Re: [w3ctag/design-reviews] Feature policy evolution (#341)

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) (https://github.com/w3c/webappsec-feature-policy/issues/359)
  - The header is now also renamed to "`Permissions-Policy`", and uses a structured syntax (https://github.com/w3c/webappsec-feature-policy/issues/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. (https://github.com/w3c/webappsec-feature-policy/issues/357). This means that features can be completely blocked from subframes, even if an attacker can inject HTML)
  - Parameterized features (#2 at the top of this request) have been dropped, and have been moved completely to the Document Policy spec. ([TAG review](https://github.com/w3ctag/design-reviews/issues/408))

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.

-- 
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/341#issuecomment-651794755