Live data from Hacker News

Google’s GDPR Workaround

brave.com

501–510 of 629 posts

Re: Google’s GDPR Workaround

#501

Earlier quoted context omitted.

This log [0], right? Did you miss in the article that it's the `google_push` identifier that's being used for syncing between adtech companies? If you search for it (AHNF13KKSmBxGD6oDK9GEw5O0kvgmFa3qM30zpNaKl72Og), you can see it being included in requests to lots of different adtech firms' domains. [0] https://brave.com/wp-content/uploads/files_2019-9-2/sample_p...

There is unfortunately no way to prevent that part. BidRequest Data [0] and Request Time is already enough to fingerprint the user. "Google prohibits multiple buyers from joining their match tables." part is not technical, it is contract based. [0] Sample Data from Bid Request ip: "F\303\006" user_agent: "Mozilla/5.0 (Linux; Android 7.1.1; Pixel XL Build/NOF26V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924…

There is unfortunately no way to prevent that part.

Well there's absolutely a way: single-source JS and no CORS.

Re: Google’s GDPR Workaround

#502
I'm glad this story was reported, and I'm thankful to the author for putting in the work required to report this story. But after the first five paragraphs, the author's shameless, repetitive self-promotion and insistence on referring to himself in the third person almost made this unreadable.

The headline was enough to pique my curiosity to explore Brave's product offering. Unfortunately, actually reading the article had the exact opposite affect.

Re: Google’s GDPR Workaround

#503

Yeah. Brave is desperately trying to compete with Chrome and can’t figure out why they aren’t making much headway, despite having better privacy (hint: users just don’t care about privacy, except for the HN crowd). These complaints filed by Brave, with their own employees posing as professional “victims” intentionally grasping at straws for evidence of privacy violations, smack of desperation. This is not the first c…

(hint: users just don’t care about privacy, except for the HN crowd).

I'm not sure that's true: uBlock Origin has twice as many installations as Brave does. You might say "oh, but that's just blocking ads!" But if you don't block ads, privacy problems are going to spring out of the woodwork like nobody's business. That is, they might not care about privacy by name, but they certainly care about it in effect.

Re: Google’s GDPR Workaround

#504

I think the HN community, and most consumers, tend to look at things from only one angle. Imagine you start work at some small shop that manufacturers widgets for consumers. What would you do when you have to advertise your product? You'd have to turn to Google is a similar company. Are there any real alternatives? (I am asking because I really want to know) I say this because I am in this position now. I have to fig…

The alternative is to spend hundreds of hours finding widget-related websites, trying to contact the owner(s), negotiating what ad spots are available, what ads are acceptable to run, and what pricing/terms will work for both parties, then managing that relationship over time to ensure ads are actually being displayed, being paid on time, contracts renewed, etc. It's definitely possible, but you're just doing everyth…

Native ads like those can certainly be automated to a great degree, and at the very least use a self-serve interface. "Advertise with us!" links in the sidebar or footer or wherever.

Re: Google’s GDPR Workaround

#505

Earlier quoted context omitted.

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.

Well, for 2 page views (same session), I have 2 different ‘google_push’ (Chrome with default parameters, no extensions).

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.

Re: Google’s GDPR Workaround

#506

I think the HN community, and most consumers, tend to look at things from only one angle. Imagine you start work at some small shop that manufacturers widgets for consumers. What would you do when you have to advertise your product? You'd have to turn to Google is a similar company. Are there any real alternatives? (I am asking because I really want to know) I say this because I am in this position now. I have to fig…

The alternative is to spend hundreds of hours finding widget-related websites, trying to contact the owner(s), negotiating what ad spots are available, what ads are acceptable to run, and what pricing/terms will work for both parties, then managing that relationship over time to ensure ads are actually being displayed, being paid on time, contracts renewed, etc. It's definitely possible, but you're just doing everyth…

At which point you'll very likely learn that a lot of widget-related websites use ad networks because it saves the 2-3 administrators involved a lot of time and energy.

It's definitely possible for small websites to do ads directly, but it's a lot of work. Often more than is justified for a few thousand dollars a year in ads.

Re: Google’s GDPR Workaround

#507

Yeah. Brave is desperately trying to compete with Chrome and can’t figure out why they aren’t making much headway, despite having better privacy (hint: users just don’t care about privacy, except for the HN crowd). These complaints filed by Brave, with their own employees posing as professional “victims” intentionally grasping at straws for evidence of privacy violations, smack of desperation. This is not the first c…

(hint: users just don’t care about privacy, except for the HN crowd). I'm not sure that's true: uBlock Origin has twice as many installations as Brave does. You might say "oh, but that's just blocking ads!" But if you don't block ads, privacy problems are going to spring out of the woodwork like nobody's business. That is, they might not care about privacy by name, but they certainly care about it in effect.

I’d say the vast majority of uBlock users care about user experience. The current ad experience sucks. Most local newspaper sites, for example, are unusable because of ads. But if it still preserved their privacy behind the scenes and didn’t significantly improve their experience, the install base on uBlock and other ad blockers would be near 0.

Re: Google’s GDPR Workaround

#508

Earlier quoted context omitted.

This is a problem because companies can use this ID to correlate private user data, without anyone's knowledge or consent. There are companies that specialise in sharing user information. Some of them work by only sharing data with companies that first share data with them (an exchange). If you got this Google ID, and you had a few other pieces of information about the user, you could share that data with an exchange…

Considering google_gid is valid for you for 14 days only. It is very unlikely to build a profile around it.

Considering how much time many people spend online, and how efficient these profiling systems have become, I wouldn't be surprised if 14 days was plenty of time.

Re: Google’s GDPR Workaround

#509

Earlier quoted context omitted.

This is a problem because companies can use this ID to correlate private user data, without anyone's knowledge or consent. There are companies that specialise in sharing user information. Some of them work by only sharing data with companies that first share data with them (an exchange). If you got this Google ID, and you had a few other pieces of information about the user, you could share that data with an exchange…

Considering google_gid is valid for you for 14 days only. It is very unlikely to build a profile around it.

It seems likely that the ad network could detect the change in ID if the expiration happens in the middle of a browsing session. Which, considering user habits, they are probably online at the same time every day, or have habits that cycle weekly.

Also, considering we largely do the same things every week and every day, I suspect a single day to give you at least 50% of a user's identifying data, and a week to give you at least 80%. That leaves a whole week of pretty accurate tracking.

I think you've made a pretty wild claim that 14 days isn't enough time to build a useful profile. Regardless, even if the usefulness of the data over two weeks is questionable, it's still illegal to share the data in this way. You wouldn't be too happy if someone broke into your house and "only" stole a single fork.

Re: Google’s GDPR Workaround

#510

Earlier quoted context omitted.

Well, for 2 page views (same session), I have 2 different ‘google_push’ (Chrome with default parameters, no extensions).

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 corre…

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).

Post reply on HN