Detecting fraudulent engagement

[spanicker]

Services that are embedded in a third-party context will now see distinct IPs for each top-level domain that the user is visiting. This negatively impacts the ability to count the number of distinct users across a set of sites, and makes it easier to inflate impressions and ad clicks by having these same users engage on multiple sites.

Some attributes, such as GeoIP, may allow sites to validate observed regional distributions against what is expected. We are keen to discuss any suggestions that could improve defensibility within our privacy objective of preventing scaled cross-site tracking.

[dmdabbs]

Services that are embedded in a third-party context will now see distinct IPs for each top-level domain that the user is visiting.

This echoes one of the approaches sketched in the Near-Path NAT proposal that was removed from this repo. Interested in more details, as well as for the user authentication, auth and other measures the new content introduces.

[etrouton]

We are looking for feedback on additional proposals to jointly optimize privacy and anti-fraud goals, including:

• Introducing multi-user “cohorts” (similar to YouTube RCAT) that are stable across top-level origins.
• Trusted execution environments for training and applying IVT filtration models.

Are these proposals sufficient to meet your use cases? Are there other privacy preserving ideas that you would suggest for detecting fraudulent engagement without the use of real IP?

[miketaylr]

Closing and locking in favor of https://github.com/GoogleChrome/ip-protection/issues/4