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 <https://github.com/w3ctag/design-reviews/issues/990> 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 <https://github.com/w3ctag/design-reviews/issues/990>, 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 <https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship:~:text=If%20your%20specification%20is%20still%20in%20an%20incubation%20venue%20and%20not%20a%20working%20group%2C%20propose%20that%20the%20feature%20migrate%20to%20a%20working%20group.>, and we're figuring out what shape that should take. Jeffrey On Thu, Oct 3, 2024 at 11:37 AM Ari Chivukula <aric...@chromium.org> wrote: > 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 > <https://github.com/WICG/trust-token-api/issues/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 > <https://github.com/GoogleChrome/private-tokens/blob/main/PST-Registration.md> > 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) > > > On Wed, Oct 2, 2024 at 4:51 PM Ari Chivukula <aric...@chromium.org> wrote: > >> 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) >> >> >> On Wed, Sep 11, 2024 at 3:52 PM Jeffrey Yasskin <jyass...@chromium.org> >> wrote: >> >>> 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 >>> >>> On Mon, Sep 9, 2024 at 5:58 AM Ari Chivukula <aric...@chromium.org> >>> wrote: >>> >>>> Contact emails >>>> >>>> aric...@chromium.org, kaustub...@chromium.org, sval...@chromium.org, >>>> ayk...@google.com, nick...@google.com >>>> >>>> Specification >>>> >>>> https://github.com/WICG/trust-token-api/pull/306 >>>> >>>> Summary >>>> >>>> Access to the Private State Token API >>>> <https://wicg.github.io/trust-token-api/> is gated by Permissions >>>> Policy <https://www.w3.org/TR/permissions-policy/> features. We >>>> proposed to update the default allowlist >>>> <https://w3c.github.io/webappsec-permissions-policy/#policy-controlled-feature-default-allowlist> >>>> for both `private-state-token-issuance >>>> <https://wicg.github.io/trust-token-api/#policy-controlled-feature-private-state-token-issuance>` >>>> and `private-state-token-redemption >>>> <https://wicg.github.io/trust-token-api/#policy-controlled-feature-private-state-token-redemption>` >>>> features from self to * (wildcard). >>>> >>>> >>>> Blink component >>>> >>>> Blink>StorageAccessAPI >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> >>>> >>>> >>>> Motivation >>>> >>>> The Private State Tokens API <https://wicg.github.io/trust-token-api/> >>>> has received recurring feedback from developers >>>> <https://github.com/WICG/trust-token-api/issues/106> 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 >>>> <https://wicg.github.io/trust-token-api/#issuer-exhaustion>. >>>> >>>> Competing scripts might race to call hasPrivateToken to ensure their >>>> preferred issuer enters the issuerAssociations >>>> <https://wicg.github.io/trust-token-api/#issuerassociations> map >>>> <https://infra.spec.whatwg.org/#ordered-map> before the issuer of >>>> others given a limit of two per top-level origin >>>> <https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-origin>. >>>> To control this process, the top-level origin >>>> <https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-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 >>>> <https://chromestatus.com/metrics/feature/timeline/popularity/3277> >>>> 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 >>>> <https://github.com/mozilla/standards-positions/issues/1066> >>>> >>>> WebKit: Position Requested >>>> <https://github.com/WebKit/standards-positions/issues/391> >>>> >>>> Web developers: Positive >>>> <https://github.com/WICG/trust-token-api/issues/106> >>>> >>>> Debuggability >>>> >>>> Storage written can be examined in devtools. >>>> >>>> Is this feature fully tested by web-platform-tests? >>>> >>>> Yes >>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/trust-tokens/> >>>> >>>> Tracking bug >>>> >>>> https://issues.chromium.org/353738486 >>>> >>>> Link to entry on the Chrome Platform Status >>>> >>>> https://chromestatus.com/feature/5205548434456576 >>>> >>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DL2enC2Q1vYBb%2BKA-O3aYW-a3bcvpWnU12NdAvQT6eUcg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXkS9mOzPi_oe67V9DqDsg4sij4mQKzoo4cQYTsLERbnTw%40mail.gmail.com.
