]> Google

philippp@gmail.com

Google

jkcrypto@google.com

Google

sauski@google.com

token anti-fraud Fraud detection often relies on high-entropy signals that can also be used to track users across sites. Probabilistic Reveal Tokens (PRTs) attempt to balance the needs of fraud detection and tracking prevention by sampling at a rate that is too low for scaled cross-site tracking, but sufficient for fraud detection in aggregate scenarios. This document describes the PRT protocol, which allows browsers to reveal sensitive signals (e.g., IP address) on a per-site basis with provable probability p_reveal, while websites can use PRTs to measure traffic quality and update denylists. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Cross-site tracking threatens user privacy, yet websites require access to certain signals for legitimate fraud detection and security purposes. IP addresses, in particular, serve as critical signals for identifying and mitigating fraudulent activity, but their universal availability enables large-scale tracking across websites. Probabilistic Reveal Tokens (PRTs) provide a solution that balances these competing needs. PRTs allow browsers to share sensitive signals with websites at a controlled probability rate that is too low for effective cross-site tracking but sufficient for aggregate fraud detection and analysis. The PRT protocol enables:

• Browsers to reveal sensitive signals on a per-site basis with provable probability p_reveal
• Websites to measure traffic quality for a sample of entities or combinations of entities
• Users to validate that the reveal rate is as expected after tokens have been spent
• Prevention of scaled cross-site tracking while preserving fraud detection capabilities

PRTs utilize ElGamal encryption with re-randomization properties to ensure that tokens remain unlinkable beyond the probabilistically-included high-entropy signals. Tokens are unforgeable while eligible to be spent and become refutable after the spending period (epoch) ends through the publication of decryption keys. This document specifies the PRT protocol, including token generation, transmission, validation, and the associated cryptographic operations. The protocol is designed to provide verifiable privacy properties while enabling legitimate fraud detection use cases.

Conventions and Definitions Key Coordinator: The entity that generates the cryptographic keypair necessary for token encryption and decryption, and is responsible for keeping the secret key material secret while tokens are eligible to be spent. This may be implemented as part of the Issuer. Epoch: A time period during which tokens are eligible to be spent by a browser. After the epoch ends, the Key Coordinator reveals the key material needed to decrypt and verify the tokens. This key material also allows anyone to generate tokens of this now-revealed epoch, creating deniability for token bearers. Embargo Period: An additional duration after the epoch has ended, and before keys are released. Without an embargo period, keys minted at the exact end of the epoch are at risk of having been minted with recently released keys. Issuer: An internet-facing service from which the browser fetches PRTs. The issuer computes an array of N = N_signal + N_NULL tokens (where N_signal tokens contain the signal, and N_NULL tokens do not) so that p_reveal = N_signal/N. The issuer shuffles these tokens and passes them to the browser. Browser: The client software that fetches tokens from the issuer, re-randomizes them to prevent linkability, and sends the tokens to websites. After the key material is published, the browser helps the user validate the privacy properties of the tokens. Website: The recipient of tokens from the browser. After the key material is published, websites validate the legitimacy of the tokens and leverage sampled signals. Signal: The sensitive data (such as an IP address) that is probabilistically included in tokens. p_reveal: The probability that any given token contains the signal rather than a NULL value. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Protocol Overview The PRT protocol involves four main participants: the Key Coordinator, Issuer, Browser, and Websites. The protocol operates in epochs, with each epoch having a defined start and end time. During each epoch:

1. The Key Coordinator generates an asymmetric keypair for ElGamal encryption
2. The Issuer generates a plaintext value containing signals with probability p_reveal, signs them with an HMAC key, and encrypts them using the public key to create tokens.
3. Browsers fetch token batches, re-randomize individual tokens, and send them to websites in HTTP headers
4. Websites store received tokens for later decryption

After the epoch ends and the embargo period has expired:

1. The Key Coordinator publishes the private key and HMAC secret
2. All parties can decrypt tokens and validate their contents
3. Users can verify the actual reveal rate matches the expected p_reveal
4. Websites can extract signals for fraud analysis

Trust Model The PRT protocol relies on the following trust relationships:

• Websites need to trust that the issuer is writing the correct signal into the token
• The issuer needs to independently establish trust in the signal
• Browsers must trust the issuer to correctly mint tokens for the duration of the epoch (i.e. until validation)

Protocol Requirements The protocol satisfies the following requirements:

• Ratio Inspection: Users MUST be able to verify the token reveal rate (p_reveal) after epoch completion.
• Content Inspection: Users MUST be able to verify after-the-fact that the tokens do not contain additional identifying information beyond the expected signal.
• Unlinkability: The website and issuer MUST NOT be able to re-identify the user (e.g., by colluding and matching tokens).
• Robustness: Browsers MUST NOT be able to intentionally reduce their aggregate token reveal rate below p_reveal, and websites MUST NOT be able to increase the likelihood of a browser revealing its signal.

Protocol Specification

