#990: FYI Private State Token API Permissions Policy Default Allowlist Wildcard

Visit on Github.

Opened Sep 9, 2024

こんにちは 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).

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: https://github.com/w3ctag/design-reviews/issues/414

Discussions

2024-10-14

Minutes

Not clear that this is OK, but the problems are likely inherent, rather than a result of this change.

Consider asking for privacy review to validate the claim that calling this API doesn't have a significant privacy cost.

2024-10-14

Minutes

Postponed to Breakout B.

2024-10-21

Minutes

Martin: the race on picking the 2 issuers gets worse with this change, so this would be a good time to insist on finding a better way for the top-level page to pick its issuers.

There is a set of entities that can run script. That set is probably smaller than the set of entities that might get framed in. Therefore, this change increases the by-default exposure of a page to entities that might "use up" its limit of 2 token-issuing origins.

Jeffrey: Last week we said we should ask them to get a privacy review.

satisfied with concerns:

<blockquote>

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?

</blockquote>