`Permissions-Policy` - Wrongly subsumes `Feature-Policy`

[ddbeck]

What type of issue is this?

Incorrect support data (example: BrowserX says "86" but support was added in "40")

What information was incorrect, unhelpful, or incomplete?

BCD records the Feature-Policy header as an alternative name for Permissions-Policy, despite Feature-Policy having a distinct, (now non-standard) syntax. This prevents web-features from computing a plausible status for both Feature-Policy and Permissions-Policy.

What browsers does this problem apply to, if applicable?

Chromium (Chrome, Edge 79+, Opera, Samsung Internet)

Luckily, this only affects Chromium-based browsers.

That said, all browsers seem to support the permissions policy specification's allow attribute on <iframe> elements but, if I understand it correctly, the attribute syntax (which differs from the header) is compatible between the two (feature policy spec, permissions policy spec).

What did you expect to see?

Entries for both http.headers.Feature-Policy and http.headers.Permissions-Policy (and possibly for the associated web APIs, see API names below for further discussion).

Did you test this? If so, how?

No, but it's not a support problem—I trust that the data is accurate—just that the representation of the data doesn't conform to the way other similar API changes are represented in BCD.

Other sources, such as caniuse, separately represent feature policy and permissions policy.

The change in syntax is well attested.

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

Downstream consumer PR that illustrates the problem with the current data: web-platform-dx/web-features#2661

Implementation bugs:

• Firefox: 1531012 - (permissions-policy) [meta] Permissions Policy tracking
• WebKit: 253126 – Implement Permissions-Policy HTTP Header

Do you have anything more you want to share?

Content considerations: MDN documents this as Permissions-Policy. This is probably fine. However, if we were to split Feature-Policy from Permissions-Policy, then the MDN reference pages would no longer report anything about the Feature-Policy support. To cover these facts, it would probably be necessary to do something like include a section in the PP pages mentioning the former FP header (perhaps including an extra compat table) or add notes to the PP BCD mentioning the succession from FP to PP.

API names: The little-used web API could be represented under the spec's permissions policy naming, with the feature policy names as alternative_name values. This is probably technically correct, but I'm not certain if it's worth doing: no browser (including Chrome) actually ships it under the new names.

[github-actions]

This issue was automatically closed because the title was left as the default, and a summary was not added.

If this is not a spam issue, please replace the <SUMMARIZE THE PROBLEM> part of the title with a short summary of the reported issue, and then post a follow-up comment. A maintainer will review your issue and reopen it if needed.

[caugner]

I don't have any objections against this. If their syntax differs significantly, we probably shouldn't mix these features in BCD.

[hamishwillee]

IMO they are very diverged now, and splitting out Feature-Policy makes sense to me - no point doing contortions to make them stay the same.
However if we do this we should add a corresponding Feature-Policy page to MDN that contains information that where there is duplicate information it is the same as in Permissions-Policy.

Note that this is needed because Firefox somewhat implements Feature-Policy - at least in iframes - but the header is not sent by default. There has been a purge of that name (merged into the Permissions-Policy docs) which was fine while we were treating them as the same, but is not very useful for Firefox if we are now treating them as different.

Note, the alternative name doesn't seem to be visible on Permissions-Policy page in MDN.

Does that make sense?

[ddbeck]

I've sent #26708. There are several unanswered questions, bu it's a start.