Token Scope PRTs reduce access to re-identifiable information in the absence of other cross-visit identifiers. PRT implementations MUST allocate only one token to each website during a visit, where a visit is defined as a period during which the user expects to be re-identified by a website (e.g., a sequence of navigations or a cookied session). If this requirement is not met, a website could collect multiple tokens for the same user and the same signal, and increase their chance of recovering the signal beyond p_reveal.

Epochs and Sequencing Epochs SHOULD be approximately one day in length, but this is not required by the protocol. In practice, epochs SHOULD be long enough to avoid leakage through user re-identification within a browsing session, and short enough that the signal in the token is still likely to be valid. A minimum epoch length of four hours is RECOMMENDED. Each epoch MUST end after the following epoch has started. This allows browsers to start using tokens from the new epoch before the current epoch ends, avoiding both a lapse in the availability of valid tokens and a thundering herd problem when new tokens become available. The Key Coordinator SHOULD wait an additional embargo period after the epoch ends before revealing the keys. This ensures that any tokens sent at the end of an epoch cannot be decrypted shortly afterwards when the epoch changeover occurs. It is RECOMMENDED that the embargo duration be equal to that of the epoch length to ensure that no token can be decrypted sooner than one epoch duration in length regardless of when during an epoch it is sent to the website.

Token Generation

Cryptographic Parameters The following cryptographic parameters MUST be used:

• Elliptic Curve: secp256r1 (NIST P-256) as defined in
• Point Compression: All elliptic curve points MUST use compressed encoding as defined in
• HMAC Algorithm: HMAC-SHA256 as defined in
• HMAC Secret Length: 32 bytes (256 bits)
• Message Padding: 3 bytes appended for valid curve point encoding

Key Generation The Key Coordinator generates an asymmetric keypair (pk_e, sk_e) to be rotated every epoch E, with sk_e published to all participants after the epoch has ended. Key generation MUST follow these steps:

1. Generate a random private key x uniformly from [1, n-1] where n is the order of the secp256r1 base point
2. Compute the public key point Y = x * G where G is the secp256r1 generator point
3. The ElGamal public key pk_e consists of (G, Y)
4. The ElGamal private key sk_e is x

The public key pk_e is shared as a JSON Web Key (JWK) :

Token Structure The Issuer receives pk_e and generates an epoch-scoped secret S_e (32 bytes) that ensures only this issuer can mint tokens. When a browser requests a batch of N tokens, the Issuer constructs each token message with the following fixed structure: Field definitions:

• Version: MUST be set to 1 for this specification
• t_ord: Sequential ordinal from 1 to N (assigned before shuffling)
• signal: Either 16 zero bytes (NULL) or the actual signal
• H: First 8 bytes of HMAC-SHA256(S_e, Version || t_ord || signal)

Token Generation Algorithm When a browser requests a batch of N tokens, the Issuer:

1. Observes the signal (e.g., IP address) from the browser's connection
2. Determines N_signal = floor(N * p_reveal) and N_NULL = N - N_signal
3. For i = 1 to N: a. Set t_ord = i b. If i <= N_signal: set signal to the actual signal value c. If i > N_signal: set signal to a number of zero bytes which matches the signal size d. Construct message M_i as defined in Section 4.3.3 e. Compute HMAC-SHA256(S_e, Version || t_ord || signal) f. Set H to the first 8 bytes of the HMAC result
4. For each message M_i: a. Interpret the 26-byte message as a big-endian integer b. Left-shift the message by three bytes and increment the value of the three-byte padding until the (29-byte) padded message is a valid x-coordinate on the curve. c. Encrypt the point using ElGamal: (u, e) = (rG, M_point + rY) where r is a random scalar d. Serialize u and e using compressed point encoding
5. Shuffle the encrypted tokens with cryptographically secure randomness.
6. Provide the shuffled tokens to the browser along with pk_e, t_epoch_end, and t_next_epoch_start

Token Re-randomization and Spending

Re-randomization Algorithm To prevent linkability attacks, the browser MUST re-randomize each token before use. Re-randomization exploits the malleable property of ElGamal encryption to produce a new ciphertext that decrypts to the same plaintext but is unlinkable to the original ciphertext. Given an ElGamal ciphertext (u, e) where:

• u is a compressed elliptic curve point
• e is a compressed elliptic curve point

The browser re-randomizes by:

1. Parse u and e from their compressed encodings to curve points U and E
2. Generate a random scalar z uniformly from [1, n-1] where n is the order of the secp256r1 curve
3. Compute the re-randomized ciphertext:
   • U' = U + z * G
   • E' = E + z * Y where G is the generator point and Y is the public key point
4. Serialize U' and E' using compressed point encoding

The browser MUST re-randomize each token before it is used and each time the token is re-used to defend against linkability attacks. The browser maintains a local database with the following schema: Additional implementation-specific fields for token management: The context_id field defaults to NULL for new tokens and is set to an identifier of the context (e.g., the top-level domain name) when the token is spent. When the browser wishes to assert its willingness to probabilistically reveal a signal:

