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-dX%3DLnTHidxrMLjQQJfGK5qXHCRnnoQZ6YSa7Dgg6e_qhsQ%40mail.gmail.com.
