Re: [w3ctag/design-reviews] IP Protection (in Incognito mode) (Issue #1083)

miketaylr left a comment (w3ctag/design-reviews#1083)

Hi - thanks for the nudge.

> Do you see any pieces of this design that would benefit from standardization? Who on iCloud Private Relay should participate in such an effort? E.g.

The majority of this system is standardized in the sense that it uses standards such as IETF RFCs. In particular work from the MASQUE and PRIVACYPASS working groups. However, that doesn't necessarily imply that different products in this space would work together. See details inline below.

> Could multiple browser implementations share proxyB providers by speaking the same protocol to them, including the authentication part?

Using standardized protocols doesn't imply sharing providers. In order for a user agent to start using proxy providers, it needs to ascertain that the proxy provider will not degrade the quality of the user's web browsing experience, and that the two proxy providers won't collude in an attempt to break the privacy properties of the system. Conversely, the proxy providers require payment for the cost of proxying. This means that a contractual relationship needs to exist between the user agent and proxies. Even though IP Protection and iCloud Private Relay use the same standardized protocols, they are unlikely to interoperate.

> Can the IP-geo boundaries be shared between implementations?

Mapping IP addresses to geolocations is currently performed across the industry using proprietary databases. Since the boundaries are implementation details of the various IP-geo providers, it is unlikely that they will be shared. However, Google publishes the IP Protection geofeed at https://www.gstatic.com/ipprotection/geofeed for anyone to use.

> Could you standardize the process for producing the Masked Domain List?

The process to produce the MDL is publicly documented [here](https://github.com/GoogleChrome/ip-protection/blob/main/README.md#the-masked-domain-list-criteria). It's possible we could specify list creation down the road, if there was interest from other vendors, but I would expect there to be a lot of vendor-specific choices that may make it difficult.

> Can the Masked Domain List itself be shared? Does there need to be a standard protocol to disconnect.me to request the current list?

The MDL is shared [here](https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md). Google uses standard HTTPS to fetch the list from Disconnect.me when building the MDL. 

> Do you need a protocol for reporting fraudulent behavior?

Our protocol for reporting is documented [here](https://github.com/GoogleChrome/ip-protection/blob/main/README.md#anti-fraud-and-anti-spam-strategy-and-implementation). As we gain more experience, standardization may be useful.

> W.r.t. the Probabilistic Reveal Tokens, I see that 5-15% of 3p requests will (after a delay) reveal the client's true IP address, and the design has 100% of 1p requests do so. Is there an economic analysis of why this is sufficient in practice to prevent or reduce the use of IP addresses for tracking (associating top-level user IDs across sites)?

As identified, because IP Protection does not proxy connections to the 1P, it does not prevent the association of “top-level” (i.e. 1P facilitated) user fingerprint information across sites. This is independent of any PRT related behavior, including the initially proposed reveal rate. 

Our initial reveal rate has been determined in consultation with anti-fraud providers, and is based on the estimated lowest initial value that continues to enable IP protected traffic to be effectively monetized, and so continue to be provided access to ad-supported content.






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

Message ID: <w3ctag/design-reviews/issues/1083/2883724400@github.com>