Skip to content
This repository was archived by the owner on Nov 3, 2025. It is now read-only.
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

Open

Description

@etrouton

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.

Activity

  1. bvattikonda commented on Mar 4, 2025

    @bvattikonda

    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:

    1. Who would the proxy be offered to?
    2. 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.

  2. etrouton commented on Mar 10, 2025

    @etrouton
    CollaboratorAuthor

    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?

  3. SpaceGnome commented on Mar 10, 2025

    @SpaceGnome

    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?

  4. etrouton commented on Mar 12, 2025

    @etrouton
    CollaboratorAuthor

    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!

  5. syed-mustafaa commented on Sep 3, 2025

    @syed-mustafaa

    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 "

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions