Delineate relationship between Feature Policy and Permissions

[equalsJeffH]

Over in wicg.discourse.io, ian_clelland writes in response to a query regarding the relationship between Permissions and Feature Policy:

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 ) have the ability to request permissions from the user, while cross-origin pages in frames are not allowed to request permissions.

I made the query because the above, to me at least, is not clear in the Feature-Policy and Permissions specs.

see also: w3c/permissions#176

[martinthomson]

In reviewing this with folks at Mozilla, it seems like the most understandable use of this is for permissions. That it uses a different, but partially-overlapping, set of labels is confusing.

We all read and understood @clelland's description, but - speaking personally - I don't find that at all persuasive:

• Though the scope of feature policy is broader, it is only broader in an aspirational sense. Those features that are unique to feature policy either probably need a permission, or don't belong here. I mostly refer here to 'sync-xhr', which is more like an intervention than a policy control - every other listed feature should have a permission.

• Though the entity controlling access is different, that doesn't matter. Permissions already intermixes the notions of whether it is a matter of browser policy with user decisions. What matters here is that there is a point of access control. For features, a single access control point makes far more logical sense than two separate controls. That control point can have multiple ways that it can end up in the "off" position. What we have here is two separate controls on two separate, but suspiciously similar, things.

I would like to see this use the same list as permissions. Or, if the scope of this is really broader than what permissions covers, have permission use the subset of feature policy controls that are permissions-oriented.

[raymeskhoury]

I would like to see this use the same list as permissions. Or, if the scope of this is really broader than what permissions covers, have permission use the subset of feature policy controls that are permissions-oriented.

Agreed - I think that's exactly where we ended up. It didn't necessarily make sense to have a permission for everything listed in FP but it should certainly be a superset.

[clelland]

@martinthomson, I agree that feature policy should definitely use the identifiers from the Permissions API. (I thought it already did, but I don't see any text to that effect in the Permissions spec, so I must be misremembering that). We should have a statement somewhere that declares that each of the permission names also represents a policy-controlled feature.

It should, as @raymeskhoury says, be a superset of that, though. There are definitely features, besides just sync-xhr, that do not fit into the permissions framework that are a good fit for feature policy. I don't think this issue is the right place to have that discussion; I'll open a new one for that.