Google is phasing adblockers from the Chrome Store. Brave has a built in adblocker, but having more than one is more effective. How will Brave accommodate 3rd party adblockers in the future?
@Sleep1 already been answered a lot. Check out things like https://brave.com/blog/brave-shields-manifest-v3/
Also, why worry about 3rd party adblockers anyway? All you need is Brave Shields. It works better than the others and as is built into the browser it’s not impacted
3 Likes
What he said, but also a side note:
It is possible to add custom lists (from other ad blockers) to the Brave shields settings page if the good selection provided by Brave does not quite fit what you need.
Scroll down a bit from brave://settings/shields/filters
Example:
You will need to get the URLs from the ad blocker sites.
1 Like
Brave Shields is great, but it does sometimes lag behind uBlock Origin, especially when it comes to YouTube’s war on adblockers. I find it useful to keep uBO around and enabled on YouTube (and Brave Shields disabled there).
Fortunately, Brave lets you enable uBO in the settings.
Settings > Extensions > Manifest V2 Extensions > Enable uBlock Origin.
1 Like
Something new.
I love Brave even more now.
Interesting article, thanks for the link. One sentence in particular jumped out at me…
Since Shields are patched directly onto the open-source Chromium codebase, they don’t rely on MV2 or MV3.
Brave isn’t hooking into the webRequest API? I thought all ad/tracker blocking extensions had to, which is why its deprecation in favor of the far more restrictive declarativeWebRequest is causing so many issues. What is Brave hooking into?
1 Like
@theJman Brave has coded everything into Rust and it’s integrated into the browser.
Let me quote you something from Luke Mulks, VP of Business Operations at Brave, shared on Reddit:
Brave upgraded our ad blocking and tracking protection engine with Rust in 2019, this upgrade included a shift away from the webRequest API dependency that extensions rely on for blocking network requests.
Brave blocks ads and trackers from within the native browser code with our engine, meaning that this upcoming change with Manifest V3 does not impact Brave ad blocking and tracking protection.
Umm, nothing? I’m hesitating on the accuracy of my answer there. But as I quoted a bit above, Shields is built completely in Brave and running through the browser. It’s not having to call out and use any API for the adblocking to work.
Brave builds and maintains their own lists as well, such as you can see at https://github.com/brave/adblock-lists/tree/master/brave-lists and https://github.com/brave/adblock-lists/blob/master/brave-unbreak.txt These are all the syntax and all to block ads and keep things working.
As you know, we can add other lists, such as uBlock Annoyances or whatever. For those extra filters then it may use some API or whatever to fetch updates on those and would be pulling those directly from the source. It’s this portion here that makes me hesitant on how I’m answering in terms of saying not using API.
Keep in mind I’m no expert here and not promising 100% accuracy on the answer, but think it’s close enough. We would have to tag in Mattches or Fanboynz if you need to dive in deeper.
1 Like
That answered the question right there. My research showed every ad block extension hooked webRequest, I just assumed all ad blockers - embedded or otherwise - had to hook network requests in the same manner. Apparently not. Perhaps whatever Brave does to provide the functionality doesn’t have an exposed API, maybe that’s why it’s not available to the extension developers. Pretty forward thinking, they were ahead of the curve with that approach.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.