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).
On Wednesday, November 6, 2024 at 4:15:09 PM UTC+1 Yoav Weiss wrote: > How likely are we to get multiple 3Ps on the page with each using its own > issuer? > > On Wednesday, November 6, 2024 at 1:19:49 AM UTC+1 Chris Harrelson wrote: > >> LGTM1 >> >> On Thu, Oct 31, 2024 at 8:59 AM Ari Chivukula <aric...@chromium.org> >> wrote: >> >>> >>>> - 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 >>>> >>>> <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? >>>> >>>> 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) >>> >>> >>> On Thu, Oct 31, 2024 at 7:04 AM Alexandre Nderagakura < >>> nderale...@gmail.com> wrote: >>> >>>> 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/CAGpy5DKLGRyeE9SCYuxyRG0DSLvzzX9qT4%3Dz3MtXW37Ki_9JsA%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKLGRyeE9SCYuxyRG0DSLvzzX9qT4%3Dz3MtXW37Ki_9JsA%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/99634aa5-7264-44b3-9eaa-8b1506853126n%40chromium.org.
