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 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 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.
