Could you flip the required review bits in the chromestatus tool? On Monday, September 9, 2024 at 2:58:19 PM UTC+2 Ari Chivukula 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/27d1a149-24a0-4ca3-91ad-96f6e065466cn%40chromium.org.
