Just block Google tag manager itself. Gets two birds stoned at the same time.
Regardless, I use a DNS based ad blocker (pihole) and it takes care of all this stuff. I occasionally need to turn it off or whitelist domains (like Google tag manager) for client work, but normally I have it blocked.
Isn't the whole point of this new change that it runs server-side, using a proxy that you install on the website so it uses the same domain?
> Regardless, I use a DNS based ad blocker
But it's the same domain name isn't it?
Some processing happens on the server, but event data must still be sent to the server-side container first. For now, the "standard" deployment of a server-side is that it receives hits directly from the browser, orchestrated by a traditional client-side container. So the client-side script is still there, just less bloated.
The server-side container has built-in facilities for serving up the client-side container script. Meaning that domain-name blocking will not prevent this. DNS-based also has some issues: Server-Side Containers run in App Engine, blocking them basically means blocking anything running on GCP.
gtm javascript loads, pulls down the config, injects tracker X javascript into the browser
new gtm:
gtm javascript loads, pulls down config, streams events to google servers to fan out to tracker X as configured
So blocking gtm.js off tagmanager.google.com / www.googletagmanager.com / the various other domains still blocks all gtm injected tags.
The tl;dr is they're become much closer to segment -- which does the data fanout internally to segment. But they should still be straightforward to block.
[1] https://developers.google.com/tag-platform/tag-manager/serve...
There are a million ways to detect and block this sort of thing when you control the client. Yes, it's harder than just blackholing a whole domain, but it's hardly impossible.
I'll miss this extension.
I think this is why Raymond gave up on it.. I think for the masses his time is better spent on uBlock Origin.
Although the dev gave up on it, he's open to someone picking it up (if there are any brave souls on HN)
https://old.reddit.com/r/uBlockOrigin/comments/i240ds/reques...
https://news.ycombinator.com/item?id=26284124
The only thing that uBO doesn't support is controlling cookie access, so I still use uM for that.
That’s a pretty big "just", though. Very few sites work without fiddling with rules, having to do manual text entry every time would push me towards not using it.
The UI of uMatrix is generally far superior to the mobile-friendly, simplified one of uBo.
It is, but for me the pros outweigh the cons. In particular, even with uM I often ended up editing the rules by hand because it was easier to copy-paste and turn on and off rules for experimenting, but uM would forcibly resort the rules on save which made that annoying.
>Very few sites work without fiddling with rules,
The only sites I fiddle with the rules of are the ones I visit regularly, which is not many. Over the 1.5 years that I've been using this method, I've only got 75 "web properties" in my list (github.com, github.io and githubusercontent.com count as one "GitHub" web property; so the number of domains is a bit higher). Going by git history, I do have to fiddle with one or more rules once a month on average.
For other sites, either they work well enough with default settings, or I give up and close them, or if I really need to know what they say I use a different browser. For this other browser I never log in to anything, and have it configured to delete all history by default on exit. (I've been pondering making this an X-forwarded browser running on a different source IP, but haven't bothered.)
>The UI of uMatrix is generally far superior to the mobile-friendly, simplified one of uBo.
To be clear, editing the rules does not use the "mobile-friendly, simplified" uBO UI. It refers to the giant text field you see in the uBO "Dashboard", specifically the "My filters" tab.
But yes, it'd be the best of all worlds if uBO gains the table UI as an alternative to the filters textfield. I imagine the problem is that static filters are technically much more powerful than what the uM-style rules do, so it'd require inventing a third kind of rule, which isn't great.