v132 · network / connectivity

Private State Token API Permissions Policy Default Allowlist Wildcard

Access to the Private State Token API is gated by Permissions Policy features. We proposed to update the default allowlist for both `private-state-token-issuance` and `private-state-token-redemption` features from self to * (wildcard).

concepts

  1. PST Policy Default *

    Private State Token's default Permissions Policy allowlist becomes *. Explicit confirmation of the existing behaviour.

  2. embed rollout

    The publisher / fraud-vendor rollout that pre-132 took a month and 132+ takes a minute.

  3. policy explorer

    Type a Permissions-Policy header value; live table shows whether issuance and redemption are allowed for top, same-origin, and cross-origin iframes.

  4. Token flow simulator

    Walk a complete PST issuance + redemption flow from a cross-origin iframe context. Set a custom Permissions-Policy header (or leave blank for Chrome 132 defaults) and see each step succeed or fail — with a permission matrix comparing pre-132 (self) vs Chrome 132 (*) default allowlists.

why it shipped

The Private State Tokens API has received recurring feedback from developers 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 ar

references