Permissions policy (formerly feature policy) evolution

[triblondon]

こんにちはTAG！

Special delivery courtesy of your request of me earlier this evening. I would like to draw your attention to two aspects of Feature policy. Feature policy itself was reviewed by the TAG while I was a member and generally judged to be splendid. However, being a 'framework spec' (my term for a spec that creates a scaffold on which elements of its behaviour will operate, but where those elements are defined elsewhere or not within the same process), it has developed in a way that might attract further interest:

1. Whilst policies are generally named for the behaviour that they allow, in some cases they are named after the behaviour that results from denying the policy. 'lazyload' is one such policy. In the default case, where no policy is defined or it is defined and allowed for the relevant origin, the document follows the instructions of the lazyload attribute, which defaults to immediate ('eager', if you like) loading. If a policy is defined and disallowed for the relevant origin, the page forces all elements to be lazyloaded. This could be considered counterintuitive, and if the TAG were to take a view, I would imagine it would be on the principle rather than this specific instance.

2. Feature Policies are booleans, but there is a proposal to make them parameteri[sz]ed. Some of the examples cited for parameterised policies seem to suggest that the value would be required ('allowed-image-formats' seems not to make sense without a value), while others which already exist as boolean policies become quite different when in parameterised 'mode' (eg lazyload), and still others seem like they are fundamentally booleans so the behaviour if a value is supplied is undefined (eg document-write).

Ref:

• Proposal: Parameterized features w3c/webappsec-permissions-policy#163
• https://github.com/w3c/webappsec-feature-policy/issues/193

[triblondon]

Also see w3c/webappsec-permissions-policy#163 (comment)

[torgo]

Trying to determine if we should try to have a more comprehensive session on this at our next f2f to progress this. @triblondon do you think this would be helpful?

[torgo]

We also discussed today the idea of adding some material to the design principles document on this topic.

[triblondon]

FP is now potentially splitting into three separate standards: one for sandboxing behaviours within an iframe, one for imposing conditions on the document itself, and one for dealing with permission-requiring features.

My original points are still valid (1 and 2 in the OP), and I’d add that the TAG might do well to consider whether it’s good to bake feature-policy’s idea of developer best practice into the platform itself, and if so whether there needs to be any additional scrutiny of what that best practice is judged to be.

Most web specifications offer a new feature. Developers decide whether to use it. It’s in some sense a market mechanism with a balance of power and interests. Feature policy takes features away or constrains how a developer might use them, without the developer having much say in the matter, though ultimately maybe for the benefit of everyone?

[torgo]

@triblondon brought to our attention:
https://github.com/w3c/webappsec-feature-policy/issues/282
w3c/webappsec-permissions-policy#296

[triblondon]

See also: https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-486267212

[cynthia]

We discussed this twice during the Iceland F2F. One was with @triblondon, and @dbaron and I had a separate discussion on this as a breakout.

While it is somewhat unclear what is expected from us here, so we considered it as a open-ended request for the time being.

First of all, we are supportive of the spec being split into three different things - we believe this allows better division of work and being able to ship the less-complex parts sooner.

One of the points that came up is that for cases where a feature policy will make an API disappear (e.g. deprecation of document.write) there is plumbing that will be required in WebIDL, and the fact that there is a path for disabling these features seems like a useful addition to the platform.

Spec templates should ideally be updated to have a separate fixed section for feature policy identifer, to be 1) machine parsing friendly and 2) easier to find by readers. This does beg the question whether or not long term there should be a registry, which is more of a question than a suggestion.

There should definitely be strong guidance on the naming conventions of these following the points above, so the initial status is either as positive as possible of as negative as possible, and not named against the default state of the policy. This relates to an issue that we should be looking at: w3ctag/design-principles#41

[clelland]

Thanks for looking at this, @cynthia (and the rest of TAG)!

One of the points that came up is that for cases where a feature policy will make an API disappear (e.g. deprecation of document.write) there is plumbing that will be required in WebIDL, and the fact that there is a path for disabling these features seems like a useful addition to the platform.

This is good to hear -- it's not something that has been proposed recently; in all of the cases where we thought we'd want to have FP control visibility of JS attributes, we eventually concluded that having methods exist, but fail in some well-defined way was less disruptive. Long term, though, actually removing APIs from the platform would be a good thing, I think.

This does beg the question whether or not long term there should be a registry, which is more of a question than a suggestion.

