Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Tag Manager, the new anti-adblock weapon (2020)

chromium.woolyss.com

Post reply on HN
Print view View original

51–60 of 902 posts

Re: Google Tag Manager, the new anti-adblock weapon (2020)

#51

Post by Godel_unicode »

bink wrote: post #26
jtbayly wrote: post #7

Earlier quoted context omitted.

The article claims ublock origin won’t work on sites that implement this.

The current version doesn't but there's not really a reason to believe it can't be updated. I think the author overstates the complexity of documenting these proxies and URLs for sites that run them.

You're going to lose this cat-and-mouse game, it's the same one that gets played with malware C2 domains (except it's worse because both the proxy operator and the actual domain operator are colluding). Add in the zero-cost nature of subdomains as opposed to needing to pay for new DGA root domains and the fact that they can run the whole thing behind e.g. cloudflare to prevent IP blocking? Forget about it.

Re: Google Tag Manager, the new anti-adblock weapon (2020)

#52

Post by kibibu »

quicklime wrote: post #38
gigel82 wrote: post #25

God damn... this is it, this is the end-game. There's no way to fight this unless you customize and maintain blocking scripts for each individual website. Yes, websites could always have done this, but the REST (CDN-bypassing) requests' cost and the manual maintenance for the telemetry endpoints and storage was an impediment that Google just gives them a drop-in solution for :( I think Google is happy to eat some of…

> Maybe using an archive.is-like service that renders the static page (as an image at the extreme) A lot of companies are starting to use "browser isolation" which is essentially what you're saying. A proxy runs between the client and the server, but it does more than just direct TLS streams - it actually builds the DOM and executes the JS. The resulting web page is sent to the actual client browser, which might send…

Opera Mobile has been doing this for years and years

Re: Google Tag Manager, the new anti-adblock weapon (2020)

#54

Post by coffeefirst »

losteric wrote: post #8

Citing adblock feels like clickbait. Google Tag Manager can't run ads so I don't follow the comparison. Marketing analytics could always side-step anti-adblocking tools through server-side tracking.

Right. Everything in the article is wrong.

GTM is still GTM and can be trivially blocked; the container itself isn't moving server-side.

It's just gained the ability to proxy data to third parties instead of needing to load scripts for every tracker. This is better for performance, and should be explicitly in control of exactly what data is passed on to where.

All you really lose is the ability to block a subset of analytics scripts selectively.

Re: Google Tag Manager, the new anti-adblock weapon (2020)

#55

Post by tootie »

gigel82 wrote: post #25

God damn... this is it, this is the end-game. There's no way to fight this unless you customize and maintain blocking scripts for each individual website. Yes, websites could always have done this, but the REST (CDN-bypassing) requests' cost and the manual maintenance for the telemetry endpoints and storage was an impediment that Google just gives them a drop-in solution for :( I think Google is happy to eat some of…

"Endgame" is the way all web analytics was done 20 years ago.

Re: Google Tag Manager, the new anti-adblock weapon (2020)

#56

Post by anxrn »

gigel82 wrote: post #48
anxrn wrote: post #39

Wouldn't it be possible for a potential client-side blocker for this to intercept the gtag() method invoked on the client side ("Tag Manager web container"), even if that function is provided by a script hosted on the website owner's domain, as Google recommends[1]? [1] https://developers.google.com/tag-platform/tag-manager/serve...

Highly doubtful the method would continue to be called "gtag"; any js bundling / minification would replace that with a randomly generated string, and it's just as easy to randomize the server-side api endpoint url, making this virtually impossible to block (maybe a pattern analysis on the data being transmitted, but that can also be encrypted with random algorithms and keys, beyond recognition).

Yes, it can surely be obfuscated, but ultimately there will be a client-side function with near-identical functionality prevalent all over the web. It's harder, but seems possible to build an extension to identify this function.

Re: Google Tag Manager, the new anti-adblock weapon (2020)

#57

Post by varenc »

Apple and Firefox brought this on by killing 3rd party cookies.

The reason why client send requests to the 3rd party domain directly is that the cookies attached to that domain are sent and which can track you better! With a server-side request there's no way to use that cookie info.

But browsers increasingly limit 3rd party cookies. With 3rd party cookies becoming useless for tracking there's far less to lose by moving all these analytics calls to the server side.

Re: Google Tag Manager, the new anti-adblock weapon (2020)

#58

Post by brundolf »

thenanyu wrote: post #10

As someone who has spent a lot of time on both sides of this, I think this is a great outcome, personally. The most annoying part of ad-tech for me, as a user, was the fact that I was running all sorts of random javascript, any bit of which could blow up performance on my browser. As someone who used to lead an e-commerce operation, I hated running all of this crap in my users' browsers because I knew it would get bl…

I have mixed feelings about it, even just as a user. There are two reasons people block tracking scripts: 1) privacy, and 2) to stem the deluge of crap that marketing departments dump onto the page, harming performance (both load-time and otherwise) [1].

This basically gives everyone the benefit of #2, even if they don't or can't use an ad blocker. That's pretty cool, in isolation. But of course it also makes it much harder to accomplish #1.

[1] I've seen React-based websites with literally 10x as much JavaScript (by weight) coming in from GTM and other third-party marketing vendors, as the amount powering the actual app functionality. This happens (partly) because every single ad provider has you load their own arbitrary JS bundle onto the page, just so they can measure conversions. This is obscenely inefficient (and frankly, even though it makes things easier to block, in some ways it's potentially a lot more insecure/privacy-invading). People on here complain about frameworks ruining web performance, but in reality GTM is far more responsible (or has been, so far).

Re: Google Tag Manager, the new anti-adblock weapon (2020)

#59

Post by toastal »

gigel82 wrote: post #25

God damn... this is it, this is the end-game. There's no way to fight this unless you customize and maintain blocking scripts for each individual website. Yes, websites could always have done this, but the REST (CDN-bypassing) requests' cost and the manual maintenance for the telemetry endpoints and storage was an impediment that Google just gives them a drop-in solution for :( I think Google is happy to eat some of…

While impractical, I liked the article's suggestion of blocking the proxies. I'm curious what reaction this would have. Ad blocking users get no content and move to alternatives and stop being users, or would the sites cave and realize having users interacting is more important than all of the data collected.
Post reply on HN