I'm not sure I understand this response. Do you have a draft change to the CSP spec posted someplace? Will that update be a breaking change to the wildcard support being requested for launch in this thread?
Best, Alex On Wednesday, April 5, 2023 at 6:29:27 AM UTC-7 Ari Chivukula wrote: > 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/89ff6938-466b-47fe-923b-3992dc322d0an%40chromium.org.