We're tracking this idea in w3c/webappsec-permissions-policy#244 -- I was orignally opposed, but I've come around to the idea that there should probably be one, for interoperability of nothing else.

There should definitely be strong guidance on the naming conventions of these following the points above, so the initial status is either as positive as possible of as negative as possible, and not named against the default state of the policy.

Can you give an example of what you mean by "not named against the default state of the policy"? Are there current features which we should be looking at renaming before they get too much traction?

[cynthia]

Can you give an example of what you mean by "not named against the default state of the policy"? Are there current features which we should be looking at renaming before they get too much traction?

Apologies for the delay, fell through the cracks in the new work process.

This remark might have been confusing - as for the list of shipping feature policy names I think we don't have any examples (based on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy) - but this was a meta comment on guidelines on how to name feature policies from a spec author perspective. For example, if there is a new platform feature X that is enabled by default, we'd like to see guidelines on naming the policy X rather than "disable-X" or "no-X".

One example would be "no-document-write" - since the tense of current feature policies are positive, it seems like it could be potentially flipped for consistency. One bit we overlooked when making this remark was about how to deal with feature deprecation through FP, in which case it does feel like having a distinction could be a helpful hint on a feature on it's way out. (e.g. no-document-write is an example). (We're not sure how unoptimized-images or oversized-images fit into this, though.)

Unfortunately for the last bit we don't have any concrete proposals, and would like to hear what you think.

[hober]

@cynthia @dbaron @plinss: We should discuss this in an upcoming APAC/California breakout.

[clelland]

Hi TAG!

The Feature Policy spec has evolved a bit since this request was filed, and I'd like to move forward with shipping our implementation, now that we have fairly solid consensus between Chromium and Gecko implementers, and at least informal nods of support from WebKit.

The biggest changes now are:

• The mechanism itself is now named "Permissions Policy", and is intended to cover delegation of permissions and other powerful features (other features including non-permission features like battery status, wake-lock and client hints) (Renaming Feature Policy w3c/webappsec-permissions-policy#359)
• The header is now also renamed to "Permissions-Policy", and uses a structured syntax (Feature Policy syntax: Structured Header? w3c/webappsec-permissions-policy#376)
• The header and iframe allow attribute now combine with boolean AND semantics, rather than OR, when deciding whether to delegate a feature to a specific frame. (Feature Policy shouldn't be overridable w3c/webappsec-permissions-policy#357). This means that features can be completely blocked from subframes, even if an attacker can inject HTML)
• Parameterized features (Compositing and Blending Level 1 #2 at the top of this request) have been dropped, and have been moved completely to the Document Policy spec. (TAG review)

I'd appreciate any comments on the header change, if the TAG has thoughts there. There is a migration plan for Chrome (Parse both headers if they exist, and give precedence to the Permissions-Policy header, if it exists, on a feature-by-feature basis), but I believe that Firefox would like to ship Permissions-Policy out-of-the-gate.

[dbaron]

Documenting the issues in the initial comment here (such as naming consistency) is closely related to #525 and to w3ctag/design-principles#41. It also relates to w3ctag/design-principles#144.

[dbaron]

The list of Permissions-Policy features will be useful for understanding the naming consistency. I'm not sure where the corresponding list for Document-Policy lives, though.

[cynthia]

Looking at the list of permission policies, it is a lot more consistent in terms of design after the split. I at least am happy about this change, and it makes it much nicer to define a clear pattern (e.g. if you have a permission, you must also have a corresponding permission policy) on what specs should do.

It seems like that the first concern (at least the specific part) has been addressed by removing lazyload? Are there any others that follow this pattern that we are unaware of?

The second part of the concern looks like it is now in document policy, so we'll track that there.

It feels like in the registry it would be helpful to have a column to distinguish permission-gated (e.g. geolocation) features, quasi-permission-gated (e.g. autoplay), and the other kind. (which I don't have a good name for - e.g. execution-while-out-of-viewport)

[cynthia]

I just looked at document policy and the second issue seems to be addressed, still figuring out if the first is though, as it looks like that has been refactored into document policy. (So please ignore my comment regarding lazyload above)

[cynthia]

While the first issue has not been addressed, it looks like this is being tracked in WICG/document-policy#6. We don't think there is much for us to do here as the split between permissions/document policy made it much more consistent. I've stuck my name on the watchers list for the lazyload issue to see where the discussion goes (currently it seems a bit dormant) - but aside from that I think we think it's fine to close this.