FYI Private State Token API Permissions Policy Default Allowlist Wildcard

[arichiv]

こんにちは TAG-さん!

I'm requesting a TAG review of Private State Token API Permissions Policy Default Allowlist Wildcard.

Access to the Private State Token API is gated by Permissions Policy features. We proposed to update the default allowlist for both private-state-token-issuance and private-state-token-redemption features from self to * (wildcard).

• Explainer: https://github.com/WICG/trust-token-api/blob/main/README.md
• Specification: Consider making permission defaults * instead of self WICG/trust-token-api#306
• WPT Tests: https://github.com/web-platform-tests/wpt/tree/master/permissions-policy
• User research: Consider dropping the 'trust-token-redemption' feature policy? WICG/trust-token-api#106
• Security and Privacy self-review: https://docs.google.com/document/d/1KPa5OQtp-n6wmf5PTDNSd-pGP993sOtZfl0LbT5fopk/edit#heading=h.95atawj7yqzu
• GitHub repo: https://github.com/WICG/trust-token-api/tree/
• Primary contacts:
  • @arichiv, Google Chrome
  • @aykutbulut, Google Chrome
  • @dvorak42, Google Chrome
  • @krgovind, Google Chrome
• Organization/project driving the specification: Google Chrome
• Multi-stakeholder support:
  • Chromium comments: https://issues.chromium.org/u/1/issues/353738486
  • Mozilla comments: FYI Private State Token API Permissions Policy Default Allowlist Wildcard mozilla/standards-positions#1066
  • WebKit comments: FYI Private State Token API Permissions Policy Default Allowlist Wildcard WebKit/standards-positions#391
• Status/issue trackers for implementations: https://chromestatus.com/feature/5205548434456576

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: None
• The group where the work on this specification is currently being done: WICG
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Google Chrome

Past Evaluation: #414

[jyasskin]

I left some questions in https://groups.google.com/a/chromium.org/g/blink-dev/c/5jI8kLLdIFw/m/_810WhKGAwAJ, and we should wait for a reply before discussing in the TAG.

[martinthomson]

We discussed this in a breakout and have a couple concerns:

• This change increases the by-default exposure of the page to entities that might "use up" its limit of 2 issuers. You've suggested that the top-level page should call the API to explicitly pick its issuers, before allowing 3p script to run. We're skeptical that that's a practical defense. You're right that it's a pre-existing issue with the API, but because this change makes the risk worse, it would be good to improve the defense before making this change.

• We're not the right body to judge whether the privacy implications are reasonable. Could you ask the Privacy WG to review this system?