How to Fully Incapacitate Google Tag Manager and Why You Should

"We're long past the days when it was possible to simply say "no" to corporate stalking without consequence. Today, when we say "no", we get punished for it. But that only goes to show WHY, more than ever, we should be saying "no"."

Google Tag Manager. It's a product which, by design, cloaks a range of the Internet's most invasive and unethical scripts in an opaque closet, then springs them out in disguise. Combining immense power with obfuscation and vast scale of use, Google Tag Manager is the WWW's single most destructive tool to public privacy and online ethicism.

And it's getting worse. Google is now driving Tag Manager into the first-party domain, switching from third-party to first-party cookie usage, for example. Whilst this may look like a warm-hearted bid to increase privacy protection for the public, it's really just part of Google's relentless string of attempts to circumvent third-party content-blocking by shifting surveillanceware into a first-party container.

This probably also explains why Google has not sought to prevent site admins from running Tag Manager on the server-side, despite such practices technically breaching this line in the Tag Manager ToS...

"You agree not to... interfere with or circumvent any aspect of the Service;"

I'll come to the burning issue of server-side GTM usage in due course, but don't worry, there are solutions...

WHAT DOES GOOGLE TAG MANAGER DO?

Whilst Google would love the general public to believe that Tag Manager covers a wide range of general purpose duties, it's almost exclusively used for one thing: surveillance. Tag Manager's close link with Google Analytics has ballooned the level of intrusion we now face across the bulk of the Web, as well as making Google Analytics more covert and more resistant to blocking.

Making Google Analytics harder to block was fairly evidently not part of Tag Manager's original brief upon launch, circa 1st October 2012. The goal back then was probably just to put Google's finger on the pulse of third-party people-profiling strategies and maintain the giant's ad-tech dominance on a classic knowledge-is-power basis.

"Using this blocking method, GTM will run if it's on the server-side, but none of the scripts it launches will work."

Conversely, Tag Manager's now inseparable companion, Google Analytics 4, was born at a time when content-blocking (as opposed to just ad-blocking) was going mainstream. With the proportion of people blocking at least some form of third-party surveillanceware estmitated to be heading for 40%, Google Analytics was under existential threat. In this light, GA4's orientation towards Tag Manager definitely did appear to be an attempt to sidestep content-blocking, and hide Google Analytics in a more general container which most of the public would not identify as a harbour for surveillanceware.

A general container which content-blockers with weak algorithms notably do not block. And which can evade blocking altogether if relocated to the first-party domain.

But thinking positively, our takeaway should be: Google recognises that we, the great, content-blocking public, have successfully rendered the old, Universal Google Analytics unfit for purpose. UGA is being deprecated next year. That's right - we won a battle against Google! Our next challenge is to kill off UGA's replacement - Google Analytics 4 + Tag Manager - in the same way.

That will be harder, because the new system can punish those who incapacitate it. So is it worth the bother?...

Definitely! And here's why...

WHY GOOGLE ANALYTICS IS NOW A MUCH GREATER SURVEILLANCE DANGER

Once upon a time, Google Analytics existed as a simple means to record website traffic volume and generalised user behaviour, so as to determine which content performed the best, and offer pointers on improving the appeal of future content.

Not anymore. Used in conjunction with Tag Manager, Google Analytics now offers scope for much more detailed behaviour-monitoring. As a result, it's commonly used to uniquely identify individual people, engage them in experiments, build dossiers on them, analyse those dossiers for psychological vulnerabilities, and then exploit those vulnerabilities unethically, for profit. Let's be clear. That's what Google Analytics is now about.

"Tracking is not only getting more aggressive - it's also getting more sneaky. We don't know where the tracking utility will be located, so we can't rely on URL-based block-lists."

In times past, there was a barrier to entry into this field, since only the site admins serious enough to hire cutting-edge developers could turn a website into a hardcore surveillance machine. But Google Tag Manager now makes the integration of powerful spyware into such a straightforward DIY task, that any random half-ass who decides to open a website can build, exploit and/or sell detailed dossiers on real people. Tag Manager has not reduced the barrier to entry. It's completely removed it.

The GA4 + Tag Manager combo records page scrolling, mouse clicks, mouse movements, screen touches, key taps, media engagements - any movement you make on the page, basically. It also times visits and attention spans a lot more accurately than the old Google Analytics. Coupled with your identity - also monitored by Google Analytics - this type of lab-ratting is obviously a licence to exploit psychological traits. Mental health issues, even.

Meanwhile, Google Tag Manager is regularly popping up on Government sites. This means not only that governments can study you in more depth - but also that Google gets to follow you into much more private spaces.

The more of us who incapacitate Google's analytics products and their support mechanism, the better. Not just for the good of each individual person implementing the blocks - but in a wider sense, because if enough people block Google Analytics 4, it will go the same way as Universal Google Analytics. These products rely on gaining access to the majority of Web users. If too many people block them, they become useless and have to be withdrawn.

