search

w3c / webappsec-permissions-policy

A mechanism to selectively enable and disable browser features and APIs
https://w3c.github.io/webappsec-permissions-policy/
Other
398 stars 155 forks source link

Renaming Feature Policy #359

Closed annevk closed 4 years ago

annevk commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

cc @foolip

jan-ivar commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

clelland commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

clelland commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

  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 commented 4 years ago

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:

annevk commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.