#408: Feature Policy: Document Policies
Discussions
2020-02-24
Dan: what is the user need? Feels like it needs to be better documented... Feels very overly complex...
Ken: Document policy enforced? Required document policy / etc... how do these relate? Policies split into 3 different groups- this is part of it. A bit confused between the different types...
[comments in issue]
Ken: How are we gonna make sure these features are consistent... consistency needed... if presentation lock, shouldn't there be one for orientation lock? Need consistency... same names...
Dan: is that a design principles thing?
Dan: reached out to Andrew Betts for additional comment.
Ken: an overview... requires acklnwoledgement flag... What is an associated flag?
Dan: added more comments... let's move on for now
2020-11-16
Dan: asked for current status - looks stalled - hopefully we get feedback by the plenary and close it off.
Ken: Sounds good to me.
2020-11-23
[considering Ian's bullet points]
Ken: not sure I can think of a better name [than policy]....
Dan: I think we need to take these questions to plenary and maybe close the issue if appropriate.
Ken: worried about wide review from other browsers. Seems to be a very core thing, an architectural thing.
2020-12-07
Dan: looking for specific feedback on 4 points listed in issue.. let's see if we can get them feedback on those points.
... Not shipped negotiation mechanism... naming issue. Ossifying.
Dan: regarding the use of the term "policy" - I agree it's confusing.
Hadley: also not very descriptive... if you came across this on its own it's not clear what it does...
Sangwhan: might suggest "features" - but that's also confusing...
Dan: the first 2 examples are about performance. Others are about security.
Sangwhan: feature policy got split up between document policy and permission policy...
Dan: it's very complex... How do you explain this to a regular web developer.
Sangwhan: don't see average web developers using this - There will be "silver bullet" policies. This is opt in as well..
Dan: maybe we don't have any useful feedback on the naming other than that the current name is not so developer-friendly (self-descriptive).
[on the API]
Sangwhan: we have a permissions API... It should be unified...
Alice: on naming: the name fits together with the use of document policy header.
Sangwhan: on the 4th point (enum) I would lean towards waiting until we see an actual consumer.
Dan: let's try to close this in plenary after leaving this feedback.
OpenedAug 13, 2019
こんにちはTAG!
I'm requesting a TAG review of:
Further details:
You should also know that the initial Feature Policy spec, which was reviewed previously (#159) by TAG, can be simplified with the adoption of Document Policies. The goal is to constrain it to just those features which are best served by the "allowed at top-level, delegate to cross-origin frames" model, and focus it tightly on that use case.
You should also also know that this explainer is the result of discussions which were also previously noted by TAG in #341.
This request has been updated (2020-12-08) to reflect the new repository which was opened in WICG for Document Policy, as a result of https://github.com/w3c/webappsec-permissions-policy/issues/411.
We'd prefer the TAG provide feedback as (please select one):