Brave connects to googletagmanager.com

[fabi-hub]

Description

Brave connects to googletagmanager.com, when I open macrumors.com or other sites who use googletagmanager.
It's not happening with uBlock Origin.

Steps to Reproduce

1. Run the program Fiddler to monitor background traffic
2. Open https://www.macrumors.com/
3. Try the same with uBlock Origin

Actual result:

First Brave shows googletagmanager as blocked.

But if you look into Fiddler you'll see it's not

Expected result:

No connection to googletagmanager.com just like uBlock Origin

Reproduces how often:

Everytime

Brave version (brave://version info)

1.19.92 Chromium: 88.0.4324.152 (Offizieller Build) (64-Bit

Miscellaneous Information:

I used Fiddler for Windows
https://www.telerik.com/

[diracdeltas]

cc @ryanbr

[pes10k]

Hmm, im not able to reproduce on Nightly (1.25.13) at least (using mitmproxy and MacOS). @fabi-hub are you still seeing on current versions? I wonder if the script you're seeing might be calling it from the service worker, in which case it should be fixed as of #13781

Can you let us know if you're still seeing @fabi-hub, as this would be a serious problem if this is still happening

[fabi-hub]

I just downloaded Version 1.25.13 and it didn't changed for me. Gorhill explained why this is happening in Egde and Chome with uBlock Origin: "The blocked resources won't be parsed/processed/executed in the browser, however the pre-connections and DNS requests won't be prevented: https://imgur.com/a/HCY7Qdx." Link
Maybe it's the same issue with Brave.

When I look into the .js file from Googletagmanager, I get this:

---

uBlock Origin - a browser extension to block requests.
Copyright (C) 2019-present Raymond Hill

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see {http://www.gnu.org/licenses/}.

Home: https://github.com/gorhill/uBlock

*/

(function() {
'use strict';
const noopfn = function() {
};
const w = window;
w.ga = w.ga || noopfn;
const dl = w.dataLayer;
if ( dl instanceof Object === false ) { return; }
if ( dl.hide instanceof Object && typeof dl.hide.end === 'function' ) {
dl.hide.end();
}
if ( typeof dl.push === 'function' ) {
dl.push = function(o) {
if (
o instanceof Object &&
typeof o.eventCallback === 'function'
) {
setTimeout(o.eventCallback, 1);
}
};
}
})();

So at least not Googles code, but why uBlocks code? I don't have uBlock installed in Brave.
In Firefox with uBlock it works fine, no connection to Google.

[pes10k]

We ship the same resource replacements that uBlock Origin ships (more details here, we will also be shortly announcing how Brave will be generating and contributing additional resource replacements too.

If you're seeing the above uBlock resource replacement, you can be confident that nothing is being fetched from Google (my local test shows the same).

About why Fiddler reports a connection, I can't say at the moment (I do not have a Windows machine I can test on, though I am asking around Brave if others do). Its possible that what Gorhill is saying is correct, but it would be surprising; we disable DNS prefetching in general in Brave.

It may be the case that Chrome is pre-connecting before a blocking decision is made (that would be very surprising, extremely bad, and almost certainly a bug in Chrome, Brave, and other Chromium browsers). It wouldn't be a serious privacy leak (the preconnect setup doesn't include anything about the context, or cookies, or similar), but its still IP and unnecessary network work.

But, maybe that is the case, and the certainly stranger things have happened! I will get back to you ASAP with more information. Thank you for following up on the issue!

[pes10k]

just to follow up again real quick, after dipping into Wireshark, I am able to see DNS (and what i think is TLS preconnect) connections related to requests that end up being blocked (and, so are wasteful). Again, I think the privacy loss here is small (given the communication being done), but its not zero, and the current behavior is definitely wasteful, so its something we should sort out.

I'm talking with other Brave folks now, and I hope to have an update shortly

[pes10k]

One more quick update here. At least some of what you're seeing is the result of our CNAME decloaking implementation. This new issue, #15302, has more details, but, suffice it to say, this is indeed a bug (or at least, a place for perf improvement), and we're on it!

Its odd if Chrome shows the same thing though; i have no explanation for that!

[pes10k]

Last, I'm going to close this issue in favor of #15302, since that describes the fix that'll be implemented, an so can be tagged in a PR. If you are interested, please follow this topic there. And again, thank you very much for taking the time to report this!

[fabi-hub]

Thanks a lot,
I only tested it in Edge myself, so I can't say for Chrome

[Dryader]

Not sure if the fix has been implemented but I seem to have the same issue, using ublock origin with brave seems to allow all the network requests through even though they are blocked as well as just brave blocking. This link as an example. Excuse the large amount of blocklists. :D
imgur1 imgur2 I'm using NextDNS to see the network requests.
Same thing happens on android where the blocked requests show up in the logs. Curiously Firefox doesn't seem to have the same issue although I may be misunderstanding how brave works. Using ublock origin only with ad blocking off as well seems to yield the same issue although I think NextDNS' logging feature might be a bit behind as it sometimes shows up and sometimes doesn't.

[pes10k]

Hi @Dryader , the fix for this is being worked on here #15302 . The short of it is

1. we make DNS requests Chromium doesn't bc we check CNAME records when making blocking decisions
2. we make more than is optimal (i.e. there are cases where we could make the same blocking determination w/ less DNS traffic).
3. Fixing the above is captured in Prevent DNS lookups for CNAME decloaking for adblock for already-blocked requests #15302, and I expect we'll merge a PR fixing that issue very shortly (possibly even by EOW)
4. Importantly though, we are not fetching the actual request (at least in my testing). This means no communication with the server hosting the blocked request, no identifying information, etc. So, the privacy harm here is extremely low, but its not zero, and its inefficient either way, so we're fixing the issue 👍

Hope that helps (and all credit to @antonok-edm who is working on the fix)

[Dryader]

@pes10k good to hear, thanks for replying. :D