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 https://github.com/w3c/webappsec-feature-policy/issues/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