uBlocksOrigin for Mojave

[212rikanmofo]

I am currently running ublocks Origin v1.16.0, but it says that this current version will slow down your web browsing. Is there an updated version that gets rid of this warning and will run on Mojave?

Or can somebody with Mojave compile and build this from scratch and share it?

 

[upandown]

I’m curious what exactly prompts that warning message. (I don’t have the message on HS) I too have been hoping for an update and continued support, as I know it’s the best program for the job.

Can you actually notice a slow down? Is it that bad? Or perhaps it’s a generic flag because it meets some out of date criteria. I know it needs updating but largely it still blocks content correctly and gets updated lists everyday. At least for now I would continue using it if I were you.

 

[212rikanmofo]

i don't notice any slow downs at all, but like you said it could need an update because of some out of date info that needs to be updated. But I hope for an official update.

 

[shinyleaf]

The warning appears because uBlocks origin uses the old javascript based Safari Extension mechanism to filter and block ads / urls from loading. Starting in Mojave, this mechanism has been deprecated by Apple. Developers are encouraged to use Safari's Content Blocker extensions (the same one that provide ad blocking on iOS), because they are much faster and more efficient.

 

[212rikanmofo]

Safari's Content Blocker extension? could you explain what this is? Is it a built-in thing?

 

[upandown]

The warning appears because uBlocks origin uses the old javascript based Safari Extension mechanism to filter and block ads / urls from loading. Starting in Mojave, this mechanism has been deprecated by Apple. Developers are encouraged to use Safari's Content Blocker extensions (the same one that provide ad blocking on iOS), because they are much faster and more efficient.

Have they lifted the number of filters that can be used to block content? When it came out it was a measly 50k I believe in apples API.

Although apples heart is in the right place, using the old JavaScript with ALL of the filters you want, is actually more effective. Especially these days...

As far as performance, I believe uBlock Origin is negligible in the amount of additional resources used than using Apples API. And that’s with using 3-4 times more filters. That’s almost a non-existent trade off for better blocking.

I admit I don’t know the full extent of changes in Mojaves API but this is how it’s been.

 

[shinyleaf]

Have they lifted the number of filters that can be used to block content? When it came out it was a measly 50k I believe in apples API.

Although apples heart is in the right place, using the old JavaScript with ALL of the filters you want, is actually more effective. Especially these days...

As far as performance, I believe uBlock Origin is negligible in the amount of additional resources used than using Apples API. And that’s with using 3-4 times more filters. That’s almost a non-existent trade off for better blocking.

I admit I don’t know the full extent of changes in Mojaves API but this is how it’s been.

It's less about 'performance' but more energy usage. uBlock Origin, running javascript code has to process and filter often 100+ resource urls on a single page load. In contrast the content blocker compiles into native code 1 time (on list update), and at page load ~300-1000x less processing time required. The user perceived performance might be the same, but the energy usage over hundreds of page load each day adds up quickly.

It's not exactly a 50k hard limit, but varies on each platform. When the filter rules are loaded and compiled, it is tested to see if it crosses a performance threshold. There's been subsequent posts on webkit mailing list and blog on how to optimize for it. Back when it came out, the limit was being hit because developers were directly porting EasyList or other blocking lists directly to the Webkit Content Blocker format. Today, most lists are optimized for the webkit format and significantly smaller than 50k.

Also, a single blocker extension can load multiple lists.

 

[upandown]

It's less about 'performance' but more energy usage. uBlock Origin, running javascript code has to process and filter often 100+ resource urls on a single page load. In contrast the content blocker compiles into native code 1 time (on list update), and at page load ~300-1000x less processing time required. The user perceived performance might be the same, but the energy usage over hundreds of page load each day adds up quickly.

It's not exactly a 50k hard limit, but varies on each platform. When the filter rules are loaded and compiled, it is tested to see if it crosses a performance threshold. There's been subsequent posts on webkit mailing list and blog on how to optimize for it. Back when it came out, the limit was being hit because developers were directly porting EasyList or other blocking lists directly to the Webkit Content Blocker format. Today, most lists are optimized for the webkit format and significantly smaller than 50k.

Also, a single blocker extension can load multiple lists.

Performance can be described from different criteria such as efficiency, which I thought was obvious in the context of my sentence when I referenced 'additional resources'. Vis-a-vis energy usage; cpu resources, memory resources etc.

Thank you for the explanation though. Glad to hear it's been better optimized. I was excited when the feature was released but was disappointed when it didn't offer an advantage right off the bat.

The uBlock Origin team set themselves apart due to the fact their entire mission is to block content because they feel its our right to do so. And don't sell data to advertisers. So switching to a new blocker would need to be with one that doesn't develop for nefarious reasons.

Do you have a program that you recommend? I currently have over 200k network + cosmetic filters loaded. Can the native API handle that many? Essentially handle the same filters with the new process?

 

[Troy2000]

The information provided by previous posters is correct, however I believe that a clarification may be in order.

uBlock Origin will perform just as well under Mojave as it did under prior versions of OS X. It relies upon exactly the same JavaScript mechanism as it did under High Sierra. The warning message simply serves to inform you that the extension could deliver superior performance, were it to adopt Apple's new mechanism.

 

[s2s]

uBlock Origin for Safari hasn't been updated since April, it seems dead...

Javascript (old Safari extension) developers may not have enough skillset to port the code to Xcode (new Safari app extension).

Those old Safari extensions like uBlock Origin (and many other Ad Blockers) will continue to work in Safari 12 if you ignore the warning, but Apple will stop this somewhere in 2019.

There are many ported Ad Blockers available in Mac AppStore, simply search for "Ad Block", but none of them are comparable with the old Safari-based extensions, you can't subscribe to custom filters for example.

The only fully functional Ad Block for Safari 12 is AdGuard, unfortunately it is not really a content blocker for Safari, it is a network-level filter, it works well with down side: your internet speed/latency will be impacted.