Architecture discussion: Permissions

[clelland]

As mentioned in https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-486267212, there's interest in splitting different types of policies out into different pieces of FP. I'm going to try to define the 'permissions' piece here, and leave the other two to their own issues. This issue can become the central bikeshed for that behaviour.

That said, of the three, permissions require the least deviation from the existing FP spec.

• Permission features would be a superset of those defined by the Permissions API
• All of these should be enabled by default in top-level browsing contexts. (Subject to user approval when required by the permissions api.)
• When enabled in a document, these are also enabled by default in its same-origin nested browsing contexts. (Including those at about:blank, data:, and blob: origins)
• When disabled in a document, these cannot be enabled in any of its nested browsing contexts.
• Either the Feature-Policy header or the <iframe allow> attribute can be used to change this, to decline an otherwise-granted permission, or to enable an otherwise blocked permission in a child frame (as currently specced by FP)

[clelland]

To be clear, I do think that there is room here to include things which are not strictly permissions, but behave in the same way as permission delegation (available to top-level documents, requiring the developer to delegate across origin boundaries in nested frames)

That would include things like fullscreen, payment, wake-lock, and the various Client Hints.

The critical thing is that there is a well-defined (and expected) failure mode for web developers. This is probably not suitable for APIs which can reasonably be expected to never fail, since there is no explicit opt-in. Permissions fit this model, as does fullscreen, as well as new APIs which were designed to be restricted in third parties.

[foolip]

Another thing which isn't a permission is the ability to autoplay media, listed in #296. It does meet the "well-defined (and expected) failure mode for web developers" criteria.

[eeeps]

• All of these should be enabled by default in top-level browsing contexts.

With a default allowlist of 'self', yeah? Or are there cases where we’d want the default to be '*'?

[clelland]

If we can do it, standardizing on a universal allowlist of 'self' for permissions and powerful features would certainly simplify the spec.

[equalsJeffH]

wrt the orig post's bulleted list of five proposed behavioral facets for "powerful features and permisions" (PFAP?), I'm curious wrt #4 & #5:

• (4) When disabled in a document, these cannot be enabled in any of its nested browsing contexts.
• (5) Either the Feature-Policy header or the <iframe allow> attribute can be used to change this, to decline an otherwise-granted permission, or to enable an otherwise blocked permission in a child frame (as currently specced by FP)

Those two statements seem to be in conflict to me: #4 is saying "if something is turned off in a browsing context, it can't be turned on in a child browsing context no how, period", and then #5 is saying (to me anyway), "no worries, just issue a Feature-Policy response header for the things you need when you, child context, are loaded..."

Perhaps this apparent impedance mismatch is un-intended, or I'm misreading?

[annevk]

The header would have to be set on the parent with a policy that would permit descendants (equivalent to the allow attribute, which is also in control of the parent). (There's no agreement on the exact header yet though.)

[clelland]

@equalsJeffH, I guess that wording was confusing. What I mean there is more like this (written here as three separate scenarios):

1. Browsing context A has a permission feature F enabled, and embeds a same-origin browsing context B. By default, F will be enabled in B, but A can use either a header or allow attribute to change that, and B can use a header to decline it, even if granted by A.

2. Browsing context A has a permission feature F enabled, and embeds a cross-origin browsing context B. By default, F will be disabled in B, but A can use either a header or allow attribute to change that, and B can use a header to decline it, even if granted by A.

3. Browsing context A has a permission feature F disabled, and embeds any browsing context B. F will never be enabled in B, regardless of headers / iframe attributes.

[equalsJeffH]

Ok, thanks for explanation, its clear now. So those items 1, 2, 3, replace bullets (4) & (5) in the orig post?

[clelland]

If I were going to replace them, I might say:

4. These are disabled by default in cross-origin nested browsing contexts.
5. Either the Feature-Policy header in the parent document or the <iframe allow> attribute can be used to override these defaults: to enable an otherwise blocked permission in a child frame or disable it in a same-origin frame (as currently specced by FP)
6. The Feature-Policy header in the child document can be used to decline an otherwise-granted permission.
7. When disabled in the parent document, these cannot be enabled in any of its nested browsing contexts.

(To avoid switching from declarative statements to story-telling mode, at least)

[equalsJeffH]

WRT the name "permission features", I suggest using something other than the latter because of confusion with the Permissions spec spec and "permissions" in general.

The Permissions spec uses the terms "powerful feature" and "feature" to refer to the named things that PermissionDescriptors refer to: e.g., Section 10 Permission Registry opens with:

Each enumeration value in the PermissionName enum identifies a powerful feature. Each powerful feature has the following permission-related flags, algorithms, and types:

I'm thinking I'd refer to the sort of features you are presently terming "Permission features" (in the first bullet in the orig post) as simply "powerful features", link that term to the definition in Permissions spec, and while also noting that not all powerful features have a PermissionDescriptor, and that the list of powerful features in the feature policy registry is a superset of that listed in Section 10 Permission Registry.

[annevk]

FWIW, I wouldn't take what the Permission specification says today as golden. We can change it to be more precise and fit better with what we're trying to enable here (or even merge them, which is what I'd personally like to see for the allow attribute at least).

[equalsJeffH]

@annevk wrote

I wouldn't take what the Permission specification says today as golden.

OK.

We can change it to be more precise and fit better with what we're trying to enable here (or even merge them, which is what I'd personally like to see for the allow attribute at least).

Yeah, that's an interesting idea.