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.
