Intent to Prototype & Ship: Wildcards in Permissions Policy Origins

[Ari Chivukula]

Contact emails

ari...@chromium.org, mike...@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

 

Motivation

The Permissions Policy specification “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

 

Web developers: https://github.com/w3c/webappsec-permissions-policy/issues/479

Debuggability

Future work might flag syntax errors in the Issues tab.

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)

[Yoav Weiss]

Links to signal requests?

 

 

Web developers: https://github.com/w3c/webappsec-permissions-policy/issues/479

Debuggability

Future work might flag syntax errors in the Issues tab.

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

[Ari Chivukula]

Sorry about that:

https://github.com/mozilla/standards-positions/issues/679

https://github.com/WebKit/standards-positions/issues/51

~ Ari Chivukula (Their/There/They're)

[ayumi hamasaki]

The example in the description is a bit confusing found here: https://chromestatus.com/feature/5170361717489664

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")

```

One would think why not just write: `ch-ua-platform-version=(self "https://*.foo.com")` instead. As you're used `foo.com` twice!

----

Would it not be better to use `foo.com` and `example.com` instead e.g.

Before, a permissions policy might need to look like: 

```

permissions-policy: ch-ua-platform-version=(self "https://example.com" "https://cdn1.foo.com" "https://cdn2.foo.com") 

```

With this feature, it could look like: permissions-policy: 

```

ch-ua-platform-version=(self "https://example.com" "https://*.foo.com")

```

Which would make more sense.

[Ari Chivukula]

I'll add a note, but this is actually deliberate.

*.foo.com does not match foo.com.

~ Ari Chivukula (Their/There/They're)

[Mike Taylor]

We discussed this in the API OWNERS meeting today, and given that the TAG review issue was added to the TPAC milestone for next week, we'd like to wait a week or so to see if there is any useful feedback.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2BCusaFBxLhe930f_X%2BvisYes%3DQLOBB8VFevR804kcS_A%40mail.gmail.com.

[Ari Chivukula]

There was one comment on the TAG thread: https://github.com/w3ctag/design-reviews/issues/765#issuecomment-1245616454

Mozilla just published a positive position: https://github.com/mozilla/standards-positions/issues/679

~ Ari Chivukula (Their/There/They're)

[Chris Harrelson]

Hi Ari,

There were some questions on the TAG review about potential extensions to the syntax for additional use cases. Just checking: do you think the current design is forward-compatible with these use cases?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2Bqnrhs1j0YaFFHmJGCzzE2_YMW6yYe1QYX_PezNHWo2Q%40mail.gmail.com.

[Ari Chivukula]

I haven't seen the notes from the meeting (don't see them here: https://github.com/w3ctag/meetings/tree/gh-pages/2022/telcons), do you have a copy and/or can you describe the forward-compatible cases?

~ Ari Chivukula (Their/There/They're)

[Yoav Weiss]

Essentially, this comment suggested a negation syntax, which looks like a feature request, but may be good to ensure that the current parsing algorithm would enable such future extensions.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DL%2BnwnbfHJe5gk86LPjWEK%2BrjA37Pyv6m43zA418a6LrA%40mail.gmail.com.

[Ari Chivukula]

Ah, yes I responded to that comment and believe it would be possible to support that future extension without having to un-ship this version of wildcards.

~ Ari Chivukula (Their/There/They're)

[Chris Harrelson]

Great. LGTM1 then!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DL-%2BBuNvSh46_qWHeCi%3DwY4f_%2BRzA4MN73sx9hp55qBLg%40mail.gmail.com.

[Yoav Weiss]

LGTM2

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXpc5BWaf-bY_UVGn2qzAmzVndQeVswvNhOAFoaZz14ow%40mail.gmail.com.