Code and WPTs shipped here: https://chromium-review.googlesource.com/c/chromium/src/+/4555927
Spec shipped here: https://github.com/w3c/webappsec-permissions-policy/pull/516 ~ Ari Chivukula (Their/There/They're) On Wed, Apr 19, 2023 at 12:05 PM Rick Byers <rby...@chromium.org> wrote: > 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/CAGpy5DKABuNRLyeJxien2Pj%2BLzgEH6yFfxxLK5-DZ73zJOmqow%40mail.gmail.com.
