How do I disable everything?

[billinghamj]

Using a CSP, I'd do:

content-security-policy: default-src 'none'

How can I achieve the equivalent here?

[Malvoz]

This is essentially a duplicate of #189.

[billinghamj]

It is related, but I do not think it is a duplicate. I have looked thoroughly to try and figure out the answer to this question and have come up empty.

[billinghamj]

For example, perhaps I could do something like feature-policy: ;? Indicating that I'm aware of the header, but don't want to enable anything

[clelland]

This does seem to be exactly the same request as #189, except that the only value you want to use is 'none'.

The points I made in #189 (comment) all still apply, I believe -- I'd like to see FP used similarly to sandboxing, to allow the ability to remove features which may be fundamental to the web platform generally. You probably don't want all of those removed from your top-level page, and you almost definitely don't want browser vendors arbitrarily adding new features to that set (like one day removing the ability to use images, for instance).

That said, I would support an option that turned off all of those features which have a default allowlist of 'self' -- those are the features which are already denied by default in cross-origin frames, and having the ability to disable all of them with a single directive could be useful. I think that bikeshedding the syntax for such a switch would be the only blocker there.

[billinghamj]

In my case, it's an endpoint which simply doesn't serve HTML. It's an API. So there is never a scenario where any HTML feature would ever be used.

[jpchase]

As suggested in #189 (comment), you shouldn't need to specify the header for an API endpoint. If the endpoint doesn't serve HTML, then it doesn't matter if HTML features are enabled or disabled, because there's no content that can attempt to use any features.

[samuelweiler]

re: the concern about evolution, what if added a numbering to the permissions registry and could say "disable every before feature 178, except allow 42"? (I also heard ideas about named categories or lexical wildcards, e.g. ch-* or sensor-*.)

[AramZS]

Yeah, I think maybe a wildcard based around categories makes sense? Seems something like ch-* or even ch-ua-* or clipboard-* would be very useful.

[anarcat]

i was pointed here from this blog post where it says the answer is apparently:

<iframe
    credentialless
    allowfullscreen
    referrerpolicy="no-referrer"
    sandbox="allow-scripts allow-same-origin"
    allow="accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; battery 'none'; browsing-topics 'none'; camera 'none'; display-capture 'none'; domain-agent 'none'; document-domain 'none'; encrypted-media 'none'; execution-while-not-rendered 'none'; execution-while-out-of-viewport ''; gamepad 'none'; geolocation 'none'; gyroscope 'none'; hid 'none'; identity-credentials-get 'none'; idle-detection 'none'; local-fonts 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; otp-credentials 'none'; payment 'none'; picture-in-picture 'none'; publickey-credentials-create 'none'; publickey-credentials-get 'none'; screen-wake-lock 'none'; serial 'none'; speaker-selection 'none'; usb 'none'; window-management 'none'; xr-spatial-tracking 'none'",
    csp="sandbox allow-scripts allow-same-origin;"
    width="560"
    height="315"
    src="https://www.youtube.com/embed/jfKfPfyJRdk"
    title="lofi hip hop radio 📚 - beats to relax/study to"
    frameborder="0"
></iframe>

the overflow here doesn't do justice to the length of that allow list, it's a bit ridiculous. here is it in its entirety: allow="accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; battery 'none'; browsing-topics 'none'; camera 'none'; display-capture 'none'; domain-agent 'none'; document-domain 'none'; encrypted-media 'none'; execution-while-not-rendered 'none'; execution-while-out-of-viewport ''; gamepad 'none'; geolocation 'none'; gyroscope 'none'; hid 'none'; identity-credentials-get 'none'; idle-detection 'none'; local-fonts 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; otp-credentials 'none'; payment 'none'; picture-in-picture 'none'; publickey-credentials-create 'none'; publickey-credentials-get 'none'; screen-wake-lock 'none'; serial 'none'; speaker-selection 'none'; usb 'none'; window-management 'none'; xr-spatial-tracking 'none'",.

would be ... uh... nice to improve on this a bit.

[nextgenthemes]

I am also here because of this blog post and very skeptical of its claim about the allow attribute. I would love someone to chime on who actually knows what (s)he is talking about. Specifically asking for the iframe context here, as this seems to be overlapping with some HTTP header stuff I am not sure if I understand at this point.

