Change 'Permissions-Policy' to WARN, or allow exclusion?

[mejofi]

If I am reading the documentation correctly;

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy

the header is basically a Chrome-only thing, and not broadly supported in Firefox and Safari, which only support some categories, and then mostly within <iframe> tags. Besides that it's also missing a way to disable everything at once, like when running a static website that asks nothing at all.

It might therefore be better to downgrade this test failure to a warning, or allow for a way to exclude certain tests?

[sesh]

This was added to promote blocking of FLoC with:

Permissions-Policy: interest-cohort=()

See, for example, this post from Plausable: https://plausible.io/blog/google-floc#how-to-opt-out-of-floc-as-a-web-developer-set-a-permissions-policy

Since FLoC is dead and this header is otherwise a bit of a mess I agree that displaying a warning might be more appropriate for some cases.

That said, there's no harm in including this as a way to explicitly tell supported browsers that the page cannot access the camera/microphone/location. If you include any third party javascript or user content on the page then these rules will block the use of those browser features from within code you might not have full control over.

A header like this is close to ideal in my opinion:

Permissions-Policy: camera=(), microphone=(), geolocation=()

Edit: updated the examples with the correct pluralisation of Permissions-Policy.

[mejofi]

Ah, yeah, that also makes sense. The main reason I am a bit annoyed with this particular header, besides the fact that there's no way to just do a blanket deny for sites that never need any of it, regardless of what new options may be added in the future, is that it just adds extra size to the request without actual benefit.

The one you suggest may be an interesting compromise, though 🤔

[mejofi]

Oh, by the way, it should be Permissions-Policy, plural. Shame on me for copying without proper review 😂

[sesh]

Whoops, I've updated the example above in case anyone else copies it.

I've been frustrated at the header as well. RE: not being able to do a blanket deny; I believe that's because the list of directives is considered non-exhaustive, and as new browser features are added new ones may be included. "Deny All" would mean denying all current directives, but also all future directives which is unlikely to be what you're after.

It's also still a draft and only in Chrome.

I came down on this being a net win for Chrome users when implemented in a way that blocks access to device features from any third party code. Because of that I think it does make sense to expect it in most cases.

[mejofi]

From a security perspective, you'd actually want to deny all future directives, so you don't end up opening yourself up to features you have not explicitly enabled. I'll accept the current conclusion, though, perhaps to be revisited if it ever moves beyond Chrome into some form of standard.