Renaming Feature Policy

[annevk]

As Feature Policy is for delegating permissions, it would be good if it had a name that made it not sound so encompassing. Permissions Policy?

This would also allow us to redo the header using Structured Headers.

[clelland]

Delegation Policy?

(I'm still hesitant to bind the spec tightly to permissions, as there are other features that follow the 'delegation' model for attribution and trust that don't necessarily fit the user-granted-permission model, but otherwise I'm open to change)

[annevk]

I think the problem with "Delegation" is that at least as done today, it can also apply to your own document.

What's a feature that we'd disable by default in third-parties and we'd not want to expose through navigator.permissions.query()?

cc @johannhof @jan-ivar

[clelland]

Right now, that category includes fullscreen, paymentrequest, EME, idle-detection, USB, wake-lock, publickey-credentials (WebAuthn), serial, and xr-spatial-tracking. (There may be others proposed; I'd need to take a look to see what else is there)

Are all of those candidates for navigator.permissions? If so, that speaks in favour of tying the mechanisms together. I'd still be wary of turning this into something that can only ever be used for items in the permission registry.

[annevk]

I would go as far as saying that all of those should be permissions, if they are not already.

cc @foolip

[jan-ivar]

Permissions are user agent territory (e.g. see web compat issues w/sites using query for priming).

Won't classifying these as "permissions" cede spec control over them to user agents?

We recently removed the device-info permission from mediacapture for this reason.

[annevk]

That's a good point, not all permissions are exposed through query(), but I'd still argue that "camera" is a permission. It mostly means permissions are complicated and permission strings useful in one place might not be useful in another.

[foolip]

@annevk do you think Fullscreen should be a permission in the full sense? If memory serves it started out that way but implementations backed down to just requiring user activation.

[annevk]

I'm not sure what "full sense" means. Permissions are a very broad concept and a lot of permissions have unique characteristics. I would expect sites to be able to delegate "Fullscreen" and users to be able to disable "Fullscreen". Beyond that it's a bit less clear to me.

I guess the question raised in this thread is whether that's sufficient to count it as a permission. It doesn't seem too different from "camera" to me as discussed above and permission is a good grouping name for these kind of features, so to me it seems fine.

[clelland]

That's a good point, not all permissions are exposed through query(), but I'd still argue that "camera" is a permission.

The permissions registry would agree with you on that count.

It mostly means permissions are complicated and permission strings useful in one place might not be useful in another.

They are. I'm still worried about what it would imply to say that all features controlled by this mechanism must also be in the permissions registry. I think that query() is probably a good interface to be able to see their state, but not all of these require the same UA treatment as what is in the permissions registry today for requesting / revoking permission.

[annevk]

Yeah, so Firefox does not support requesting or revoking through a general API and it seems unlikely we'd add that. We support query() only and only for some permissions.

I also don't think we ever want to have a permission that is not a "Feature Policy", so the namespace is definitely shared. And given that it's shared and not all permissions are visibly exposed anyway, we might as well use that as a name.

[jan-ivar]

Permissions are a very broad concept and a lot of permissions have unique characteristics.

Actually, looking at the registry, few permissions appear to alter the base premise that, apart from feature policy, permission behavior is completely user agent dependent, almost by definition:

"If there was a previous invocation of this algorithm with the same descriptor and settings, returning previousResult, and the UA has not received new information about the user’s intent since that invocation, return previousResult.
Return whichever of the following options most accurately reflects the user’s intent for the calling algorithm, taking into account any permission state constraints for descriptor.name"

As I recall, it was written like this to reflect the status quo of user permissions in browsers. I should say I'm personally a proponent of differentiation in this space, since I don't think we've seen the ideal permission UX yet.

But, if we already have web compat around a feature that does not center around user settings, say fullscreen behavior, then I think it's fair to say that moving it to be a user permission, is not without consequence. I'd recommend looking at that decision on a case by case basis.

users to be able to disable "Fullscreen"

I think this is the key. If we want a user setting then sure. Permissions are user permissions.

[foolip]

@annevk I mean at minimum that the feature would be exposed in the Permissions API and WebDriver endpoint, and most likely that there would be some UI around this. Neither of those are true for Fullscreen now.

[annevk]

I guess I'm saying that the minimum is that it's exposed through allow="" and everything else is up for discussion given the status quo around existing permission strings.

[foolip]

Alright, if nothing beyond support in allow="" is implied, then at least for Fullscreen I don't see a problem with that.

[clelland]

That makes sense to me, if "exposed through allow" is 1:1 with "exists in permission registry" and maybe with "exposed through query()", and if we can ensure that participation in that registry doesn't imply anything else (such as prescribed UI or default state)

[jan-ivar]

WFM. Note query is a fingerprinting surface. Sure, sites may request notification, and if it fails, learn I've globally blocked notifications. But most tracking libraries probably wouldn't risk that.

[clelland]

It sounds to me like what we actually have in that case, is

1. A common definition (and central registry) of "powerful feature", which is useful in and of itself. Currently residing in the Permissions spec.
2. A method for sites to delegate to child frames the ability to access powerful features, through the allow attribute.
3. A method for sites to disable powerful features in their own documents, through the Feature-Policy header.
4. Algorithms for interacting with the user, in cases where the user should be the final arbiter of whether a feature should be allowed or not. (granting and revoking permission)
5. A javascript interface for querying the availability state of powerful features, through navigator.permissions.query.

If the Feature Policy mechanisms (2 and 3) apply to all members of the registry (1), and the Permission mechanisms (4 and 5) apply to only some of them, I wonder if the registry should be separated from the Permissions spec, and made into a separate document.

[annevk]

Well, I think 4 applies to all of them as well. The Fullscreen specification quite clearly allows user preferences to override whatever it dictates and for these features that generally applies I'd hope. Again, the exact UI is up to the user agent. User agents may decide to not have UI, but that doesn't mean it's a feature without user agency.

Also, if we rename Feature Policy to Permissions Policy the odd one out might be query(), but:

1. It's quite normal for APIs to expose a subset of the overall model.
2. I think we can do more work there to see if the fingerprinting issues can be countered somehow (e.g., requiring the default value ("prompt" ) to be returned if there's a global setting).

To me the criteria for a permission are:

1. It's available in first-parties and not delegated by default.
2. End users might want to control it.

[annevk]

@clelland what does vNext mean? It would be really great to get this resolved as it would unblock Firefox from shipping the header.

[clelland]

vNext was a label that we were using to distinguish between the currently shipping Chrome behaviour and the stripped-down behaviour that we could get to after removing all of the ideas that ended up in Document Policy.

I'd love to get Firefox unblocked here -- it looks like what we need is some combination of:

• A final decision on the name of the HTTP header
• Decision on whether a new SH syntax is better than the existing CSP-inspired header (Are there any proposals there?)
• I'd like to see if the change I proposed in Feature Policy shouldn't be overridable #357 (comment) is tenable as well; I think it solves a real problem and makes the purpose of the header much more clear.

Also, we (Chrome) would need to figure out a migration plan for any change in the header, to ensure that we don't break existing content. That's on us to figure out, certainly, but affects timelines.

[annevk]

I think the problem is that it's CSP-inspired and doesn't actually reuse that parser as suggested at one point. The one argument to keep the existing syntax is that allow="" also uses it I suppose.

For a structured header a dictionary would make sense I think. Something like:

Rainbow: geolocation=self
Rainbow: geolocation=(self, "https://test.example")

You would still have to validate the resulting dictionary, but the overall setup would be simpler as we're adopting structured headers everywhere.

I think Permission-Policy still makes a lot of sense, including for things you might not normally think of as permissions, such as cross-origin isolated (Google proposed requiring delegation for that), but I could live with other names. I think Feature- is way too generic though, especially now that we have agreement that this will not cover everything under the sun.

@mikewest might also have thoughts.

[mikewest]

1. We're not reusing the CSP parser, which was my main hope when we were talking about the FP syntax. Given that, shifting to something we can standardize on seems pretty reasonable, and Structured Headers seems to be where folks are landing. So, my vote is to use Structured Headers' syntax.

2. I think a dictionary of lists of (parameterized?) strings is a reasonable representation of what I think FP looks like these days. It's probably reasonable to explore that a bit to see whether it would meet all y'all's needs.

3. I've given up on naming things. Just call it Rainbow. In ~5 years, that will make as much sense as Feature-Policy or Permission-Policy or whatever else we come up with. :)

[clelland]

I think I've come around to Permission[s] Policy -- if I squint just right, I can see it as a site-driven policy for how permissions (in the vaguest sense) can propagate through the frame tree.

Open questions, then:

• Permission or Permissions? (Is there a semantic difference between the two spellings?)
• Do we rename both the header and the spec? (I assume so, but want to make sure there's agreement)
• There are more questions about SH, enough that I'll open another issue.

[annevk]

Given API precedent in https://w3c.github.io/permissions/ I think Permissions would be okay. Singular would match "Feature", but is perhaps a bit weird as it is for multiple permissions? @sideshowbarker opinions between "Permission Policy" and "Permissions Policy"?

Yeah, I think we should rename both and potentially merge with https://w3c.github.io/permissions/ down the line to ensure new additions to either are considered as part of the larger whole.

Hope that helps.

[sideshowbarker]

I think Permissions plural is right for this, because with that plural it’s essentially more precisely a term of art from the broader class of things its loosely related to — which include permissions as used in, e.g., UNIX file-system permissions https://en.wikipedia.org/wiki/File_system_permissions — and that’s loosely synonymous with privileges and rights.

So for the same reason it’d make more sense to have a Rights Policy title rather than Right Policy, it makes more sense to have Permissions Policy rather than Permission Policy.

[clelland]

I've put up a PR that makes this change:

• Changes the spec document name from "Feature Policy" to "Permissions Policy"
• Changes the API from "The Feature Policy API" to "The Permissions Policy API"
• Renames the browser concept from "Feature Policy" to "Permissions Policy"
• Renames the HTTP response header name from "Feature-Policy" to "Permissions-Policy" (But does not currently change the format of the field value; that's for Feature Policy syntax: Structured Header? #376)
• Renames the ECMAScript interface from "FeaturePolicy" to "PermissionsPolicy"
• Renames the Document and WorkerGlobalScope members from "featurePolicy" to "permissionsPolicy"
• Renames the report body interface from "FeaturePolicyViolationReportBody" to "PermissionsPolicyViolationReportBody"
• Changes the report type from "feature-policy-violation" to "permissions-policy-violation"
• Renames the ABNF symbols which describe the header/attribute format.

I think that covers everything, but let me know if I've missed anything there. I won't merge this until we've handled all of the W3C process issues as well as well, so that the renamed spec can live in the correct place.

[marcoscaceres]

I know maybe too late... but this was not an amazing thing to do so late after implementations, tests, and specs had taken this up :(

[marcoscaceres]

I want to say sorry for complaining above... I got frustrated because I've had to rename a lot things lately because of it. However, I know this was a right change to make for the platform, so I'll get over it. Short term pain, long term gains.

[clelland]

Yeah :( It's not great right now, but it should be better in the long run. I'm going to try to fix up the spec situation with PRs everywhere that integrates, and to get WPT cleaned up.

Let me know if there's any way that I can help to make it easier on you.

[marcoscaceres]

Nothing immediate. I'm fixing things as I encounter them. When you do the updates, if you see anything that WebAppsWG owns, I'm happy to review. I'll update the Web Payments stuff also.