I don't have a draft of the CSP or Permissions Policy spec changes yet. There won't be any breaking changes for either needed, the change is to a superset of supported matching options for Permissions Policy.
~ Ari Chivukula (Their/There/They're) On Wed, Apr 5, 2023 at 11:22 AM Alex Russell <slightly...@chromium.org> wrote: > 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/CAGpy5DJ%2Bhr8chAOPiTvaSwYzJF%2B2A1ZiVG7CUR3scv1DgEreag%40mail.gmail.com.
