Intent to Ship: Probabilistic Reveal Tokens

[Theodore Olsauskas-Warren]

Contact emails

sau...@google.com, las...@google.com, nic...@google.com, erict...@chromium.org, ryan...@google.com, ayk...@google.com

Explainer

https://github.com/GoogleChrome/ip-protection/blob/main/prt_explainer.md

Specification

https://datatracker.ietf.org/doc/html/draft-pfeiffenberger-prtokens-00

Summary

To enable businesses to estimate the amount of fraud on their systems, train models to defend against fraud, and analyze emerging fraudulent behavior while still mitigating the ability to track users at scale using IP addresses, we propose the introduction of a delayed IP sampling mechanism called Probabilistic Reveal Tokens (PRTs) alongside IP Protection for use in proxied traffic. Chrome plans to launch IP Protection in incognito mode later this year.

PRTs will be included on proxied requests in a new HTTP header added by the browser for domains that indicate they want to receive them via a signup process. Each PRT contains a ciphertext, generated by an Issuer and re-randomized by the browser for unlinkability prior to the request, that the recipient can decrypt after a delay. Google will be the issuer for Chrome's implementation. A minority of the decrypted PRTs contain the client's pre-proxy IP address (i.e. non-masked, and as observed by the token issuer), while the remaining PRTs provide no information about the client's original IP address. This results in only a small percent of PRTs containing and revealing the user's IP.

Our explainer introduces key tunable parameters for this proposal: 

• Reveal rate: the percentage of the time that the tokens are revealed

• Epoch and delay period length: the periods after which tokens are made available 

We will initially set reveal rate to 10% and epoch and delay period length both to 24 hours each.

Developers that want to receive PRTs will need to request them at console.privacysandbox.google.com. Sign ups will open when PRTs are available in pre-Stable channels.

Blink component

Privacy>Fingerprinting>IPProtection

TAG review

The IP Protection TAG review, for which this feature is closely tied, was closed by the TAG as “Resolution: Decline” (https://github.com/w3ctag/design-reviews/issues/1083)

TAG review status

Resolution Decline

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1273)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/529)

Web developers: Positive signal from invalid traffic detection providers, though open questions remain about the impact on fraud detection with initial parameter settings. As IP Protection launches, we’ll continue to solicit feedback.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

Attached PRTs are visible in the Chrome DevTools Network panel.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No, supported everywhere IP Protection is supported (no WebView).

Is this feature fully tested by web-platform-tests?

No, as there is no browser API for actuating PRTs (only a header attached as part of IP Protection), we don’t plan to add any.

DevTrial instructions

https://github.com/explainers-by-googlers/prtoken-reference/blob/main/prt_dev_testing.md

Flag name on about://flags

None

Finch feature name

EnableProbabilisticRevealTokens - Note that there are many subtleties to enabling this feature, please see DevTrial instructions for enabling locally.

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Launch bug

https://launch.corp.google.com/launch/4367692

Estimated milestones

Shipping on desktop	140
DevTrial on desktop	138
Shipping on Android	140
DevTrial on Android	138

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4914046966693888?gate=6289919137546240

--

Theodore Olsauskas-Warren

Software Engineering Manager

sau...@google.com

[Reilly Grant]

Can you request a separate TAG review for this feature? The TAG's response to the IP protection review request seemed to be about standardizing the complete system. However this individual piece could be adopted by other browsers even if their particular implementations of a complete IP protection system are implementation-specific.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B0Xr79QUTJt7bi443Ax5eMD2z%3DCsqV0o4__0tNvqKbMmLb5fg%40mail.gmail.com.

[Theodore Olsauskas-Warren]

Thanks for the feedback, Reilly. While the original IP Protection feature’s TAG review covers some ground on PRTs, you’re right that it’s possible the TAG may want to weigh in differently on PRTs specifically as opposed to IP Protection generally. We’ve filed a TAG request here.

At the same time, we also recognize that the protocol introduced here is likely best reviewed in an IETF forum, and would just flag for reviewers that we do hope to pursue discussions at IETF 124 this fall.

