Private State Tokens

Implementation status

What are Private State Tokens?

   

Private State Tokens enable trust in a user's authenticity to be conveyed from one context to another, to help sites combat fraud and distinguish bots from real humans—without passive tracking.

  • An issuer website can issue tokens to the web browser of a user who shows that they're trustworthy, for example through continued account usage, by completing a transaction, or by getting an acceptable reCAPTCHA score.
  • A redeemer website can confirm that a user is not fake by checking if they have tokens from an issuer the redeemer trusts, and then redeeming tokens as necessary.

Private State Tokens are encrypted, so it isn't possible to identify an individual or connect trusted and untrusted instances to discover user identity.

Why do we need Private State Tokens?

The web needs ways to establish and convey trust signals which show that a user is who they say they are, and not a bot pretending to be a human or a malicious third-party defrauding a real person or service. Fraud protection is particularly important for advertisers, ad providers, and CDNs.

Unfortunately, many existing mechanisms to gauge and propagate trustworthiness—to work out if an interaction with a site is from a real human, for example—take advantage of techniques that can also be used for fingerprinting. Mechanisms to convey trust must preserve privacy, enabling trust to be propagated across sites without individual user tracking.

With the Private State Token API, a website can issue cryptographic tokens to a user it trusts, which can later be used elsewhere. The tokens are stored securely by the user's browser, and can then be redeemed in other contexts to confirm the user's authenticity. This allows trust of a user on one website (such as a social media site or email service) to be conveyed to another website (such as a publisher or online store) without identifying the user or linking identities across sites.

How do Private State Tokens work?

In this example a publisher website wants to check if a user is a real human, and not a bot, before displaying an ad.

  1. A user visits a website (known as an issuer) and performs actions that lead the site to believe that the user is a real human, such as making purchases, using an email account or successfully completing reCAPTCHA.
  2. The issuer site uses the Private State Token JavaScript API to trigger a request for trust tokens for the user's browser.
  3. The issuer site responds with token data.
  4. The user's browser securely stores data for the trust token.
  5. The user visits a different website (such as a news publisher) that wants to verify if the user is a real human: for example, when displaying ads.
  6. The site uses the Private State Token API to check if the user's browser has trust tokens stored for issuers that the site trusts.
  7. Private state tokens are found for the issuer the user visited previously.
  8. The publisher site makes a request to the issuer to redeem the trust tokens.
  9. The issuer site responds with a Redemption Record.
  10. The publisher site makes a request to an ad platform, including the Redemption Record to show that the user is trusted by the issuer to be a real human.
  11. The ad platform provides the data required to display an ad.
  12. The publisher site displays the ad.
  13. An ad view impression is counted.

Is tooling available for Private State Tokens?

Chrome DevTools turns on inspection from the Network and Application tabs. Read more about this DevTools integration and about Private State Tokens.

How do websites handle tokens from multiple trusted issuers?

The site can check a user's browser for valid tokens with document.hasTrustToken() for one issuer at a time. If this returns true and a token is available, the site can redeem the token and stop looking for other tokens.

The website must decide which token issuers to check and in what order.

Use cases

Private State Tokens (PST) support a range of anti-fraud use cases. At its core, PST can act as an additional trust signal because the API is able to encode pieces of information that can help convey trust from one context to another. As third-party cookies go away, we recognize that it will be critical to make sure that use cases such as the following can still function as needed. All of the PST use cases require both issuers and redeemers to work together. You may like to consider PST if you have use cases similar to any of the following:

  • Anti-fraud services: Preventing fraud is a legitimate use case that the web should support, but it shouldn't require a stable, global, per-user identifier. In third-party contexts, PST can be used for segmenting users into trusted and untrusted sets.
  • Analyzing ad fraud: PST can be useful for analyzing fraudulent clicks, impressions, and bot schemes in ad tech services.
  • Bot detection: After you run your analysis on whether a browser is a bot or not, PST can help encode that information to be shared from one context to another.
  • Secure payments: To detect threats that are harder to identify in a third-party context with limited information (like carding), PST can be used as an additional signal to convey trust.
  • Anti-abuse services in ecommerce: Detecting bots in ecommerce interactions (clicks, checkout, purchase, product ratings, chat bots, returns) is very important to avoid page scraping and non-human interactions. This can be an important additional signal to detect automated agents for third-party anti-fraud providers in ecommerce platforms.
  • CDN services: PST provide a mechanism to aid in the reporting and detection of fraudulent traffic.

This list of use cases is not an exhaustive list of all anti-fraud capabilities that may benefit from Private State Tokens. The list is also not mutually exclusive, PST may benefit multiple anti-fraud workflows.

User journeys

Issuance and redemption are the key components of Private State Tokens. While the previous use cases are the key areas where PSTs would be supported, you can think about the following moments in certain user journeys as the instances where you would actually want to issue or redeem tokens:

  • Issue tokens during Account Management Flows (Login, Sign up, Password Reset, and so on)
  • Issue tokens after confirming a multi-factor authentication (MFA)
  • Issue tokens after high risk actions such as deleting payment history
  • Redeem tokens for cross-site confirmation before moderate risk actions
  • Redeem tokens for cross-site confirmation before high risk actions

Engage and share feedback

Find out more