Re: [w3ctag/design-reviews] Probabilistic Reveal Tokens (for IP Protection) (Issue #1125)

etrouton left a comment (w3ctag/design-reviews#1125)

Hi Martin and TAG reviewers,

Thanks for taking a look and hopefully we can help answer some of your questions.  It seems we can carve this into two high level concerns:

1. What utility does this actually provide to users and the web ecosystem more broadly?
2. Why is this a reasonable privacy trade off?

For the first point, the main user benefit is derived from our free and cross-platform private proxy service that limits visibility from 3rd party trackers.  This proxy provides tangible user benefits like limiting advertisers and adtechs from using a user’s IP address for ad targeting and personalization. However, offering an open relay on the web is potentially very risky and dangerous, so the free access is a package deal with tools like PRTs that help keep the proxy free of abuse.  

While PRTs do not detect abuse in real time, the benefit it provides to sites and 3rd parties is:

- Allowing websites to monitor abuse and measure fraud in aggregate after the fact, which is helpful for things like make-goods/clawbacks for excessive ad fraud
- Provide organizations the ability to update models with sampled event level datasets, which is useful for fraud detection in non-proxied traffic and potentially in the future for real-time detection of proxied traffic, which we hope to discuss as a future initiative
- Lastly, it gives Chrome some ability to respond to reports of abuse of the proxy, where we have actionable levers like adjusting quotas to limit future abuse sites see

You might imagine, if a proxy service had low reputation through a suspected (or measured) high proportion of unmitigated abuse, sites would simply block those proxy IPs - which would be very bad for users who want more privacy provided by that service.  Tor users often face this exact conundrum, where there is not enough signal for sites to differentiate good and bad users, so it’s easier for many sites to simply block access for all Tor users or known onion router egress IPs.  Other proxy services maintain higher reputations by charging a high amount for access or requiring proprietary hardware, which raises the cost of investment for potential abuse, and therefore yields less abuse.  As a free service, we are striving to have it all: widely accessible, greatly improved user privacy, and universally accepted by websites.  

If there are better ways to do this, we would love to do them! In fact, we are actively investing in private feedback loops and hope Privacy Pass will take on Anonymous Credit Tokens, which can contribute to a private long term solution.  However it does not currently solve the challenge about updating models and detecting novel attacks, which today often requires manual analysis and supervised learning. We think that PRTs are a necessary component to launching IP Protection responsibly today, fully acknowledging that we might discover better ways to do this in the future. 

For the second issue, is this a reasonable tradeoff?  This is a very tricky problem to balance access, openness, privacy, and web safety, but in my opinion it offers a great tradeoff, particularly considering it is free service. If some users have more sophisticated threat models, it’s possible there are other proxy services they may prefer but come with other drawbacks like being a paid service or having low reputation / site access issues. 

10%/24hr are the starting parameters, and it’s possible (likely even) that we may adjust them up or down based on feedback. Our goal is to reduce the reveal rate while minimizing the prevalence of fraud, so hopefully the tradeoff for most users looks even better over time.  

Hopefully that helps clarify our intent and address your questions. We also already pinged the MASQUE listserv as well. Looking forward to hearing your thoughts and feedback,

Thanks,
Eric 


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1125#issuecomment-3186532009
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1125/3186532009@github.com>