Theo.

[Mike Taylor]

LGTM1

I think this strikes the right balance between protecting users from known trackers and the ability to detect fraud and abuse. I'm not sure that 10% reveal after 24 hours is the magic recipe, but appreciate that these are configurable such that the team will be able to adapt to feedback / new information.

aside: I don't think we need to block on TAG review here, but encourage the team to follow up with the relevant IETF groups to get a broader review on the design.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/98e6b10c-f5c5-4852-b4b5-ff4da46c43bdn%40chromium.org.

[Yoav Weiss (@Shopify)]

Presenting this to various IETF groups in November sounds like a good idea, but it'd be great to try and shorten the feedback loop and shop around this I-D with relevant IETF mailing list.

That would enable the relevant communities to give this some attention and provide some feedback before it ships.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[David Turner]

As a member of Google's Ad Traffic Quality team, we're excited to see the development of PRTs and to better understand ad fraud in IP protected traffic. 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/98e6b10c-f5c5-4852-b4b5-ff4da46c43bdn%40chromium.org.

--
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+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17308ea5-3320-4d26-bc1f-067615267ccdn%40chromium.org.

[Rick Byers]

If another browser wanted to implement PRTs in a way compatible with Chrome in the future, how might they validate the compatibility of their implementation? This doesn't have to be WPT necessarily (though that is preferable since browsers are all trying to maximize their WPT pass rates).  

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODJ6YNy664F2PP%2BDYmFbA682fgG%2BOG56f5A%2BDt826x2WU4zRw%40mail.gmail.com.

[Scott Pierce]

Integral Ad Science (IAS) is looking forward to testing PRTs to determine the impact obfuscated IPs within Incognito sessions may have on ad fraud.

Cheers,

Scott Pierce, Head of Fraud

Integral Ad Science

---

This message (including any attachments) may contain confidential, proprietary, private and/or privileged information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is strictly prohibited. In addition, emails sent from and to this integralads.com domain are monitored, archived, and subject to disclosure, including in connection with regulatory or other legal processes.

[Rick Byers]

Thank you Scott (and David), understanding the developer adoption interest is really helpful in weighing the tradeoffs around enabling this by default in Chromium!

Rick

[eric trouton]

Hi folks,

Yoav, thank you for your suggestions, we reached out to the MASQUE listserv for feedback and responded to TAG reviewers with more details about the utility and privacy properties.  

Rick, as to your question, we have a reference implementation (covering issuance, re-randomization & decryption), with tooling support for websites that can easily be used to validate other implementations. We commit to providing more conformance test support if another browser expresses interest in building PRTs. 

To be clear, we are committed to responding to ecosystem needs and evolving PRTs over time.  

Finally, thank you Scott and David for commenting about your interest in testing PRTs!

Thanks all,

Eric

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-v52s%3DpYGCHV4YeomgB12HQ4TEX8nsWaictnzZ_EtZ4w%40mail.gmail.com.

[Rick Byers]

On Tue, Aug 19, 2025 at 7:08 AM eric trouton <erict...@chromium.org> wrote:

Hi folks,

Yoav, thank you for your suggestions, we reached out to the MASQUE listserv for feedback and responded to TAG reviewers with more details about the utility and privacy properties.  

Rick, as to your question, we have a reference implementation (covering issuance, re-randomization & decryption), with tooling support for websites that can easily be used to validate other implementations. We commit to providing more conformance test support if another browser expresses interest in building PRTs. 

Thanks, that's good enough for me in this case. None of the other engines seem to be investing in balanced anti-fraud features like this so while I'd love there to be an automated conformance test suite for this somewhat unconventional API, I don't feel it's reasonable to ask for it as a condition of shipping. But please keep your ears open, perhaps interest from other engines will materialize if major sites start to challenge users more when using IP anonymization from a browser without PRT support.

LGTM2 

[Yoav Weiss (@Shopify)]

LGTM3

I'd have loved getting more feedback from the broader community on this, but given the fact that the team is willing to ship breaking changes to the feature based on future feedback, that's an acceptable risk. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.