1. It checks for any token already assigned to the requesting context whose t_epoch_end has not passed
2. If such a token exists, the browser reuses it for this connection
3. If no such token exists, the browser assigns a non-spent, current-epoch token to the context by setting the context_id field
4. The assigned token is re-randomized and sent to the relevant party

Key Disclosure and Validation At the end of each epoch and after the embargo period has ended, the Key Coordinator MUST publish (pk_e, sk_e, S_e) as JSON Web Keys (JWKs). The ElGamal key is stored with key type "eg", where "x" and "y" hold the public key (pk_e) and "d" holds the secret key (sk_e). The HMAC secret S_e is stored as "hmac.k". All values are converted to big-endian byte arrays and base64url-encoded . Example key disclosure format: Users and websites can then:

1. Decrypt tokens using sk_e
2. Validate HMAC values using S_e
3. Verify that the distribution of t_ord values is uniformly distributed
4. Confirm that the actual reveal rate matches the expected p_reveal

HTTP Integration

HTTP Header Format PRTs are transmitted in the "Sec-Probabilistic-Reveal-Token" HTTP header . The header value is a Structured Header Byte Sequence containing a TLS Presentation Language serialized PRTStruct: Where:

• version identifies the token format version
• u and e are the ElGamal ciphertext components
• epoch_id identifies the corresponding key material for decryption

For version 1, u and e are each 33 bytes in length (compressed secp256r1 points).

Token Transmission Example HTTP header: Sec-Probabilistic-Reveal-Token: :AQAhA0YcSOPXwN8JkGJz2Rxe349sEOzwLcXnrU0/e5P1QUEEACECjvPnzEReeDlIkrDocZA5ZtiIptiG02YOOaNMJKyKZTdIXbE63QJtYA==: Browsers SHOULD include this header on requests where:

1. The request is being sent through a proxy for privacy purposes
2. The destination origin has registered to receive PRTs
3. A valid PRT is available for the current epoch

If no valid PRTs are available when composing a proxied request, the browser SHOULD make the request without the header. Well-behaved clients SHOULD only fail to attach a PRT in exceptional circumstances (e.g., Issuer unavailability).

Implementation Considerations

Epoch Length The epoch length affects both privacy and utility:

• Epochs SHOULD be long enough to prevent leakage through user re- identification within browsing sessions
• Epochs SHOULD be short enough that signals remain valid and users can verify issuer behavior in reasonable time
• A minimum epoch length of four hours is RECOMMENDED
• Typical implementations MAY use epoch lengths of approximately one day

Privacy Considerations Tokens from the same browser MUST NOT be joinable by the website. If the receiving party can link multiple tokens from the same browser (e.g., through storing them in partitioned storage), the website's chance of recovering the signal increases beyond p_reveal. Browsers MUST enforce reasonable bounds on the epoch length to ensure privacy requirements are met. Implementations MUST track context assignments to ensure that only one token per context per epoch is allocated. The context_id field in the browser database is REQUIRED to prevent websites from obtaining multiple tokens and exceeding the intended p_reveal rate.

Security Considerations

Token Ordinal Metadata Token ordinals prevent a malicious client from choosing one token and using it for every session. This would allow an attacker to generate an unbounded set of tokens with the same message. Although the attacker does not know which property this set of tokens has, this re-use would create a high likelihood that the signal would never be revealed. For each requested batch of tokens, the issuer records the order of the token in the generation sequence as the token's "ordinal" and then shuffles the tokens. This field does not convey information about the client requesting tokens, since each batch of tokens has the full set of ordinal IDs. Websites can monitor the distribution of token ordinal values and detect spikes that may indicate an attacker re-randomizing the same token across different sessions.

Ciphertext Re-randomization The ability to re-randomize a token's ciphertext without changing the underlying contents (a property of the ElGamal encryption scheme) underpins many of the security and privacy properties of PRTs. The issuer cannot link a re-randomized token's ciphertext back to any tokens it issued, and origins that receive re-randomized versions of the same token cannot link them together. Before sending a token on a connection to a particular site for the first time, the client re-randomizes the ciphertext for that token to make it unlinkable to any other usage of the token for other pairs. The client caches the ciphertexts for each pairing and reuses them on subsequent requests while the underlying token remains valid. The client does not re-randomize the token when the token is re-used on the same site. This allows the site to distinguish between a client with many visits using the same token and a client that is re-randomizing the same token across multiple visits (see section above).

IP Address Mismatch The IP address a client uses to fetch tokens may differ from the IP address used to connect to websites later. This can occur due to network changes, dynamic IP assignment, or other factors. This drift may result in a PRT revealing an IP address that is unexpected from the user's perspective. Browsers can reduce the chance of IP address mismatch by fetching tokens close to when they are spent and aligned with user expectations.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d. n.d. This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK] This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE). All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography. These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal Information Processing Standard (FIPS) validation of implementations that make use of these groups. This memo provides information for the Internet community. This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

Acknowledgments We thank Scott Hendrickson for his thoughtful review and constructive criticism of earlier drafts of this proposal.