On Tue, Mar 14, 2023 at 3:34 PM Ari Chivukula <aric...@chromium.org> wrote:
> Contact emails > > aric...@chromium.org, miketa...@chromium.org, iclell...@chromium.org > > > Prior Work > > Wildcards in Permissions Policy Origins > <https://chromestatus.com/feature/5170361717489664> > > Specification > > https://github.com/w3c/webappsec-permissions-policy/pull/482 > Any blockers for the PR to land? > > 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 > <https://www.w3.org/TR/CSP/#framework-directive-source-list> and > permitting ‘scheme + wildcard domain’ and ‘wildcard port’ in the allowlist. > > Specifically, this intent would adopt the definition of host-source > <https://www.w3.org/TR/CSP/#grammardef-host-source> and scheme-source > <https://www.w3.org/TR/CSP/#grammardef-scheme-source> instead of origin > <https://www.w3.org/TR/permissions-policy/#allowlists> in the Allowlist > definition while requiring that the path-part > <https://www.w3.org/TR/CSP/#grammardef-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 > > Blink>PermissionsAPI > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPermissionsAPI> > > > Motivation > > The Permissions Policy specification > <https://w3c.github.io/webappsec-permissions-policy/> “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 > <https://www.w3.org/TR/CSP/#framework-directive-source-list> 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 > Not necessarily a blocker to shipping IMO, but Anne raised a few reasonably-looking issues on CSP related to this feature's integration with it. > > Debuggability > > Future work might flag syntax errors in the Issues tab > <https://docs.google.com/document/d/1lDEvj8tMeuvUs1HTTqL-44YiI-7ljeQkusM_WhUfIeE/edit> > . > > Is this feature fully tested by web-platform-tests? > > No, but it will be. > > Tracking bug > > https://crbug.com/1418009 > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5170361717489664 > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJRu2--NqZdPKjeF9HRc%3DcQaNFxCpYb%3DUvfsmperXPTFg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVR6OmesGGUYJWOva0hNOerOPiW9gbfLDF%2B5FuN%2B_o4TA%40mail.gmail.com.
