Re: [w3ctag/design-reviews] Feature Policy: Document Policies (#408)

Hi @torgo,

Regarding the spec and explainer:
* As mentioned in previous comments, the spec and explainer have both been updated since March, to incorporate the comments from TAG. (I should still address the comments in https://github.com/w3ctag/design-reviews/issues/408#issuecomment-594227064 specifically).
* The `requires-acknowledgment` bits have been removed
* The special "no-<feature>" syntax has been replaced with standard structured-field boolean False syntax.

Regarding implementation status:
* Chrome has shipped support for just the `Document-Policy` header, to provide an document-level opt-out mechanism for [Scroll-to-text-fragment](https://github.com/w3ctag/design-reviews/issues/392).
* Chrome is considering using Document Policy to provide a similar opt-out for use of `sync-xhr` and `document-domain`, hopefully as a path to eventual deprecation of those features.

Regarding interest:
* There has been discussion in the security community about using Document Policy as a means of lowering usage of security-negative features on the web platform, by making them opt-in. (See https://cloud.arturjanc.com/secweb-2020.pdf)
* There is interest, but not *interest*, from Mozilla, on both Document Policy and its use for sync-xhr. See [MSP](https://github.com/mozilla/standards-positions/issues/327), [XHR](https://github.com/whatwg/xhr/pull/295) and comments [here](https://github.com/w3c/webappsec-permissions-policy/issues/410#issuecomment-718296128).

For TAG:
Despite Chrome shipping the initial header, there are still some outstanding issues that I would love TAG feedback on. Roughly in order of importance:
* We've deliberately not shipped the negotiation mechanism; I'm a bit concerned that "`policy`" is a very generic term to use for the attribute, and would like confirmation that it's a good choice before ossifying it.
* I'm pretty convinced that the mechanism, based on CSP-embedded-enforcement, is sound, but it would be good to get TAG's opinion on that as well.
* There is an [open question](https://github.com/w3c/webappsec-permissions-policy/issues/399) as to whether a JS API would be a good idea for introspecting the active policy.
* There are also questions about how an *enum* type should work with required policies; I haven't written those down yet, but essentially, it seems easy for a single document to specify its configuration as a single value from an enumerated set of tokens. It is much harder to provide a generic mechanism to state requirements on a document about allowed enum values. In some cases, there may be a strict linear ordering between values, but in other cases, the relationship may not be so clear. I'm happy to expand on that if it's useful, or maybe the best thing is to remove all mention of enums from the spec right now and reintroduce them later when there are actual use cases.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/408#issuecomment-728994329