How to use a Tag Manager

Description of the issue:
Our website ( uses Google Tag Manager, which seems to be blocked by default on Brave. Certainly many of the underlying tags we load are analytics and personalization focused platforms, and it makes sense that Brave would block these by default. However, we also use it to manage some things that are very functional, and shouldn’t require an update to our CMS or a code deployment to manage… things like our GDPR compliant Cookie-Consent manager. GTM in and of itself is not a tracking platform… it is simply used to aid in loading external code that can’t/shouldn’t be coupled with backend site code. How can we ensure that our tag manager itself isn’t blocked, but the underlying tracking scripts that Brave consider’s in violation of maintaining privacy are?

Exact URL of the website in question:

Screenshot of the ad as it appears in Brave

Did the issue present with default Shields settings? (yes/no)

Does the site function as expected when Shields are turned off?

Is there a specific Shields configuration that causes the site to break? If so, tell us that configuration. (yes/no):
no - tested out of the box

Does the site work as expected when using Chrome?

Brave version (check About Brave):
Version 1.4.96 Chromium: 80.0.3987.132 (Official Build) (64-bit)

Googletags is blocked by default due to privacy concerns (with google). Brave uses Easyprivacy list which blocks these script by default (less 3rd-party scripts being loaded, the better).

Can’t be removed due to privacy.

Google Tag Manager is not intrinsically tied to analytics. Certainly most people add analytics with it, but it has a legitimate purpose for managing functional, non-tracking focused code as well. Are there any tag management solutions that Brave doesn’t block?

Most, if not all 3rd-party tag management servers. For the enduser (the user actually browsing the site) has little need for tags, this is where privacy is important to us and users expect it.

Having less unnecessary 3rd-party items loaded is a good thing.

I think that these are misclassified. Tag management platforms themselves do not inherently do anything to jeopardize someones privacy while browsing the web. They are simply a mechanism to load code. How they are used is different from site to site, and the underlying code that is loaded is what should be scrutinized.

As developers move towards modern web infrastructures like the JAMStack, we become increasingly dependent on connections to SaaS based services to offer the best experience possible on the web. Blocking things like this in a blanket fashion will most certainly be bad for both developers AND users.

Does the Brave team have any sort of a plan for SaaS based platforms, that offer legitimate services that websites and web users need/want, to meet some sort of minimum privacy focused requirements to ensure they are not blocked by such wide sweeping rules?

In the same breath, there are certainly methods of collecting analytics that do not reveal who people are or violate their privacy, but still provide a record of actions so that marketers can gain insights into whether or not the content and designs and development efforts they are focusing are worthwhile. Aside from only being allowed to use Brave’s analytics platform, how are marketers and marketing departments to continue gaining these insights if Brave starts to gain significant usage traction? I’m genuinely curious.

Specifically re: Google Tag Manager

Addt’l security and privacy issues from custom script execution through GTM services:

More broadly re: publisher tag solutions, options, etc.
Brave ships with strong default privacy protection from multiple levels, but the user has agency over their global and site-level protection settings. We make these settings accessible from the URL bar, and include a link directly to global settings.

Our users expect a stronger level of default privacy protection and security from our product, and our mission is to execute and deliver new business lines that can operate and scale with the platform.

The first-order is to provide default privacy in a way that can scale for mainstream users without wrecking the experience.

In parallel, we’ve introduced new alternative protocols, and deployed them across millions of browsers in the wild. This is the groundwork that can help drive broader privacy protocol adoption, but the fundamentals must function for users first. Otherwise, we’d likely be on a short path to being the neatest science experiment for privacy collecting dust on a shelf.

As we scale, the growth becomes of higher interest to publishers, and becomes a forcing-function to continue to adapt existing platforms to accept new protocols. We’re already doing this from the advertising side. We have +400K creators and publishers that have verified to accept revenue from our platform ( Interest and experimentation from publishers has been growing with our user base.

There are a handful of different privacy approaches being introduced in-market. iTP has an impact in a major way. Google is trying a lighter approach. We have been consistently leading and executing on one of the strongest privacy approaches, and are aiming to prove out the revenue model for publishers at scale, as we scale.

Hope this wasn’t too vague, but the privacy model is a bit different. Hope it helps with context.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.