DOES RUNNING TAG MANAGER FROM THE SERVER-SIDE REALLY CIRCUMVENT BLOCKING?

This has become a burning question of the moment.

Used as supplied, Google Tag Manager can be blocked by third-party content-blocker extensions. uBlock Origin blocks GTM by default, and some browsers with native content-blocking based on uBO - such as Brave - will block it too.

Some preds, however, full-on will not take no for an answer, and they use a workaround to circumvent these blocking mechanisms. What they do is transfer Google Tag Manager and its connected analytics to the server side of the Web connection. This trick turns a third-party resource into a first-party resource. Tag Manager itself becomes unblockable. But running GTM on the server does not lay the site admin a golden egg...

"Block cookies. All of them. Third-party and first. Some third-party cookies are now masquerading as first-party cookies, which means they'll still function if you only block third-party."

True: technically, we cannot block something in the browser if it doesn't run in the browser. If it's running on a remote server we can't reach it.

But equally, we have a switch that the surveillance-crazed website cannot reach. If we essentially cut off the power at our end of the connnection, the tentacles of the surveillance system will fail to extract their detailed information. The tracker can thus only gather limited data. Tag Manager itself is only a launcher. Without the tentacles it fires up, it's useless.

DISABLE JAVASCRIPT

The power supply that fuels almost all of Tag Manager's tentacles - including Google Analytics - is JavaScript. So if you universally disable JavaScript, you destroy most of Tag Manager's surveillance potential.

When you universally disable JavaScript, you're killing keyloggers, mouse-monitors, service workers, a huge range of fingerprinting tools, and an unthinkable number of other aggressive spyware routines. And disabling JavaScript even hits first-party trackers. That protects you against third-party scripts running from the website's own server, in cases where the functionality of those scripts necessarily happens on the client-side.

"Admins whose static pages won't work without JavaScript are really just telling on themselves."

As an example, let's say a site wanted to run extensive Google Analytics 4 assessments and a separate typing forensics routine, via Tag Manager, from the server-side. All of these processes have been relocated to the first-party domain, which enables them to bypass third-party content-blocking. With default settings, uBlock Origin will not prevent the site from monitoring you in this situation. But if you universally block JavaScript, neither Google Analytics nor the forensics program will work, since both require client-side scripting to monitor your actions, and you've disabled it.

BUT I HEARD TAG MANAGER CAN WORK WITH JAVASCRIPT DISABLED

It can. Tag Manager has a noscript iFrame fallback that kicks in when the regular JavaScript version is unable to run. I know! How telling that Google provides noscript compatibility for a piece of unmitigated spyware, but not for a content delivery platform like YouTube. That's surveillance capitalism for ya. But Tag Manager's ability to run in all weathers does not overcome two almighty problems for the trackers...

Nearly all the actual tools launched with Tag Manager require client-side JavaScript to run, so whilst Tag Manager will fire them in any circumstance, if JavaScript is disabled in the browser, the individual "tags" won't work. This applies even if Tag Manager is running on the server-side.
With JavaScript disabled, Tag Manager can be used to sub in a custom image, which means a tracking pixel can still be loaded. However, there are separate ways to block the tracking pixel, which I'll come to shortly.

THE PRICE OF DISABLING JAVASCRIPT

Given the above implications, spyware-ridden websites really, really, really, REALLY don't want you disabling JavaScript. That's why most of Web 2.0, a sizeable proportion of e-commerce, and even a quota of Web 1.0 has been re-engineered to deliberately break when JavaScript is not enabled in the browser.

No static Web page needs JavaScript to display. None. The reason so many of them won't load without JS is that the administrations calculatedly sabotaged the natural functionality of the HTML page code to deliberately break their sites. The sites were then rebuilt, at considerable expense, to function only when JavaScript is enabled. The sole purpose of breaking natural, pre-existing page functionality (like text/image display, hyperlink and button activity, etc.) is to punish or completely exclude any visitor who will not accept script-based surveillance. Think of it like this...

"If a page can display a message that says: 'Please enable JavaScript', why can't that page display the rest of its text? The answer is: it can. Which means the rest of the text on the page was deliberately hidden."

So if you land on a static page - like a blog post, a privacy policy or an index - and it doesn't work without JavaScript, you know that the site has deliberately sabotaged the natural capability of that page in order to force you to enable active scripting. The admins are really just telling on themselves. You should be monumentally suspicious of that site's motives.

Whilst there will be a lot of sites we can't access with JavaScript disabled, most of them have a better-behaved alternative. And the more of us who simply backstep off JS-dependent pages to find an alternative, the more powerful the message we will collectively send to them. They can only withstand a minority of lost visitors. If the losses to competitors are too heavy, then they are forced to provide a noscript option once more. Unless you have no choice, seek to cut out JS-dependent sites. When you encounter one, don't focus on the content you can't see. Focus on the abused lab rat that you will become if you submit to their terms.

Let's now look at some different methods for incapacitating Google Tag Manager...

OPTIONS FOR PREVENTION

