3 ms·

> Google tag manager in my experience is a script executed by the browser. Isn't the whole point of this new change that it runs server-side, using a proxy tha

> Google tag manager in my experience is a script executed by the browser. 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?

lmkg 5y ago
A Server-Side GTM container compliments a client-side container, it does not fully replace 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.
- pixeldetracking 5y ago
  and you can host the container: https://developers.google.com/tag-platform/tag-manager/server-side/manual-setup-guide https://developers.google.com/tag-platform/tag-manager/serve...
x0x0 5y ago
Current GTM, configured (via the server UI) to inject tracker X: 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.
- volderette 5y ago
  This is not how GTM server side works. There is not a single call to Google domains from the client, when GTM server side is set up to its fullest. The config (gtm.js) will be loaded from my subdomain and not googletagmanager.com. Also gtm.js can be renamed.
  - xigoi 5y ago
    Couldn't you still recognize the script by its content?
    - ComodoHacker 5y ago
      Not with dynamic obfuscation.
    - shafyy 5y ago
      Exactly, this is already done for tracking scripts, since it's commong to use proxies to load tracking scripts.
    - freedomben 5y ago
      No because the script contents can change from site to site. Maintaining an index for every site would get you closer, but individual sites can trivially tweak things to break fingerprinting as often as they want. Even on every request.
  - x0x0 5y ago
    Per the docs here [1], that is not true. You continue to load gtag.js off the googletagmanager.com domain; subsequent events can flow to a custom domain. [1] https://developers.google.com/tag-platform/tag-manager/server-side/intro https://developers.google.com/tag-platform/tag-manager/serve...

lmkg 5y ago

A Server-Side GTM container compliments a client-side container, it does not fully replace 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.

pixeldetracking 5y ago
and you can host the container: https://developers.google.com/tag-platform/tag-manager/server-side/manual-setup-guide https://developers.google.com/tag-platform/tag-manager/serve...

x0x0 5y ago

Current GTM, configured (via the server UI) to inject tracker X: 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.

volderette 5y ago
This is not how GTM server side works. There is not a single call to Google domains from the client, when GTM server side is set up to its fullest. The config (gtm.js) will be loaded from my subdomain and not googletagmanager.com. Also gtm.js can be renamed.
- xigoi 5y ago
  Couldn't you still recognize the script by its content?
  - ComodoHacker 5y ago
    Not with dynamic obfuscation.
  - shafyy 5y ago
    Exactly, this is already done for tracking scripts, since it's commong to use proxies to load tracking scripts.
  - freedomben 5y ago
    No because the script contents can change from site to site. Maintaining an index for every site would get you closer, but individual sites can trivially tweak things to break fingerprinting as often as they want. Even on every request.
- x0x0 5y ago
  Per the docs here [1], that is not true. You continue to load gtag.js off the googletagmanager.com domain; subsequent events can flow to a custom domain. [1] https://developers.google.com/tag-platform/tag-manager/server-side/intro https://developers.google.com/tag-platform/tag-manager/serve...