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

Thanks for the feedback!

> Since there is already a permissions API, as long as the naming (of the permissions being queried) is consistent it feels like extending functionality that is missing on that end is more sensible. (if there is any - if it's just for querying then that's already covered?)

> (Also noticed the same point was brought up in the issue - should I continue there?)

This sounds more appropriate for Permissions Policy ([where the point was definitely brought up](https://github.com/w3c/webappsec-permissions-policy/issues/401)) -- the features covered by that mechanism are mostly suitable for inclusion in `permissions.query`.

The configuration space of Document Policy features may be more complex, involving at a minimum floats, ints and bools for a given configuration point. An API would probably answer questions like "what was the (minimum) required policy on this document?", "what is the current policy for this configuration point?", "If I create an iframe like this, what will its required policy be?" -- I don't know if the permissions API is suited for that.

> Regarding the naming - we've discussed in breakout and we don't have a better idea. However, we agree the current naming is not very self-descriptive and therefore could be confusing to developers who want to figure out what this does and how they can use this (though it does follow on from the header). We recommend you do some user-research with developers - explaining what it is and getting feedback.

I'll see what I can do along those lines, thanks!

> Regarding the mechanism, we don't see any issues with the CSP-based approach.

That's great to hear 😄 

> This sounds like a reasonable plan forward. (We are a bit afraid of having a mechanism that doesn't cover a use case when we actually have one - we have made these mistakes in the past.)

Sounds good, thanks 👍 I'll see about removing that from the spec until there is a clear use case.

-- 
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-740803324