Relationship of Permissions, Feature Policy, Origin Policy?

permissions
Tags: #<Tag:0x00007fba019063d0>

#1

Hi, I wish to test my perhaps flawed understanding regarding the relationship amongst these specs:

I note that the permission-registry and the set of Policy Controlled Features intersect but are not congruent. And both Origin Policy and Feature Policy have things to do with HTTP header fields.

I note that none of the above specs reference each other.

Q1. Is Feature Policy intended to supersede Permissions? If one squints even not too hard it seems the former is a superset of the latter.

Q2. If the answer to Q1 is “no”, then what is envisioned regarding the long-term coexistence of Feature Policy and Permissions?

Q3. Origin Policy does not at this time appear to limit the HTTP header field names & values one can enumerate in an Origin Policy Manifest. Does this mean one can use an Origin Policy to convey a Feature Policy HTTP Header Field?

thanks for any light y’all might be able to shed here,

=JeffH


#2

@Ian_Clelland is more authoritative than me on Feature Policy, but I believe we’re hoping for Feature Policy and Permissions to refer to a shared list of Permission Names / feature-identifiers. I believe all permissions should also be controllable with a feature policy.

This doesn’t mean that Feature Policy would “supersede” Permissions: Feature Policy controls whether a page can request a permission, but the page still might not have the permission that it could request. That is, the ability to record video is one capability, while the ability to request the ability to record video is a different capability.

I believe Origin Policy has been designed separately from both of these, and I don’t think @mikewest expected it to be used to send Feature Policy headers, but having not studied it at all, doing so seems plausible to me.


#3

@jyasskin is basically correct here.

A1. No, Feature Policy doesn’t supersede Permissions; they’re intended to co-exist.

A2. Fundamentally, Permissions is about the user, while Feature Policy is about the web developer / site owner.

The Permissions API provides a method for pages to request permission from the user for certain APIs. If the page is allowed to request permission, then the user can choose to grant / deny.

Feature policy lets developers control which pages/frames are allowed to request permission. By default, scripts running in top-level pages (not inside of <iframes>) have the ability to request permissions from the user, while cross-origin pages in frames are not allowed to request permissions.

And, as @jyasskin said, they share identifiers, so that the api name you would use in an iframe

<iframe allow="geolocation">

is the same name that the embedded page would use to request the permission:

navigator.permissions.query({ name: "geolocation" }).then(...)

A3. Ideally, yes. You would be able to use Origin Policy to set a Feature Policy header that would apply to every page on an origin. Currently, without Origin Policy, every page needs to be delivered with a header, and in a lot of use cases, that header should be exactly the same for every single page. Having to specify it for each page only increases bandwidth requirements and introduces the possibility of errors. Origin Policy should solve that, once it’s actually available.


#4

thanks @jyasskin & @Ian_Clelland for the clarifying info :slightly_smiling_face:

=JeffH


#5

Off topic but for completeness’ sake, here are a few other permission-related features :crazy_face:

  • <iframe sandbox="allow-popups">; the sandbox attribute is defined in the HTML spec.

  • <iframe allowpaymentrequest>; this special attribute is defined in the Payment Request spec.

Let me know if there’s anything else.