describe implicitly-granted (chooser-based) permissions

[dbaron]

The registry section of the Permissions API spec should describe implicitly granted permissions (such as file upload or screenshare of a window) in addition to the explicitly granted ones that it currently describes.

I mentioned this initially in w3ctag/design-reviews#225 (comment) in the context of the proposal for Permission Delegation discussed in that issue.

The background here is that some permissions for powerful capabilities on the web (e.g., geolocation) are granted by explicitly asking the user about that permission. The current permissions API spec and the capabilities it provides are designed around this type of permission.

However, there are a set of permissions that are granted more implicitly through an act of user selection. For example, permission to upload a file is granted by the user choosing that file in a file picker; similar for screensharing a window in Screen Share. This sort of permission grant is in many ways better than explicitly asking the user since it's often clearer what's being granted, and the grant is clearly tied to the thing that needs it. It also requires less API around it, since it doesn't make sense to query the status of this permission, or to request it separately.

However, there are some uses of the permissions API, such as the Permission Delegation proposal that would control the delegation of permissions to cross-origin subframes, where it seems like it would be useful to have API around these permissions. It seems like a page should be able to control whether its subframes can request file upload or screen share just like it should be able to control whether its subframes can request geolocation. (In both cases, the request appears in significant ways to come from the toplevel page.)

So I think these permissions ought to be described in the registry in the permissions API spec, in a way that Permissions.query() doesn't apply, but that other APIs such as permission delegation do apply.

[jyasskin]

https://w3c.github.io/permissions/#prompt-the-user-to-choose anticipates folks integrating with file upload and screenshare choosers, and was co-designed with the Bluetooth and USB device choosers. I call these chooser-based permission rather than implicit ones, since the user is actually more explicit about what they want to grant access to. It is still useful to query() the status of these permissions, since they can be "denied" even if they can't be "granted". We also talked about query() returning the set of devices the user has granted to a page, but I believe nobody's implemented that.

So, in general, yes, I'd welcome patches to add more chooser-based permissions to the registry.

@raymeskhoury, are you still the right contact for Permission Delegation?

@clelland, this overlaps some with the Feature Policy names.

[clelland]

@jyasskin, when you say that there's overlap, which names are you thinking of? Anything with a permission should already have an associated feature which can be controlled with Feature Policy, and it looks like this mechanism just uses the same names to invoke the chooser as well?

Feature Policy should control the underlying permission state, forcing it to "denied" if the feature is disabled in that context.

[jyasskin]

If Permission Delegation defines any new names that aren't defined by the Permissions spec, those should be covered by the Feature Policy names too. There may be nothing for you to do here, but I wanted to double-check that.

[marcoscaceres]

Summary of Issue #178 (Thanks ChatGPT)

Context:
This issue questions whether the Permissions specification needs additional clarity or changes to ensure user agents’ behavior is well-defined, without becoming overly prescriptive.

Key Points:

1. Clarity vs. Over-Specification:
   The discussion focuses on providing sufficient guidance to user agents without constraining their flexibility unnecessarily.

2. Current Consensus:
   Although some clarifications might be beneficial, there is no strong inclination toward making normative, mandatory changes. The conversation centers on potential editorial improvements rather than fundamental adjustments.

3. Impact on CR Transition:
   There’s no indication that this issue poses a significant blocker to moving the Permissions specification to Candidate Recommendation (CR). It’s seen more as an opportunity for refinement rather than a showstopper.

Conclusion:
No major spec changes are required, and this issue is unlikely to delay the CR transition. Any resulting actions would likely be minor editorial clarifications.

[miketaylr]

So, I think this is an interesting idea - my proposal is to close here, but we keep #377 open as a pointer to it, if and when a UA decides they need the infrastructure to implement these types of permission.