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.
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-dXk9f78PkydAgJOKnfpgD4zYDiOajmETdQs6WARS50cSaw%40mail.gmail.com.
