You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 3, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 3, 2025. It is now read-only.
What is a reasonable reveal rate for Probabilistic Reveal Tokens? #81
The reveal rate is a critical parameter to balancing utility in combating fraud with privacy for users. A higher reveal rate might make fraud and abuse detection easier, but it also increases the likelihood a user’s identity can be joined across sites within a browsing session.
We have a goal to minimize the reveal rate without impacting fraud and spam detection, but given the importance of this parameter, we do not want to set an initial reveal rate without public input and discussion. We humbly ask for and appreciate your feedback, concerns, questions, and if applicable, relevant details of your use cases.
Thanks @etrouton for seeking feedback on the reveal rates. Simulating the reveal rates and precisely identifying reveal rates that would help detect abuse is challenging because there are a few factors that we can’t simulate:
Who would the proxy be offered to?
How would the attackers take advantage of Chrome IP Protection?
Could we start with a reveal rate of 100% which would be as good as not having the IP protection at all? A 100% reveal rate would allow us to drop the PRTs for a segment of the traffic and evaluate if defenses can be maintained with a lower rate. We will then be able to comment on the impact of different reveal rates on our invalid traffic detection capabilities better.
Hi @bvattikonda - thank you for your thoughts and feedback. Points taken on 1&2 being difficult to simulate ahead of time. The idea to start at 100% reveal rate is understandably appealing in order to establish a baseline, but I'd personally have a very hard time arguing in favor of it simply from a privacy perspective, even if it was just a short period of time.
Is it possible, albeit less accurate, to estimate with a (far) lower reveal rate?
Or can we make more clear the "short period of time" before the desired end state and final reveal rate and have the reveal rate gradually decrease from 100% to the final rate during this period of time?
Thank you @SpaceGnome for your feedback. I don't know that we have been thinking of reveal rates as a fixed setting. Our initial approach in the explainer was to start at a moderate level and slowly decrease over time, but based on some feedback we're getting, it's possible we might start lower and find we need to raise it. Either way, our goal is to minimize the reveal rate while preserving measurement of IVT & fraud.
My personal/professional opinion is that a 100% reveal rate is just a hard sell regardless of the time period, it wipes out all the privacy improvement from IP Protection - I don't really want to advocate for that, and I'm not convinced it gets us much. Let's say we did it for one day or one week - how do we know that is a representative set of data when we know fraud tactics are highly dynamic? Isn't it likely that potential sophisticated bad actors would just wait it out until the reveal rate drops, as reveal rates will be publicly discussed and verifiable? I guess I could see it working much better if we randomly revealed 100% with no prior notice, but I really don't like that from a user privacy perspective.
Apologies if I'm missing something, and hopefully my tone comes across as inquisitive and not dismissive. Thank you for the public feedback and discussion!
I think the idea of introducing tiered p_reveal policies makes a lot of sense. A 5% default works fine for general traffic where privacy should always be the top priority, but in practice there are certain ecosystems (ads, payments, gaming, or other fraud-heavy zones) where that sampling rate just doesn’t give operators enough data to flag abuse reliably.
Having an optional tier at 10-15% for verified high-risk domains would still keep the majority of requests unlinkable while giving fraud systems a fighting chance in the areas where abuse is concentrated.
The key here is that this should be centrally controlled and fully auditable, so it’s not a “backdoor” to higher tracking, but a transparent, documented policy that everyone can review. That way we maintain user trust while still giving websites a more realistic toolset for fraud detection.
Activity
bvattikonda commentedon Mar 4, 2025
Thanks @etrouton for seeking feedback on the reveal rates. Simulating the reveal rates and precisely identifying reveal rates that would help detect abuse is challenging because there are a few factors that we can’t simulate:
Could we start with a reveal rate of 100% which would be as good as not having the IP protection at all? A 100% reveal rate would allow us to drop the PRTs for a segment of the traffic and evaluate if defenses can be maintained with a lower rate. We will then be able to comment on the impact of different reveal rates on our invalid traffic detection capabilities better.
etrouton commentedon Mar 10, 2025
Hi @bvattikonda - thank you for your thoughts and feedback. Points taken on 1&2 being difficult to simulate ahead of time. The idea to start at 100% reveal rate is understandably appealing in order to establish a baseline, but I'd personally have a very hard time arguing in favor of it simply from a privacy perspective, even if it was just a short period of time.
Is it possible, albeit less accurate, to estimate with a (far) lower reveal rate?
SpaceGnome commentedon Mar 10, 2025
Or can we make more clear the "short period of time" before the desired end state and final reveal rate and have the reveal rate gradually decrease from 100% to the final rate during this period of time?
etrouton commentedon Mar 12, 2025
Thank you @SpaceGnome for your feedback. I don't know that we have been thinking of reveal rates as a fixed setting. Our initial approach in the explainer was to start at a moderate level and slowly decrease over time, but based on some feedback we're getting, it's possible we might start lower and find we need to raise it. Either way, our goal is to minimize the reveal rate while preserving measurement of IVT & fraud.
My personal/professional opinion is that a 100% reveal rate is just a hard sell regardless of the time period, it wipes out all the privacy improvement from IP Protection - I don't really want to advocate for that, and I'm not convinced it gets us much. Let's say we did it for one day or one week - how do we know that is a representative set of data when we know fraud tactics are highly dynamic? Isn't it likely that potential sophisticated bad actors would just wait it out until the reveal rate drops, as reveal rates will be publicly discussed and verifiable? I guess I could see it working much better if we randomly revealed 100% with no prior notice, but I really don't like that from a user privacy perspective.
Apologies if I'm missing something, and hopefully my tone comes across as inquisitive and not dismissive. Thank you for the public feedback and discussion!
syed-mustafaa commentedon Sep 3, 2025
I think the idea of introducing tiered p_reveal policies makes a lot of sense. A 5% default works fine for general traffic where privacy should always be the top priority, but in practice there are certain ecosystems (ads, payments, gaming, or other fraud-heavy zones) where that sampling rate just doesn’t give operators enough data to flag abuse reliably.
Having an optional tier at 10-15% for verified high-risk domains would still keep the majority of requests unlinkable while giving fraud systems a fighting chance in the areas where abuse is concentrated.
p_reveal_review.pdf
The key here is that this should be centrally controlled and fully auditable, so it’s not a “backdoor” to higher tracking, but a transparent, documented policy that everyone can review. That way we maintain user trust while still giving websites a more realistic toolset for fraud detection.
"More signal, less fraud, fewer sleepless devs "