Intent to Prototype & Ship: Private State Token API Permissions Policy Default Allowlist Wildcard

[Ari Chivukula]

Contact emails

ari...@chromium.org, kaust...@chromium.org, sva...@chromium.org, ayk...@google.com, nic...@google.com

Specification

https://github.com/WICG/trust-token-api/pull/306

Summary

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

Blink component

Blink>StorageAccessAPI

Motivation

The Private State Tokens API has received recurring feedback from developers that the current requirement to have first-party sites opt-in to allow third-parties to invoke token issuance and redemption operations is not practical. This is especially true for use cases where embeds don’t have first-party script access to either execute the operations directly in first-party context, or to enable the permission policies on the relevant frames. Current default requires every site to update permission policy for iframes that embed invalid traffic (IVT) detection scripts.Since scale and coverage are of essence for IVT detection that rely on identifying outlier patterns; the need for coordination with first-parties places a high cost for successful adoption.

TAG review

https://github.com/w3ctag/design-reviews/issues/990

Compatibility

This will not break any existing Private State Token API usage as it only increases permissiveness. As usage increases, sites may need to consider the need to mitigate issuer exhaustion.

Competing scripts might race to call hasPrivateToken to ensure their preferred issuer enters the issuerAssociations map before the issuer of others given a limit of two per top-level origin. To control this process, the top-level origin could call hasPrivateToken up to twice before any other JavaScript is included to ensure their preferred issuers are available.

Few enough websites are using the API that we believe we can broaden the default permission set and not open any concerning new avenues of attack.

Interoperability

Gecko: Position Requested

WebKit: Position Requested

Web developers: Positive

Debuggability

Storage written can be examined in devtools.

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://issues.chromium.org/353738486

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5205548434456576

[Yoav Weiss (@Shopify)]

Could you flip the required review bits in the chromestatus tool?

[Ari Chivukula]

Done I think?

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

[Jeffrey Yasskin]

This Intent makes me realize that my mental model of Private State Tokens wasn't correct. I'd been thinking of users going to a site that trusts them, having that site issue some tokens, and then going to another site which would redeem a token to increase its trust. In both cases, the sites could rely on third-parties to handle the tokens, but the sites have intentional relationships with their service providers and so could enable them in the top-level Permission Policy.

This Intent implies that something else is going on, maybe multiple things.

1. https://github.com/WICG/trust-token-api/issues/106 says that adtech services want to redeem tokens without needing to get changes made on the top-level site. The request seems to say that it's the adtech origin that's directly called from the top-level site, but I think this change would allow redemptions anywhere down the tree of ad-related frames? 

  * Is there any risk of an ad redeeming tokens to interfere with other ads? https://github.com/WICG/trust-token-api?tab=readme-ov-file#private-state-token-exhaustion says only 1 token is redeemed per top-level page visit, which prevents the ad from deliberately using up the user's tokens, but it could still race to prevent any other ad from knowing to trust the user.

2. This intent also expands which origins can _issue_ tokens, but I don't see the justification for that in the issue. What circumstances need that?

There's some privacy impact from using this API. The tight default permission policy meant that top-level sites had to explicitly ask to expose their users to that privacy impact. Without it, shouldn't we expect lots of embedded resources to try to learn whatever information they can using this API? Why is that extra risk good for users overall?

I don't find the "the top-level origin could call hasPrivateToken up to twice before any other JavaScript is included" mitigation plausible: folks often don't control the order of their Javascript that closely. It seems more likely that sites would just explicitly set the permission policy to the origins they trust to pick their issuers: is there a reason that's not an adequate defense?

But then you've still just switched the burden from sites that want to delegate use of this API, to sites that need to defend against hostile use of the API. Can you share any analysis of why you think attacks will be much less likely than uses, or some other reason that it's good for users and sites to switch that burden?

Thanks,

Jeffrey

--
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/CAGpy5DL2enC2Q1vYBb%2BKA-O3aYW-a3bcvpWnU12NdAvQT6eUcg%40mail.gmail.com.

[Ari Chivukula]

These are good questions! Sorry for the delay in replying, now that TPAC has passed we should have something soon.

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

[Ari Chivukula]

Divided Jeffrey's email to separate questions verbatim (italic font). Our responses are below the question (bold font). 

1. https://github.com/WICG/trust-token-api/issues/106 says that adtech services want to redeem tokens without needing to get changes made on the top-level site. The request seems to say that it's the adtech origin that's directly called from the top-level site, but I think this change would allow redemptions anywhere down the tree of ad-related frames? 

