Re: [w3ctag/design-reviews] Feature Policy JS introspection API (#292)

@kenchris:
> Given these inconsistencies, how malleable are the APIs at the moment since it is a shipped feature?

Those changes are likely still possible; the feature itself only shipped in Chrome 74; We're seeing some uptick in usage, though the absolute numbers are still quite small (https://www.chromestatus.com/metrics/feature/timeline/popularity/2511). An optional origin should be trivial to add; we may need to have a short overlap period while we deprecate the old names, if we go that route.

Are there TAG guidelines for what counts as a 'query' for naming purposes? The only instances I can find in our IDL are for `querySelector` and `querySelectorAll` (Permissions and WebLocks have generically-named `query()` methods as well)

> in particular we find the term "allow list" being two different things (features, origins) called the same thing confusing (hence getAllowlistForFeature returns a list of origins and not an actual allow list).

In the spec, an 'allowlist' is either a list of origins, or the value '*' (representing all origins). It shouldn't be a list of features (a declared policy is a map from features to allowlists). I think that it would run counter to that definition if we used `getAllowList` to return a list of features -- would `getAllowedFeatures` be as clear?

> At this F2F we are hearing that feature policy will get feature policies that support parameters - what is the interopt story for that?

The initial proposal (https://github.com/w3c/webappsec-feature-policy/issues/163) extended feature policy with parameters for some new features; existing features are all considered 'boolean' in type, and so 'true' and 'false' would be the only valid values, and could be omitted from any declarations (the 'true' value is inferred from the an origin being allowed at all); in this way it was intended to be backwards-compatible with existing features and existing uses.

There is some interest from people in taking those features that would work well with parameters, and splitting them off into a different mechanism, to avoid burdening Feature Policy with additional complexity. This was proposed in https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-486267212, and I opened an issue for further design discussion at https://github.com/w3c/webappsec-feature-policy/issues/299.

-- 
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/292#issuecomment-494892236