I never in my life actually fully read any spec, they are annoying to read, and I like to leave them to the browser devs to know how to implement things.

I read some MDN, and from that it seems many of these things are actually not even implemented in browsers at this point. So just based on that, no we do really need to add it all but to be future-proof, maybe.

The way I just assume it works is having nothing to allow has it disabled as in 'none'! That is why YouTube give you allow="autoplay ..." to make it work. So why would we need autoplay 'none' if just not having autoplay in the allow attribute also works? Or why would YouTube give this embed code if the default would be 'self' anyway? It makes no sense to me.

Or is that the default setting is taken from browser or server config?

Most of these directives have a default of self so for autoplay, and most others:

allow="autoplay"

is the exact same as:

allow="autoplay: 'self'"

So if putting in the directive works in on their own switches to the default, why should not having it on there not be 'none' ??

Again, I'm just going by common sense here, briefly looking at MDN. Did not read it specifically say that anywhere, but ... Very skeptical of that blog post author's claim. If we really need to this to "absolutely fucking not" what exactly is happening when it's not set?

Again would love some clarification of someone who actually knows how the browsers have implemented this and what we should use in the real world and not so much what the spec says but also that of course.

[anarcat]

I would love someone to chime on who actually knows what (s)he is talking about.

Yeah, that would be a welcome change!

I never in my life actually fully read any spec, they are annoying to read[...]

Thankfully, @jvoisin actually knows his shit and can read (and actually does read even! including specs!), so you can probably trust him on this.

[Dreamsorcerer]

Still skeptical about this.

I'm not clear what you're sceptical on. Yes, you need to put all those nones in. That's why this issue exists, because we all think there should be a better way to do this (like CSP does).

If you've specified that permissions policy in a header for the entire page, then you don't need it in the iframe. The iframe attribute can only further restrict access.

I think you can probably answer any other questions by reading the MDN description:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#allow
and the link from there to:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy#iframes

[nextgenthemes]

I'm not clear what you're sceptical on. Yes, you need to put all those nones in. That's why this issue exists, because we all think there should be a better way to do this (like CSP does).

Well, I made it clear why. Because specs !== actual real world browser implementation in some cases. I just found this so incredibly stupid that I kind of assumed it can't be THAT bad, at least for the iframe context.

If you've specified that permissions policy in a header for the entire page, then you don't need it in the iframe. The iframe attribute can only further restrict access.

Ah, that makes things much more clear to me. So there is probably no "default all off" for the iframe or whatever I was hoping/assuming. I deleted my last comment because I was too confused.

@anarcat

Speaking of "harm reduction" and that blog post again. YouTube gives out this default embed code:

<iframe ... allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

Not sure why they want accelerometer and gyroscope for, maybe it helps or is even needed when people turn their devices from portrait into landscape. But they can detect the resolution change from viewport: I am curious what changes for a YT embed if you block this. They for sure can use this for tracking activity better, so it probably is harm reduction.

web-share, clipboard-write. I do not consider it harm reduction to block this.

speaker-selection, picture-in-picture I do not consider them harm as well. Legit features people may want to use watching videos.

encrypted-media I think this refers to Encrypted Media Extensions API / Widevine closed source bullshit. I think encrypted media does not work at all on iframes when there is a sandbox on the iframe. I think I remember checking this a while back, and I could not get it to work in Brave on Ubuntu. There was nothing specifically to allow in sandbox for it. So it might not be needed to block this specifically, when you also use sandbox. Also, you may actually want to allow it, debatable if this is "harm". My guess is that 99.9% of YouTube videos are not encrypted and play fine without, I do not even know if they use it for YouTube Red. They have Hollywood movies on there, never used that, maybe they use it for that. Maybe they have something evil planned to do some kind of mass rollout and that is why they have it on every embed code. Or it's just their default template because it's needed for some movies.

I guess I go with my own long allow list that makes sense to me.

[clelland]

This has been a long-standng request, from a lot of developers who make a lot of good points about the ever-increasing number of policy-controlled features, and the terrible ergonomics of turning them all off individually.

@marcoscaceres and I met today to discuss this, and have a concrete proposal to do exactly this - disable all (safe-to-disable) features by default, and allow individual ones to be overridden.

I'm going to close this (and other related issues), but only in order to move the discussion to a central place at #189 (comment)