[w3ctag/design-reviews] Wildcards in Permissions Policy Origins (Issue #765)

Wotcher TAG!

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

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.

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

- 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

  - Will reach out to Gecko
  - Will reach out to Webkit
- External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  - https://crbug.com/1345994


Further details:

- I have reviewed the TAG's [Web Platform Design Principles](https://w3ctag.github.io/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](https://w3c.github.io/webappsec-permissions-policy/) 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

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/765

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/765@github.com>