Yes, this change would allow redemptions anywhere down the tree of frames regardless of origin unless explicit Permissions-Policies/allow-attributes block them (7).

  * Is there any risk of an ad redeeming tokens to interfere with other ads? https://github.com/WICG/trust-token-api?tab=readme-ov-file#private-state-token-exhaustion says only 1 token is redeemed per top-level page visit, which prevents the ad from deliberately using up the user's tokens, but it could still race to prevent any other ad from knowing to trust the user.

Yes, an ad redeeming a token may interfere with other origins' capabilities, as that redemption operation associates the issuer with the top level origin. And this counts towards the issuer limit. At most 2 issuers per top level origin is allowed. See step 4 in algorithm (1). Associating an issuer with the top level origin occupies a slot. Once an ad redeems a token, only one issuer slot is left for all others in the same top level page.

Following a successful redemption, a redemption record (3) is stored, step 14 in algorithm (2). Redemption records are keyed by (issuer, toplevel) origin pair. Any other origin in the page trying to redeem a token from the same issuer will get this cached redemption record.

Put another way, ads can’t ‘use up’ tokens that other ads on the page want to redeem, because those other ads would just re-use the same redemption record.

The explainer text is not in the best shape, created issue #307 to fix this. 

2. This intent also expands which origins can _issue_ tokens, but I don't see the justification for that in the issue. What circumstances need that?

Yes, you are correct that the particular request cited here is pertaining to redemption operations. However, we are aware that many anti-fraud vendors are only embedded in 3p contexts, without necessarily having script access on the top-level site. Vendors who currently rely on third-party cookies to establish and convey trust will need commensurate permissions on both redemption and issuance sides.

There's some privacy impact from using this API. The tight default permission policy meant that top-level sites had to explicitly ask to expose their users to that privacy impact. Without it, shouldn't we expect lots of embedded resources to try to learn whatever information they can using this API? Why is that extra risk good for users overall?

We see this is a key tradeoff that many third-party cookie replacement APIs have to contend with. Given the widespread reliance on third-party cookies, it may not be practical to have anti-fraud vendors to work with every publisher/page to update their permission policy for the frames they have. Usefulness of the signal depends on its availability.

Further, the extra risk is actually very small: it's not going to affect users' privacy if anyone can learn that they've visited 2 particular issuers and the 6 bits those issuers want to convey about them. In fact, the privacy risk is decreased by allowing 3p issuers to send that information, because it limits the inference about which sites a user has actively visited.

Note that the information embedded resources can learn are constrained by limiting information content stored in a token (4) and limiting the number of issuers per page (5). Additionally, PST issuers are expected to register on GitHub with some transparency on how they’re using the tokens.

I don't find the "the top-level origin could call hasPrivateToken up to twice before any other JavaScript is included" mitigation plausible: folks often don't control the order of their Javascript that closely. It seems more likely that sites would just explicitly set the permission policy to the origins they trust to pick their issuers: is there a reason that's not an adequate defense?

Permission policy can certainly be used, but it does not prevent third-party scripts embedded on the top-level context from picking their own issuers. The hasPrivateToken method overcomes that issue. 

For the general case, the JS API method mitigates most cases, but we have heard that folks would like a more explicit way of doing this, either as a meta tag or header that can be sent by the server since the JS inclusion order and complexities with single page sites means that this is a little fragile if it's not the earliest executed JS.

While we could add a new meta-tag/header feature to control issuance origins and then change the policy to default to *, given the low usage and (in our estimation) the low risk of changing the policy default we would prefer to pursue this change and follow up if requested by clients.

But then you've still just switched the burden from sites that want to delegate use of this API, to sites that need to defend against hostile use of the API. Can you share any analysis of why you think attacks will be much less likely than uses, or some other reason that it's good for users and sites to switch that burden?

While it could be viewed as a “burden switch”, the fundamental privacy properties of PSTs mentioned above are such that the vast majority of sites shouldn’t have cause to be concerned. For sites that are looking to prevent any cross site communication, the permission policy remains available.  

References

1. https://wicg.github.io/trust-token-api/#append-private-state-token-redemption-request-headers

2. https://wicg.github.io/trust-token-api/#handle-a-redeem-response

3. https://wicg.github.io/trust-token-api/#redemption-record

4. https://wicg.github.io/trust-token-api/#limit-encoded-info

5. https://wicg.github.io/trust-token-api/#per-issuer-limits

6. https://github.com/WICG/trust-token-api/issues/106

7. https://developer.mozilla.org/en-US/docs/Web/HTTP/Permissions_Policy#allowlists

8. https://chromestatus.com/metrics/feature/timeline/popularity/3276

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

[Jeffrey Yasskin]

FYI, I'll be on vacation for the next week, so I won't be able to actually think about this, but thanks for the detailed response.