Wotcher TAG!

I'm requesting a TAG review of Wildcards in Permissions Policy Origins.

INITIAL PROPOSAL

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.

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" "https://foo.cdn2.foo.com/")

With this feature, it could look like: permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://*.foo.com")

EXPANDED PROPOSAL

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 and permitting ‘scheme + wildcard domain’ and ‘wildcard port’ in the allowlist.

Specifically, this intent would adopt the definition of host-source and scheme-source instead of origin in the Allowlist definition while requiring that the 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:*”.

• Explainer: https://docs.google.com/document/d/1HtkQivbjO6TiP6uZdTt4KmTnWzbs5IZpEdrz59-fyYU/edit
• Specification URL: https://w3c.github.io/webappsec-permissions-policy/
• Tests:
  • WPT will be added
• Security and Privacy self-review: See below
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/webappsec-permissions-policy/
• Primary contacts (and their relationship to the specification):
  • Ari Chivukula (@arichiv - contributor)
  • Mike Taylor (@miketaylr - contributor)
• Organization(s)/project(s) driving the specification: Chromium
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Akamai’s request: https://github.com/w3c/webappsec-permissions-policy/issues/479
  • https://github.com/mozilla/standards-positions/issues/679
  • https://github.com/mozilla/standards-positions/issues/760
  • https://github.com/WebKit/standards-positions/issues/51
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://crbug.com/1345994
  • https://crbug.com/1418009
  • https://chromestatus.com/feature/5170361717489664
  • https://chromestatus.com/feature/5101218029895680
  • https://groups.google.com/a/chromium.org/g/blink-dev/c/biH6g79KclA
  • https://groups.google.com/a/chromium.org/g/blink-dev/c/kSknKkiYlZU

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the work on this specification is currently being done: W3C
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): N/A
• Major unresolved issues with or opposition to this specification: N/A
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Security and Privacy questionnaire for TAG

1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

• N/A, this feature exposes no new information to websites or other parties.

2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

• Yes, no new information is exposed.

3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

• It does not deal directly in PII.

4. How do the features in your specification deal with sensitive information?

• It does not handle sensitive information.

5. Do the features in your specification introduce new state for an origin that persists across browsing sessions?

• No, permissions must be delegated on each page load and do not persist.

6. Do the features in your specification expose information about the underlying platform to origins?

• Yes, but no more than the existing permissions delegation can.

7. Does this specification allow an origin to send data to the underlying platform?

• Yes, but no more than the existing permissions delegation can.

8. Do features in this specification enable access to device sensors?

• Yes, but no more than the existing permissions delegation can.

9. What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.

• Data that can already be delegated by permissions is exposed, there is no new data being exposed.

10. Do features in this specification enable new script execution/loading mechanisms?

• No

11. Do features in this specification allow an origin to access other devices?

• Yes, but no more than the existing permissions delegation can.

12. Do features in this specification allow an origin some measure of control over a user agent’s native UI?

• No

13. What temporary identifiers do the features in this specification create or expose to the web?

• Nothing beyond what's currently possible with permissions delegation.

14. How does this specification distinguish between behavior in first-party and third-party contexts?

• The first-party context is in charge of which permissions are delegated to third-party contexts, and third-parties cannot increase their scope of delegated permissions.

15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

• It will work the same in such contexts.

16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

• Yes. https://w3c.github.io/webappsec-permissions-policy/#privacy-and-security

17. Do features in your specification enable origins to downgrade default security protections?

• No

18. How does your feature handle non-"fully active" documents?

• N/A

19. What should this questionnaire have asked?

• N/A