Hi Ari, Given the discussion on your other intent <https://groups.google.com/a/chromium.org/g/blink-dev/c/f28WWMD8HVE/m/xCrQN-8hAgAJ>, can you try to get spec PRs and WPTs landed for this before shipping this too?
Thanks, Rick On Wed, Apr 12, 2023 at 12:06 PM Ari Chivukula <aric...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJ%2Bhr8chAOPiTvaSwYzJF%2B2A1ZiVG7CUR3scv1DgEreag%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/CAFUtAY_DK1NSVLrA4gMTFHmgiDVUV6iU4WKu2ZbZdicaHbhEug%40mail.gmail.com.
