uBlock-Safari VS brave-core

You are mistaken. Safari removed the APIs necessary for an uBlock port (there used to be one), see https://github.com/el1t/uBlock-Safari/issues/158.

Injecting code via Web Extensions is too late for reliable blocking - by then, either the malicious JS you are trying to defuse has already ran (if it wasn't blocked declaratively), or if it hasn't, then the rest of the page's JS depending on it has already exploded and "fixing" it after the fact (by substituting a neutered shim via Web Extensions) doesn't fix the rest of the page.

It has been there but won't ever be again: https://github.com/el1t/uBlock-Safari/issues/158

Better to fork it and maintain as another project, like previous ublock's project on safari: https://github.com/el1t/uBlock-Safari

Brilliant move not supporting normal Webextensions though. https://github.com/el1t/uBlock-Safari/issues/158

Looks like the answer is no, Safari is not supported.

> ..as of 2022, uBlock Origin’s extension is available for several of the most widely used browsers, including: Chrome, Chromium, Edge, Opera, Firefox and all Safari releases prior to 13.

https://ublockorigin.com/

Explanation of the state of uBlock Origin (and other blockers) for Safari - https://github.com/el1t/uBlock-Safari/issues/158

Apparently, the only WebKit-based browser that can run uBO is Orion browser (beta, Mac only).

https://browser.kagi.com/

You probably can't. Safari crippled adblockers a while back. Here's a longer explanation from the developers of the best blocking extension.

Unrelated but about Brave and interesting to me: I recently found myself having a large upstream project that I need to maintain some custom patches for, and there's a need for deeper customizations and I worry that my rudimentary system of applying .patch files will turn into an unmaintainable nightmare of merge conflicts after every rebase. I was thinking about possible solutions, and it occurred to me that Brave being Chromium-based must have this same challenge but an order of magnitude more difficult, so I looked for their code to see how they solved this issue.

It's pretty interesting! They do basically the same thing for core Chromium, applying a (big) set of patches[1].

Incidentally, I'd be interested to hear any ideas/approaches to this problem. I'm guessing if there was something clearly better, Brave would be doing it, but it seems like there should be a better way even if I can't think of one.

[1] https://github.com/brave/brave-core/tree/master/patches

https://github.com/brave/brave-core/pull/13737

(Incidentally, that PR number is not quite elite. :)

I disagree that it's lip service Brave has a ton of engine level privacy patches https://github.com/brave/brave-core/tree/master/patches

To my understanding you can't match it with just js extensions.

Only firefox on the highest security mode comes close I think?

Or ungoogled chromium? (brave has most of their patches IIRC)

Are there other options that have this number of patches?

Chromium is not 100% Google's forever and always, though they do currently lead the way, and with the most used/backed fork.

https://github.com/brave/brave-core/pull/19476

They have much more changes than just compile flags. Here's the repo where they maintain their patch set: https://github.com/brave/brave-core/tree/master/patches

Brave Private Ads toggle controls just Push Notification ads at this time. So, if you are still seeing Push Notification ads, that would be incorrect. However, it's normal to still see New Tab Page image ads, and/or other ad formats. We are introducing a new UI that helps you better toggle on/off specific ad units, and removing the "Brave Private Ads" toggle that can be confusing: https://github.com/brave/brave-core/pull/18938

Yes, being fixed. Github at https://github.com/brave/brave-core/pull/18922