Sad that Brave did not do their work correctly, the google_push parameter they are talking about is not an identifier. Otherwise it’s true that RTB should not exist and violate GDPR, but it’s so complex that even Brave was not able to correctly state the workflow.
“Starting in mid-April, we will begin assigning a URL-safe string value to the google_push parameter in our pixel match requests and we will expect that same URL-safe string to be returned in the google_push parameter you set. This change will help us with our latency troubleshooting efforts and improve our pixel match efficiency.”
Okay, but the `google_push` parameter seems to be the same for all adtech providers swarming on the same user in the same RTB session. Nothing in your comment contradicts the claim that this allows them to sync up profiles for that user across providers, in the way that the switch to per-provider `google_gid` values supposedly blocks.
Sure, but as long as the adtech providers each have their own stable IDs for you, they can still use `google_push` to link their corresponding stable IDs together, uniquely identify you, and merge their respective profiles.
====
Page View #1:
- Acorp: google_gid=qwerty, google_push=foo
- Bcorp: google_gid=asdfgh, google_push=foo
- Ccorp: google_gid=zxcvbn, google_push=foo
By exchanging their `google_gid` values corresponding to the page load with shared `google_push` value foo, Acorp, Bcorp, and Ccorp can identify you as user qwerty-asdfgh-zxcvbn.
====
Page View #2:
- Acorp: google_gid=qwerty, google_push=bar
- Bcorp: google_gid=asdfgh, google_push=bar
- Ccorp: google_gid=zxcvbn, google_push=bar
By exchanging their `google_gid` values corresponding to the page load with shared `google_push` value bar, Acorp, Bcorp, and Ccorp can still identify you as user qwerty-asdfgh-zxcvbn, even though the `google_push` value has changed.
I now see your point, thanks.
I was thinking this “google_push” is probably not unique (a.k.a many users could have the same) but the adtech providers could check the ids + timestamps to help with the match. NB: Google is not syncing with everyone on the same page view so the adtech providers have to be lucky enough to be synced on the same page view. Another question is: what is the “google_push” entropy?
Having worked in adtech, I can tell you the adtech providers probably don’t do that, for those reasons:
1) those adtech providers are usually competitors
2) if they work together, they can already sync their user ids directly together (so using google id is not necessary).
So I don’t think Google intentions were malign here on this particular point (contrary to Brave communication and all the press coverage).
But yes, Google shouldn’t add entropy by sending the same “page view id” to different adtech providers. Note that Google is “better” than the others here: every other adtech providers send the same user id to each partner (persistant identifier, not session or page view like google). And those providers are sometimes quite big: for example, AppNexus or Criteo trackers are also everywhere on the web. Overall, it’s the RTB system with all those cookie syncs that shouldn’t exist, and except for the “google_push” argument, Brave study is quite good (they are just explaining how the adtech world works).
(5) ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person.
See their release note (15 April 2013); https://developers.google.com/authorized-buyers/rtb/relnotes
“Starting in mid-April, we will begin assigning a URL-safe string value to the google_push parameter in our pixel match requests and we will expect that same URL-safe string to be returned in the google_push parameter you set. This change will help us with our latency troubleshooting efforts and improve our pixel match efficiency.”