LGTM2 On Wed, Jun 14, 2023 at 8:36 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/55555aaa-7ff3-43aa-a771-9ba4774d03bbn%40chromium.org?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/CAOMQ%2Bw98ZSrxe693vYKD0FFS%2BinG9pWRapCqui9CGCzT7XDUew%40mail.gmail.com.
