On Fri, Aug 26, 2022 at 7:27 PM Ari Chivukula <aric...@chromium.org> wrote:
> Contact emails > > aric...@chromium.org, miketa...@chromium.org > > Design Doc > > > https://docs.google.com/document/d/1HtkQivbjO6TiP6uZdTt4KmTnWzbs5IZpEdrz59-fyYU/edit > > Specification > > https://github.com/w3c/webappsec-permissions-policy/issues/479 > > Summary > > This feature will add support for wildcard 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 requires that HOST is at least eTLD+1 (a > registrable domain). This means that https://*.bar.foo.com/ works but > https://*.com/ won’t (if you want to allow all domains to use the > feature, you should just delegate to *). Wildcards in the scheme and port > section will be unsupported and https://*.foo.com/ does 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";) > > With this feature, it could look like: > > permissions-policy: ch-ua-platform-version=(self "https://foo.com"; > "https://*.foo.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. > > 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 subdomains and > include the wildcard in the permissions policy. > > > Interoperability > > We would be the first to implement if approved. > > > > Gecko: Will ask > > > > WebKit: Will ask > Links to signal requests? > > > Web developers: > https://github.com/w3c/webappsec-permissions-policy/issues/479 > <https://github.com/WICG/client-hints-infrastructure/issues/108> > > 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/1345994 > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5170361717489664 > > ~ Ari Chivukula (Their/There/They're) > > -- > 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/CAGpy5DLDbhOMWugyzXTKsvjH6koO8g7sV7eg_NQgq0GZeCOQ1A%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DLDbhOMWugyzXTKsvjH6koO8g7sV7eg_NQgq0GZeCOQ1A%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/CAL5BFfVmqsva_4%2BrEMf%2BPoX4Bce%2Bg4yLrW7CiQKY63YUat5oGQ%40mail.gmail.com.
