Intent to Prototype & Ship: Expanded Wildcards in Permissions Policy Origins
Ari Chivukula
Contact emails
ari...@chromium.org, mike...@chromium.org, icle...@chromium.org
Prior Work
Wildcards in Permissions Policy Origins
Specification
https://github.com/w3c/webappsec-permissions-policy/pull/482
Background
In M108 Chrome added support for wildcards in permissions policy structured like SCHEME://*.HOST:PORT (e.g., https://*.foo.com/) where a valid Origin could be constructed from SCHEME://HOST:PORT (e.g., https://foo.com/). This required that the HOST was at least eTLD+1 (a registrable domain). This meant that https://*.bar.foo.com/ works but https://*.com/ won’t (if you wanted to allow all domains to use the feature, you had to delegate to *). Wildcards in the scheme and port section were unsupported and https://*.foo.com/ did not delegate to https://foo.com/.
Before, a permissions policy might need to look like:
permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://cdn1.foo.com" "https://cdn2.foo.com")
In M108 and later, it could look like:
permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://*.foo.com")
Summary
Subdomain wildcards in allowlists provided some valuable flexibility, but differed from existing wildcard parsers and required novel code and spec work. This intent will reduce that overhead by reusing parts of the existing Content Security Policy spec and permitting ‘scheme + wildcard domain’ and ‘wildcard port’ in the allowlist.
Specifically, this intent would adopt the definition of host-source and scheme-source instead of origin in the Allowlist definition while requiring that the path-part is empty (as Permissions Policies apply to matching origins). This would change three things from the prior wildcard implementation (all of which expand the range of allowed wildcards and none of which add new restrictions):
(1) Removing the eTLD+1 requirement for subdomain wildcards
Previously, you could not have a subdomain wildcard like “https://*.com” but could have one like “https://*.example.com”.
Now, you can have subdomain wildcards both like “https://*.com” and “https://*.example.com”.
(2) Allowing scheme restrictions on wildcard domains.
Previously, you could allow “*” but not restrict to a specific scheme like “https://*” or “https:”.
Now, you can still allow “*” but have the option of delegating to just a specific scheme like “https://*” or “https:” (the behavior of these is identical).
(3) Allowing port wildcards.
Previously you could delegate to the default https port like “https://example.com” or “https://example.com:443” (the behavior of these is identical), but there was no way to explicitly delegate to all ports like “https://example.com:*”.
Now, you can still delegate to “https://example.com” or “https://example.com:443” but delegation is also permitted to a wildcard port like “https://example.com:*”.
Blink component
Motivation
The Permissions Policy specification “defines a mechanism that allows developers to selectively enable and disable use of various browser features and APIs.” One capability of this mechanism allows features to be enabled only on explicitly enumerated origins (e.g., https://foo.com/). This mechanism is not flexible enough for the design of some CDNs, which deliver content via an origin that might be hosted on one of several hundred possible subdomains. Rather than designing a novel wildcard system we should reuse an existing one to reduce developer overhead and promote code/spec component reuse.
There has not been a prior discussion on specifically which new types of wildcards should be added when we switched to using the CSP parser, so that discussion should be resolved in the approval of this intent and in the interoperability/TAG issues below.
TAG review
https://github.com/w3ctag/design-reviews/issues/765
Compatibility
Depending on their user base, sites may want to entertain a transition period for older Chromium clients where they enumerate all desired origins for some versions and use wildcards for others.
Interoperability
We would be the first to implement if approved.
Gecko: https://github.com/mozilla/standards-positions/issues/760
WebKit: https://github.com/WebKit/standards-positions/issues/51
Debuggability
Future work might flag syntax errors in the Issues tab.
Is this feature fully tested by web-platform-tests?
No, but it will be.
Tracking bug
Link to entry on the Chrome Platform Status
Yoav Weiss
Contact emails
ari...@chromium.org, mike...@chromium.org, icle...@chromium.org
Prior Work
Wildcards in Permissions Policy Origins
Specification
https://github.com/w3c/webappsec-permissions-policy/pull/482
Debuggability
Future work might flag syntax errors in the Issues tab.
Is this feature fully tested by web-platform-tests?
No, but it will be.
Tracking bug
Link to entry on the Chrome Platform Status
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJRu2--NqZdPKjeF9HRc%3DcQaNFxCpYb%3DUvfsmperXPTFg%40mail.gmail.com.
Ari Chivukula
Alex Russell
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Ari Chivukula
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Rick Byers
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJ%2Bhr8chAOPiTvaSwYzJF%2B2A1ZiVG7CUR3scv1DgEreag%40mail.gmail.com.
Ari Chivukula
Rick Byers
Ari Chivukula
Yoav Weiss
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJRu2--NqZdPKjeF9HRc%3DcQaNFxCpYb%3DUvfsmperXPTFg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Chris Harrelson
LGTM1
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJRu2--NqZdPKjeF9HRc%3DcQaNFxCpYb%3DUvfsmperXPTFg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJ%2Bhr8chAOPiTvaSwYzJF%2B2A1ZiVG7CUR3scv1DgEreag%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/55555aaa-7ff3-43aa-a771-9ba4774d03bbn%40chromium.org.
