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.
On Wed, Aug 6, 2025 at 8:31 AM Yoav Weiss (@Shopify) <yoavwe...@chromium.org> wrote: > 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. > > On Wednesday, August 6, 2025 at 4:45:27 PM UTC+2 Mike Taylor wrote: > >> 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. >> On 8/1/25 12:48 p.m., 'Theodore Olsauskas-Warren' via blink-dev wrote: >> >> 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 >> <https://github.com/w3ctag/design-reviews/issues/1125>. >> >> 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. >> On Tuesday, July 29, 2025 at 11:13:10 AM UTC-7 Reilly Grant wrote: >> >>> 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 >>> <https://www.google.com/chrome> >>> >>> >>> On Mon, Jul 28, 2025 at 1:52 PM 'Theodore Olsauskas-Warren' via >>> blink-dev <blin...@chromium.org> wrote: >>> >>>> 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 >>>> <https://github.com/GoogleChrome/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 >>>> <https://github.com/GoogleChrome/ip-protection/blob/main/prt_explainer.md#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 >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Privacy%3EFingerprinting%3EIPProtection%22> >>>> >>>> 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 >>>> <https://github.com/GoogleChrome/ip-protection/issues/81> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> 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 >>>> >>> -- >>>> 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B0Xr79QUTJt7bi443Ax5eMD2z%3DCsqV0o4__0tNvqKbMmLb5fg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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 visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/98e6b10c-f5c5-4852-b4b5-ff4da46c43bdn%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/98e6b10c-f5c5-4852-b4b5-ff4da46c43bdn%40chromium.org?utm_medium=email&utm_source=footer> >> . >> >> -- > 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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17308ea5-3320-4d26-bc1f-067615267ccdn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17308ea5-3320-4d26-bc1f-067615267ccdn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODJ6YNy664F2PP%2BDYmFbA682fgG%2BOG56f5A%2BDt826x2WU4zRw%40mail.gmail.com.
