LGTM1 On Friday, June 9, 2023 at 8:04:29 PM UTC+2 Ari Chivukula wrote:
> Done > https://github.com/WebKit/standards-positions/issues/51#issuecomment-1584956430 > > On Fri, Jun 9, 2023, 1:57 PM Rick Byers <rby...@chromium.org> wrote: > >> 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/55555aaa-7ff3-43aa-a771-9ba4774d03bbn%40chromium.org.
