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/CAGpy5DKTMRfoGvk5a11yNN%3D%3D1WSdZo4HLmEjs4HayEoqoEZWEw%40mail.gmail.com.