Tracking is not only getting more aggressive - it's also getting more sneaky. We don't know where the tracking utility will be located, so we can't rely on URL-based block-lists. And we don't know what Tag Manager will fire, because the whole point of it is to allow a site admin complete flexibility.

So what do we know? We know that Tag Manager itself can be set up to evade all generalised privacy protections for a non-proxied connection. We know that if JavaScript is disabled, Tag Manager can run, but the only thing it can fire is a tracking pixel, or web beacon, or whatever else you want to call an unnecessary image load from a third-party domain.

So here are the options...

Pre-requisite... Block cookies. All of them. Third-party and first. Some third-party cookies are now masquerading as first-party cookies, which means they'll still function if you only block third-party. If you need cookies for specific sites, clear the domains as exceptions. You can do this in Firefox or Chromium-based browsers. Better still, use separate browsers for the sites that need cookies, and keep cookies fully disabled when randomly browsing. If you need to log into Google services (or multiple services from another tech giant), group all of the services into one browser, allow it to accept first-party cookies, and don't use that browser for anything else.

Blocking cookies while randomly browsing won't just block the actual text file drops. Most browsers interpret numerous "other technologies" as cookies too. Chromium and its derivatives, for example, will not accept service workers or local data dumps for a site whose first-party cookies are blocked.

Method 1... Disable all JavaScript and all image loading in your browser. This method is for those who don't want to use a browser extension. It renders Tag Manager basically useless, as neither scripts nor tracking pixels can load. But GTM can still, in itself, run. Various third-party surveillanceware not connected with Tag Manager can potentially load too. The downside? Nearly all pages will be in some way disrupted. No images will display, most of Web 2.0 will not display at all, and some pages that do load will display with a corrupt layout. On information-based pages you can usually iron out the layout problems by using a Firefox-based browser and engaging the Reader Mode from the icon to the immediate right of the URL bar.

Method 2... Disable JavaScript using uBlock Origin. Install uBlock Origin if you don't already have it, and simply click the Disable JavaScript tick box in its settings. That tick box is a master switch, like the native switch in a browser, but it can more easily be disengaged per site when you actually do need JavaScript. Provided you trust uBO, this method is better than Method 1, because if Google Tag Manager is running on the client-side, uBlock's third-party prohibitions will prevent it from loading at all. GTM will run if it's on the server-side, but none of the scripts it launches will work. uBlock Origin will try to minimise the disruption to pages, but in order to do that it will let through some third-party page elements as dependencies. Those "dependencies" will normally allow Big Tech to verify your whereabouts, but not micro-monitor your behaviour.

Method 3... This is an extreme version of the above, which affords much more watertight privacy, but also results in much more disruption to pages. Use uBlock Origin with JavaScript disabled, as described above, but also with ALL third-party content hard-blocked. To achieve the latter, you need to add the rule ||.^$third-party to the My Filters pane. Test to see if the rule is working by clicking the uBlock shield icon on the browser toolbar as you visit sites. If you can't see a rundown of the individual trackers in the uBlock dropdown, you'll need to hit the More button near the base of its dialogue. All reported domains except the first-party at the top should have red identifiers, indicating that they're blocked. With all third-party content blocked, you won't have to worry about tracking pixels. They can theoretically load from the first-party domain, but that would be pointless because the first-party site knows you're there anyway.

Method 4... Use uBlock Origin with JavaScript enabled, but shut down your Web connection once the page has loaded. Try this method when you're forced to view a JavaScript-dependent page. Surveillance scripts running from the server-side will probably load, but so-called "events" can't be monitored, because there's no connection through which live data transfer can travel. If you have cookies enabled, the site can still potentially use a service worker to monitor scrolls and events locally and then send the data to the website after the connection reopens. This is a compelling reason why you should block cookies. See my service workers post on blogspot for full details on how to incapacitate them.

Method 5... Use the Lynx browser in conjunction with Frogfind. This will only show you the text on a given page, but if the page is loadable, you should get a readable layout, and you don't have to think about anything as regards blocking. Lynx will just block every piece of surveillanceware if used with cookies disabled, as described in the post I linked to.

ADDITIONAL ADVICE RE THE ABOVE

Don't disable JavaScript both in your browser's native controls and uBlock Origin at the same time. Use one or the other.

If you're using Method 1, you can feasibly tighten your privacy further by loading a blacklist into your hosts file to block third-party content. There are quite a few of these blacklists on Github - just search for hosts file blacklist on a search engine. This will, however, slow down your system, and it's not as watertight as Method 3.

If you decide to block images (which stops tracking pixels from loading), blocking them in the browser is much more reliable than blocking them with an extension.

CLOSING COMMENT

Comprehensively incapacitating Google Tag Manager, and indeed maintaining online privacy in general, does not come without sacrifice. We're long past the days when it was possible to simply say "no" to corporate stalking without consequence. Today, when we say "no", we get punished for it. But that only goes to show WHY, more than ever, we should be saying "no". Do you really want to be dealing with people who punish you when you ask not to be exploited?