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)