custom filters fail www.google-analytics.com & www.googletagmanager.com

[privacy-advo]

Description

Custom filter not blocking www.google-analytics.com and www.googletagmanager.com on https://www.uefa.com/.

Steps to reproduce

1. Use custom filters (brave://settings/shields/filters) to block www.google-analytics.com and www.googletagmanager.com. Use fonts.googleapis.com as comparison.

   www.google-analytics.com
   www.googletagmanager.com
   fonts.googleapis.com

2. visit https://www.uefa.com
3. Repeat with different syntax a) ||www.google-analytics.com^ ||www.googletagmanager.com^ ||fonts.googleapis.com^ b) ||google-analytics.com^ ||googletagmanager.com^ ||fonts.googleapis.com^

Actual result

Expected result

www.google-analytics.com
www.googletagmanager.com
fonts.googleapis.com

blocked

Reproduces how often

Easily reproduced

Brave version (brave://version info)

1.67.119 Chromium: 126.0.6478.114 (Official Build) (64-bit) 36e2dbd9e397c3a8a4d54a741ea5a6316eab0203

Channel information

• [X] release (stable)
• [ ] beta
• [ ] nightly

Reproducibility

• [ ] with Brave Shields disabled
• [X] with Brave Rewards disabled
• [ ] in the latest version of Chrome

Miscellaneous information

No response

[ghost]

1. Those filters are already applied so you don't need to add them as 'custom filters'
2. They don't get blocked, they get redirected. You need to click the files next time, you will see it says they are uBlock, which means they are being redirected and uBlock resources are being used instead.
3. $redirect or $redirect-rule will take priority over anything, even ,important because redirect means "block and redirect" so it does both things while redirect-rule just means to redirect a blocked connection. This means the only way to properly block these connections is by $badfilter uBlock redirect rule because Easylist already block them, but this doesn't apply to Brave because custom rules can't badfilter default rules. But inside Brave you should be able to get them blocked by using $important like this:

   @@||google-analytics.com/analytics.js$script,redirect=google-analytics_analytics.js:5
   ||google-analytics.com^$script,important

4. While devtools will not mention anything about it, redirected network requests will not have a Remote Address, which is an easy way to tell that a resource was blocked, because even if the file is in the Disk Cache, it will always have a remote IP attached to it. So while it looks like these connections are being 'allowed', if you enable that column, you can easily see the difference. Also, even if Devtools take these rules as 'delivered', and there is no indication of $redirect like you get in uBlock logger. You can still see Brave's Shields panel will you these connections got blocked.

   

So, as you can see this is a expected behavior. I know it's not easy to tell, but people should understand adblocking stopped being "block network requests" and "hide html nodes" long time ago. Also, people need to stop adding custom adblock rules that are already covered by uBlock/Easylist and therefore applied to Brave, because Brave uses the same default lists uBlock has + Brave lists and Brave supports most features from uBlock lists and Easylist, so the big trackers and ads are already covered. This is all the full catalog of Brave default lists and regional lists https://github.com/brave/adblock-resources/blob/master/filter_lists/list_catalog.json

Why a redirection? because some sites detect the adblocker by detecting X or Y request wasn't made, so redirecting will reduce that by making the site pretend it got the real file, when it is a modified one without the trackers, you can modify the redirection. the current uBlock rule has a priority of :5 so you just need to add a bigger number and you can add noopJS or whatever if you wanted. In

There are many types of resources, from Scriptlets to Redirections and you can check all of them here:

https://github.com/gorhill/uBlock/wiki/Resources-Library#empty-redirect-resources

Hope this helps to clarify things. I will delete this comment, so no need to at me or anything. You can just close the issue.

[privacy-advo]

Thanks for your time and the explanation. Looking at payload would have helped. Thanks for pointing that out.

Those filters are already applied so you don't need to add them as 'custom filters'

I stumbled apon this behaviour while testing Brave's native blocking capabilities. I'm aware that, hence good for testing, those popular domains are already covered.

I will delete this comment, so no need to at me or anything. You can just close the issue.

You shouldn't do it. It is valuable to other people too.

Plus: Brave should definitly add a logger.

[ghost]

If you want to properly test things, you can disable Default lists. You find them in %localappdata%\BraveSoftware\Brave-Browser*\User Data\gkboaolpopklhgplhaaiboijnklogmbc\ then you modify the resources.json in whatever is the latest version and set the "hidden" to false and you will see Brave Ad Block Updater and Brave Ad Block First Party Filters in brave://settings/shields/filters and easily disable them. It works until the catalog gets updated again, a new version will hide them again.

Then you can load the lists as custom lists, and that way you get a better experience since you can create exception rules, for scriptlets: #@#+js(), cosmetics: #@#, and the $badfilter.

The only one that has a workaround is cosmetics exception by using :style() operator and cancel the cosmetic but adding :style(display: block !important;) or whatever is needed by the element.

Brave has two adblock engines, one for default lists and one for regional/custom lists-rules and custom ones and that's why they can't touch Default lists, as I have noticed, seems like custom lists/rules get the same features, in the past you wouldn't get all the features, but now I can use generic cosmetics and all.

Modifying the adblocker is easy and simple, unlike extensions where you don't have this kind of freedom to modify the component lists and add whatever you want (not limited to adblocker, you can add your own clear-URLs and debounce entries). I use folder permissions to also avoid the 'writing' for new versions, like of resources like the ones from uBlock, you can totally add new resources if you want in Brave. I even use uBo Scriptlets and my own and modify whatever Adblocker devs don't want to implement and do, so I make the changes myself and keep it for myself.

Anyway, that's beyond what this issue is about, but yeah.

For missing features, you can search uBo-party in adblock-rust repository, but I made a comment a year ago in the first issue unhandled options that shows all the unsupported features like $popup, $to, $all.

I didn't include procedurals because since Chromium got :has() support, I try to make my filters without any procedural, since they are slower to apply. But it seems Brave will support Procedurals soon. You can test the performance between native vs Procedural with Performance tabs in Devtools, you will see how slow procedurals apply compared to native CSS selectors and pseudo classes. In fact, Brave is way faster than uBlock applying normal cosmetics, in Brave there is no flickering/hiding, while in uBlock is like few milliseconds where you could see it being hidden, but it's so fast, it's not noticeable.

Recently Nightly added support for the other style operators :remove(), :remove-class() and :remove-attr() too.

Well, hope this helps you to make your tests and things better! I run Default lists as custom lists, and the only advantage is Default lists will not include the #!if firefox lines (soon, when Brave merge their PR) that cause a lot of trouble, but I can create my exception rule if needed, just as Brave team does it today in the Brave unbreak, so I don't care. Another side effect is Brave will start slower, for a few seconds it will not load pages, but once the few seconds have passed, then it works normally.

Take care and have a good day.