Thanks Ari, looks great! Can you also please post an update to the WebKit positions threads <https://github.com/WebKit/standards-positions/issues/51#issuecomment-1470519891>? I see you've landed fixes in CSP for 2 of the 3 issues Anne filed (great!), but it would be good to know if WebKit folks still feel the state of integration with CSP is such that they can't support this yet. Of course we can choose to disagree, we should just be clear about where any disagreement is.
Thanks, Rick On Fri, Jun 9, 2023 at 12:05 PM Ari Chivukula <aric...@chromium.org> wrote: > 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/CAFUtAY9dHeY46nyy_BiSmPjGw5jUEio1sb3Qz3Bimf32d3Gw-g%40mail.gmail.com.
