EDIT May 25, 2021: Google Tag Manager's "Server-Side Tagging" is evolving, and bypassing adblockers is becoming easier and simpler. I added the section “One step ahead of adblockers” to the article.
Google Tag Manager, the Trojan horse for marketing teams
Google Tag Manager is a TMS (Tag Management System): it allows marketing teams to add trackers to a website or application, without having to go through developers. Via a web interface, these teams can decide:
- Trackers to trigger (analytics, A/B testing, attribution, etc.).
- Trigger conditions (page categories, user characteristics, etc.).
- Data to be transmitted to these third-party tools (user characteristics, navigation data, variables present on the page, etc.).
It is not the only one (we can for example cite Segment, French TagCommander or Matomo Tag Manager) but Google Tag Manager is ultra dominant:
Google Tag Manager is present on 31.9% of the top 10 million Alexa websites, according to W3Techs, but above all Google Tag Manager has a market share of 99.4% on TMS (!)
How was Google able to assert itself again? Just like with Google Analytics, the standard version of Google Tag Manager is free (market solutions generally charge a fee), it is very well integrated with other Google solutions and it is well made.
Trackers that are no longer called from your browser
Last August, Google announces a new version of Google Tag Manager, called Server-Side Tagging. Here is a Google schema to explain how Google Tag Manager works in the Client-Side Tagging version (the “historical” version):
Google Tag Manager will allow the triggering of various third-party trackers (in the diagram: Google Analytics, Google Ads, and an analytics tool), directly on your browser.
In the new Server-Side version, third-party trackers are no longer run from your browser but from a server"Proxy" called "Server container" in the diagram below (and hosted at Google):
The javascript library (called "Tag Manager web container" in the diagram) still runs on your browser in order to collect your interactions and your personal data, but the execution of the various third-party trackers takes place on the server side.
Note that this new version also applies to applications and the collection of “offline” data (to transmit in-store purchases for example):
Diagram of Simo Ahava's blog : on the server side, the "Clients" are there to translate the HTTP requests received into "events", the "Tags" react to these events to send "hits" to third-party marketing companies.
This logic for triggering third-party server-side trackers is a game-changer. Simo Ahava detailed the different impacts in an excellent article, I will for my part summarize the advantages and focus on the problems for your privacy (operating on the server side can make it possible to circumvent your choices and leak your personal data, without being unmasked).
Better user experience
On most websites, the number of JavaScript libraries loaded by third parties (for analytics, advertising, A/B testing, etc.) is impressive. Loading and executing these libraries is often the main cause of a poor user experience: site slowness and lack of interactivity.
Consequences for websites offering a poor user experience: less satisfied Internet users, who will abandon navigation directly or not return.
Here is an example with Le Bon Coin, this calls countless number of javascript libraries :
A small part of the javascript scripts called on the Le Bon Coin home page, this leaks your personal data to many third parties.
In the best scenario, the website will only install a single javascript library (the events can be very different between tools that do not have the same goals, the website will sometimes use more than a single library). This could be that of Google Tag Manager but not necessarily: it is possible to create your own library or to use other libraries on the market such as Snowplow, Matomo, AT Internet, etc.
Then instructs this library to send the “hits” with the parameters required during key interactions. Then the "client" of the server container will have to translate these "hits" into events, these will be read by the "Tags" which will send "hits" to third-party marketing companies. Note that if the JavaScript library installed on the site is provided by Google, the "client" is already pre-configured in Google Tag Manager. If the website uses another library, it will need to create its own "client" in Google Tag Manager (example with AT Internet), while waiting to have pre-configured “clients” for the main javascript tracking libraries.
Advantage therefore: a single javascript tracking library is installed on the website and a single “flow” of data coming from the browser, the user should see the difference.
Better control over data transmitted to third parties
Having a server-side "proxy" allows you to control the data transmitted to third parties (which is much more difficult when the trackers are directly executed by the user's browser):
- By default and unlike the "client-side" version, the IP address and User-Agent (browser name, version, operating system, language, etc.) of the user are not leaked (which avoids user identification via "fingerprinting"). The publisher using the Server-Side Tagging version of Google Tag Manager can decide to transmit this information to third parties, but this is not automatic.
- It often happens that personal information is leaked to third parties via URL parameters (read for example the article "Google Tag Manager Server-Side — How To Manage Custom Vendor Tags"), Server-Side Tagging helps prevent this.
- Generally speaking, the publisher has control over the personal data and cookies sent by its "proxy" to third parties (read Google technical documentation, note for example the get_cookies and set_cookies methods). He can therefore “clean” the information and send only what is strictly necessary to third parties.
Example with an AT Internet hit "seen" by the "proxy" server, the website can decide not to transmit the user's IP address and User-Agent to AT Internet.
A better secure website
Set up a Content-Security Policy (CSP) allows a publisher to better protect itself against different types of threats including attacks XSS (Cross-Site Scripting) and content injections. By adding a header to web server responses, the site can tell browsers which resources (scripts, css, etc.) are allowed.
Here is an example of CSP documented by Google :
Content-Security-Policy: script-src 'self' https://apis.google.com.
Which means: the browser only has the right to execute scripts that come directly from the site consulted ('self') or apis.google.com. And here is how your browser will react if a malicious script then tries to run from the site consulted:
The evil.js script is not hosted on the site consulted, nor on apis.google.com: its execution is blocked by the browser.
By greatly reducing the third-party domains authorized to execute javascript code, the CSP becomes more robust.
If Server-Side Tagging has advantages for users consenting to marketing surveillance (speed, security), it jeopardizes the protections of non-consenting users.
A bypass of browser protections
The "proxy" server is hosted in the Google cloud (instance AppEngine) but Google advises to link the App Engine domain to a subdomain of its clients' site (without explaining the reasons):
The default server-side tagging deployment is hosted on an App Engine domain. We recommend that you modify the deployment to use a subdomain of your website instead.
The link between the App Engine domain and the client subdomain, documented by Google.
Google does not recommend a CNAME (alias) DNS record, but a DNS record type A or AAAA, directly linked to the IP addresses of Google App Engine, which acts as host. The “proxy” server is therefore well considered by browsers as 1st party, and the consequences are therefore significant.
In particular, cookies placed by the “proxy” server are not third-party cookies, nor cookies created via javascript, nor cookies placed by a CNAME domain. They are therefore authorized, without restriction:
- Safari via Intelligent Tracking Prevention (ITP) restricts the lifespan of cookies created in javascript to 7 days (example: 1st-party cookies created by Google Analytics). Thanks to the “proxy” server, third-party trackers now override this limitation.
- Always Safari via ITP now restricts cookies placed via a CNAME domain to 7 days. Thanks to the “proxy” server, third-party trackers are not affected by this limitation.
- Brave on his side blocks CNAME requests to known trackers. Still thanks to the “proxy” server, third-party trackers avoid this blocking.
A bypass of adblockers
Your adblocker (uBlock Origin on Firefox for example), your content blocker (Firefox Focus or Adguard on iOS for example) or your DNS blocker (NextDNS for example) works on your device. It can thus detect third-party trackers and block them before your personal data is leaked.
None of this with the Server-Side Tagging version of Google Tag Manager: personal data leaks take place from the client's proxy server (hosted in the Google cloud) to third parties. You therefore no longer have control to avoid these leaks.
You might say to yourself: just block the first call, that of your browser to the javascript library in charge of collecting the data and communicating to the "proxy" server. Except that this javascript library can very well be accessible on the domain of the website (and not on a Google domain for example). Also, Google already recommend for its clients to change their scripts gtag.js in order to enter the domain of the proxy server. This manipulation already makes blocking via domain name inoperative.
All Google tracking libraries (gtag.js, analytics.js but also gtm.js, Google's "advanced" library, in charge of Google Tag Manager) can be hosted on its own domain.
Via Simo Amaha's blog.
If gtag.js or gtm.js are javascript libraries whose names are known to the main adblockers, they will have to find other methods when the name of the javascript library has been modified or sites have created their own libraries.
uBlock Origin, effective against CNAME cloaking on Firefox, powerless against Server-Side Tagging?
One step ahead of adblockers
The Google Tag Manager javascript library is called gtm.js, it is called with the container identifier: GTM-.... An adblocker can therefore easily target these names and block the loading of this library. A website could decide to create its own JavaScript library, but it's not that easy.
But always thanks to Simo Ahava, it is now easy to choose another name for the javascript library gtm.js and hide the container identifier (no need to create your own javascript library):
Via Simo Ahava’s blog : with Simo's "GTM Loader" template, the website can rename the javascript library ("Request Path") and hide the container identifier ("Override Container ID" checked, "Container ID" empty).
Also, if it were possible on the adblockers side to target Google proxy, a website can now host the server container elsewhere (on Amazon AWS, Microsoft Azure, OVH... or on its own infrastructure). It's not that easy, but Google provides the Docker image and steps to follow.
Simo Ahava thus indicates the procedure to follow for deploy the server container on Amazon AWS while Mark Edmondson details how deploy the server container on Google Cloud Run (another Google Cloud Platform service, different from Google App Engine).
How can adblockers react?
The subject is not obvious, here are some ideas but I am not sure that they are feasible:
- Automatically detect these "1st party" calls to the "proxy" server via sent URL parameters. Except that these URL parameters will change from one site to another, depending on the library used, the page viewed, etc.
- Detect the javascript library responsible for calls to the “proxy” server to block its execution. As we have seen, this method will not work if the website renames the Google Tag Manager library or develop your own javascript library.
- Block proxies, at the risk of blocking essential website functionalities? Also, this method does not work if the website decides tohost the server container on its own infrastructure.
- Never run javascript on your browser, for example with the NoScript extension, radically configured. Effective option, except that many websites will no longer work.
Leak your personal data in total opacity
Although many websites today leak your personal data, often without your consent, it is nevertheless possible to audit the sites, prove the violation of consent and document the leaks. The CNIL could, for example, do its job and sanction mistakes. None of this with Server-Side Tagging, a site can now very easily:
- Give the appearance of consent by letting you respond to a consent banner.
- While leaking your personal data to multiple third parties, without an external auditor being able to realize it (he will simply see the "1st-party" call to the "proxy" server, without knowing if the personal data is used, shared or resold behind).
Your data on the Google cloud
By default, the "proxy" server logs all requests it receives :
By default, App Engine logs information about every single request (e.g. request path, query parameters, etc) that it receives.
But the personal data contained in these queries is not the only information leaking to Google. Everything as for CNAME cloaking, cookies associated with the domain of the site consulted are sent to the subdomain of the “proxy” server. So, if your session cookies are associated with the site domain (and not a separate subdomain), they will be sent to the Google cloud.
This one declares that the data hosted on its cloud belongs to the customer, and not to Google. However, you have to trust Google.
Server-Side Tagging, probably soon widely adopted
If Server-Side solutions had existed on the market for a long time, and if it was already possible to develop your own "proxy", the launch of Google's solution will probably have a huge impact on the adoption of Server-Side Tagging:
- Google Tag Manager is present on a considerable number of websites, it is ultra-dominant.
- Google presents this version as a evolution TMS tools, improving the performance and security of websites.
- Big argument for marketers, leak your personal data to Facebook.
A Google Analytics tag can hide the leak of your personal data to Facebook, combo!
Even if a Google Tag Manager client can continue to use the Client-Side version, even if the Server-Side version still has limits (few third-party libraries, certain solutions will have difficulty being supported, etc.), even if learning the solution is complex and even if it is often paid (Google App Engine invoice for the "proxy" server), we can therefore bet that Google Tag Manager clients will gradually migrate to this version.
Bypassing adblockers and other browser protections, a selling point
As we have seen, Google doesn't explain the reason for creating a subdomain of the website for its “proxy” server:
The default server-side tagging deployment is hosted on an App Engine domain. We recommend that you modify the deployment to use a subdomain of your website instead.
There is no need for it, bypassing browser protections and adblockers have already been listed as "benefits" by numerous publications:
- "Server-side Tagging In Google Tag Manager" by Simo Ahava, the article indicates the benefit of being able to bypass Safari's limitations regarding the lifespan of JavaScript cookies. To his credit, the author does not want to give details on the fact that Server-Side Tagging makes it possible to bypass adblockers and indicates that the collection of data must be done after obtaining consent.
- "GTM Server Side – The natural evolution for your tagging?" from Converteo. The article lists the advantages of being able to bypass browser limitations such as those of Safari and Firefox, as well as bypassing adblockers.
- "Introduction to Google Tag Manager Server-side Tagging", from the Analytics mania blog. Here too, bypasses of browser and adblocker limitations are listed as benefits.
- "Google introduces server-side tagging, good news?" by Nicolas Jaimes on the JDN. The angle of the article is advertising, and therefore bypassing browser protections is listed as a benefit (even if for the moment, the lack of third-party libraries means that Server-Side Tagging remains complex to implement).
Unfortunately, it's a safe bet that many sites will also be attracted by these "benefits", in addition to the gains in performance, security and control. The inability to audit websites will also be a big loss for privacy advocates. Hoping that browsers and adblockers find solutions so that Internet users concerned about their privacy can continue to defend themselves.