Bypassing IP protection through first-party cooperation

[Mickael-van-der-Beek]

Hello everyone,

As a follow-up to the following thread that clarified the behaviour of the allowlist logic: #31, I would like to ask how the IP Protection project will protect users from cooperating first-party origins.

For example, if a user browses to publisher.com, the site will have access to the real IP address of the user, as expected.
It could then pass said IP address to tracker.com as a query string parameter or HTTP header of the request to the tracking origin.

This would defeat the IP Protection mechanism in a relatively simple way if I'm not mistaken?

Thank you in advance four your answers and insights.

[dvorak42]

We're initially focusing on third parties as we see that as having the most impact. If first-parties start engaging in this kind of behavior, there are other web privacy efforts such as requiring the use of Fenced Frames and Navigation Tracking Mitigations that should help mitigate the ability for first parties to freely share information with embedded parties. We will continue to monitor the ecosystem to determine whether these kinds of mitigations will be suitable to avoid this kind of problem and will continue to evolve our approach to prevent scaled abuse.

[Mickael-van-der-Beek]

@dvorak42 Thank you for your answer!

I'm guessing that IP Protection, like DIPS (the bounce tracking blocking system in Chromium), will use an eTLD+1 scope to determine if a traffic destination is or is not considered tracking?

If so, will these systems eventually also (or might already) have CNAME cloaking detection in place to prevent tracking traffic from being considered as "first party"?

Thanks a lot in advance for your clarifications!

[dvorak42]

The exact scope will be dependent on the shape of the tracker list we end up using, but something like DIPS/eTLD+1 is probably a good starting point for what we'd likely want to do.

Regarding CNAME cloaking, we are investigating potential defenses such as the HTTP Proxy-Status Parameter for Next-Hop Alias proposal.

[Mickael-van-der-Beek]

@dvorak42 Thank you for the clarifications! I'm closing this issue for now.