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.

[Jeffrey Yasskin]

This all makes sense to me. I don't personally have a good sense of the privacy implications of calling this, but that's a question for the privacy reviewers, not me. :) I'm torn on the question of when to make it easier for sites to pick their issuers. The overall TAG sense was that because this makes the risk worse, you should add the easier mitigation before shipping this change. But you have more experience with the particular users of this API, so it could be that you're right to want to wait for those users to complain. Is there a good issue for them to comment on if they run into this problem, so you can notice and fix it quickly? I think it'd be reasonable for the API owners to let this ship given a good way to catch if it breaks anything.

The TAG also requested that you ask the Privacy WG to review the PST API, to get some non-Google validation that there aren't any privacy reasons to avoid loosening the permission policy. I wouldn't expect the API owners to insist that shipping wait for the Privacy WG.

For the thread's information, I also got a request to help PSTs move into a WG, as the launch process requires we do, and we're figuring out what shape that should take.

Jeffrey

[Alexandre Nderagakura]

Trying to understand this discussion, the Issue 990 design revue in w3ctag and the privacy side (I put a comment in the Issue 306 but perhaps talking is here is better) :

• In case of the user denies giving consent to X vendors / tech via the CMP (Consent Management Platform), will the token be shared cross site if a wildcard is set anyway? The question also works with the Global privacy control
• Is there a way to prevent any adtech to redeem the token to display an ads anywhere outside? (But I think this question is already in the blink discussion)
• Not related but somehow related, if the token is considered First party tracking (Potential risk noted in the spec) then combined with the wildcard, you have a cross site tracking : How to prevent that?

[Ari Chivukula]

• In case of the user denies giving consent to X vendors / tech via the CMP (Consent Management Platform), will the token be shared cross site if a wildcard is set anyway? The question also works with the Global privacy control

I think this is unrelated to the work here as that's a question about how any permissions policy would work with CMP/GPC, and not this specific change.

• Is there a way to prevent any adtech to redeem the token to display an ads anywhere outside? (But I think this question is already in the blink discussion)

I'm having trouble parsing the question, but if the question is whether adtech could redeem a token and then later take action based on past redemption the answer is yes as long as it's the same context storage wise (otherwise there wouldn't be a way to know a past redemption had occured).

• Not related but somehow related, if the token is considered First party tracking (Potential risk noted in the spec) then combined with the wildcard, you have a cross site tracking : How to prevent that?

The first-party tracking potential you link to isn't about third-parties accessing data but first-parties reading the redemption records (this is only available in a top-level frame). The mitigation described in the explainer still applies as this change does not impact the availability of redemption records.

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

[Chris Harrelson]

LGTM1

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKLGRyeE9SCYuxyRG0DSLvzzX9qT4%3Dz3MtXW37Ki_9JsA%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

How likely are we to get multiple 3Ps on the page with each using its own issuer?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoav Weiss (@Shopify)]

LGTM2

At the API owner meeting, Jeffrey explained to me that the issuers are controlled by the top-level, so I'm comfortable with the model (and the fact that ad providers won't fight for the 2 slots in ways that the site owner can't control).

[Vladimir Levin]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKLGRyeE9SCYuxyRG0DSLvzzX9qT4%3Dz3MtXW37Ki_9JsA%40mail.gmail.com.

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/99634aa5-7264-44b3-9eaa-8b1506853126n%40chromium.org.