backlit

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, hides 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 secrecy 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 raft of steps to combat third-party content-blocking by trying to shift 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 practises 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 original goal 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.

"This renders Tag Manager basically useless, even though it can still, in itself, load."

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 is designed to 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.

One of the workarounds now being used by preds who full-on will not take no for an answer, is to port 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. But it has limited mileage. Running Tag Manager 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. The core of the system can run, and there's nothing we can do to prevent that.

However, 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. However, there are 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. 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.

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, even though it can still, in itself, load. Some 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 many pages that do load may 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. Librewolf has this feature and so, again, it made a good choice.

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 track you.

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. That's how cybertech's punishment system works. 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 on the page, you'll need to hit the More button near the base of the dialogue. All reported domains except the first-party at the top should have red identifiers, indicating that they're blocked. If you're seeing greens or ambers for any third party domains, the rule is not working in your particular browser. Try ||.$third-party in this instance.

Method 4... Allow JavaScript, images and third-party content, but shut down your Web connection once the page has loaded. Try this method when you're forced to view a JavaScript-dependent page. The surveillanceware will 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 them to the website after the connection reopens. See my service workers post on blogspot for full details on how to incapacitate them. This method does not protect you anything like as well as the above three, but it will normally allow you to view the page without disruption, whilst avoiding the most dystopian of the spyware.

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 tracking 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?