- From: Martin Thomson <notifications@github.com>
- Date: Mon, 11 Aug 2025 17:28:02 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1125/3177285710@github.com>
martinthomson left a comment (w3ctag/design-reviews#1125) Hey, thanks for sharing this. We have some thoughts, but thought we'd start with some high-level questions to clarify first. First, the explainer doesn't address the end-user benefits that might come from a solution like this. For those users who reveal their IP address, this doesn't seem like a great deal, but maybe there is some indirect benefit you can point to. Privacy loss is forever. Mostly, the things that we need to understand better what sort of operational model might apply here. That starts with what sort of expectations end users have with respect to the system you are deploying. Ordinarily, a user that engages a proxy does so to ensure that their activity cannot be traced back to their IP address. This upends that, with a 10% chance of leak after a 24h delay. Then there is the question of how a site might use what it learns. If an IP is acting poorly, sites learn about who was responsible 24h after that abuse starts. Critically, none of the requests that pass the proxy have an IP that can be used at the time of the request, so real-time use is right out. For this to work for DoS, or any other form of abuse where the reaction needs to occur in real time, there has to be some visibility of IP addresses at the time of a request. That rules this out for many forms of abuse mitigation. The explainer says that this is for managing ad fraud, but we can't see how this works for many workflows related to ads. Given the 10% reveal rate, this might give a probabilistic read on fraud rates -- if IP is a significant factor -- but the 24h delay is going to makes this very limited in its applicability. That's even in this narrow case, because many ad fraud management cases need real time action as well. For example, it doesn't look like sites using the Attribution API will be able to take advantage of this sort of information. Finally, we recommend that you take this to the MASQUE working group in the IETF to collect feedback from the experts there. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1125#issuecomment-3177285710 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1125/3177285710@github.com>
Received on Tuesday, 12 August 2025 00:28:06 UTC