Trying to understand this discussion, the Issue 990 design revue in w3ctag <https://github.com/w3ctag/design-reviews/issues/990> and the privacy side (I put a comment in the Issue 306 <https://github.com/WICG/trust-token-api/pull/306#issuecomment-2449585140> 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 <https://github.com/WICG/trust-token-api/blob/main/README.md#first-party-tracking-potential>) then combined with the wildcard, you have a cross site tracking : How to prevent that? On Wednesday, October 23, 2024 at 1:41:52 AM UTC+2 Jeffrey Yasskin wrote: > 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 <ari...@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 <ari...@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 <jyas...@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 <ari...@chromium.org> >>>> wrote: >>>> >>>>> 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 >>>>> <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+...@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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a4f1c03c-80af-46bd-843c-a1385d2e4030n%40chromium.org.
