The PR needs to be updated to depend on CSP logic but I don't want to make that change until this expansion of wildcard support is approved and launched with some WPTs. It'll require making changes to the CSP spec itself and it all feels a bit too speculative until the launch in chrome is unblocked.
On Wed, Apr 5, 2023, 4:57 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > > > 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/CAGpy5DJFgJDqc7vzF_7TFd_Eh7sm5rbCfKi9bqP_a4Am5Cwm_Q%40mail.gmail.com.
