Safari 12 compatible versions of ad blockers fail to block many ads

adblocksafarisafari-extensions

Since installing Safari 12 and switching to the compatible version of my adblocker(s), many ads that were once successfully blocked by each of those adblockers are now visible, with the result that many frequently visited sites are (to this ad-allergic user) unusable.

Is this likely to be a temporary situation as the features for the compatible adblockers are (quickly!) improved and stabilized, and capabilities of my old adblockers are restored? Or is this the result of limitations imposed by the new Safari 12 architecture, and thus likely to persist (or improve glacially)?

Best Answer

The situation is likely to persist.

Content blockers that are offered by Safari are limited to 50000 entries. uBlockOrigin needs many more for example. 1Blocker for iOS circumvents that with a trick, using many of these and combining them. This is another builtin technical limitation, making 1Blocker inherently less effective.

In any case, these are different from the concept used in the traditional blockers – requiring a rewrite. Apple says these would be "faster and safer". Maybe. All we see is that our tried and tested favourite extensions do not work anymore, and if there are any successors even ready, they are apparently not up to the task on the level many were accustomed to.

Coupled with the newly enforced restrictions for devs requiring App Store distribution, this disincentivises independent developers. The latter are artificial policy enforcements. This raises the cost for the devs and will likely result in the withdrawal of most useful plugins altogether.

TamperMonkey and uBlockOrigin or JSBlocker devs are not happy. And for those three at least, it seems they have dropped the ball, citing the need for App Store distribution and certification as too costly, too much hassle, not worth it, bad on some fundamental principles:

Safari/iOS: Unfortunately, after legal review, the EFF found Apple's developer agreement unacceptable. Furthermore, Safari seems to lack certain extension capabilities required by Privacy Badger to function properly.

And in its current iteration, the technology of content blockers as too limited in principle for blocking all that needs to be blocked. uBlockorigin cites the same reasons as JSBlocker:

Safari has a feature called "Content Blockers" that allows for extremely efficient resource blocking on both the desktop and iOS version of Safari. As much as I'd like to incorporate this into JS Blocker, it is not feasible to do so. Using a content blocker will prevent JS Blocker from showing you exactly what's going on on a website (i.e. you won't see what's allowed or blocked.) It will also break all of JS Blocker's "other" features, such as showing alerts within the webpage and canvas fingerprinting protection. Besides the loss of features, content blockers are limited to 50,000 rules. While this seems like a high number, it isn't enough for efficient protection and a lot of rules would need to be cut out to even run a content blocker. Until Apple eases the restrictions (or at least raises the number of rules that can be in a content blocker), JS Blocker will not be using this API.

And:

Safari App Extension

I have no experience creating native mac apps; it will therefore be impossible for me to re-create JSB as one.

Users who downloaded JS Blocker from the Safari Extension Gallery will probably not be able to update beyond 5.2.2. Apple is not responding to my requests for updates despite them saying they will accept submissions until the end of 2018.

We all need to complain to Apple directly and massively. It's a pity we haven't done so during the shocking beta phase.

Use Product Feedback - Apple, email, chat, your blog, or even better yet a developer feedback channel, file bugs.

Zotero connector is going to circumvent the stupidity enforced by switching to bookmarklets, other things break left and right and in the middle. This is just much too strict:

Enable Your App Extension in Safari If you’re not part of the Apple Development Program, or if you haven’t yet configured a developer identity for your existing Xcode project, your Safari App Extension won’t be signed with a development certificate. For security purposes, Safari, by default, ignores unsigned extensions, so your extension won’t show up in Safari Extensions preferences. To develop without a certificate, each time Safari is launched, you must tell it to load unsigned extensions using the Develop menu:

Many might think it's about money, but for some, it's indeed more the technical parting of the ways:

Safari Support As of RES v5.2.2, Safari is no longer a supported browser and will not receive updates or support from the development team. We want to support Safari and provide a good user experience for all, however we need Apple's support with this by improving extension development and publishing experiences.

Apple have announced that as of Safari 12, support for this style of extension will be deprecated and will no longer work.

Why did we do it?

It ultimately came down to the direction development of Safari extensions was heading. Major browsers such as Google Chrome, Microsoft Edge and Mozilla Firefox were all adopting a standard commonly known as "WebExtensions". This provides a single API across all browsers. This is hugely beneficial as you can develop for all major browsers from a single code base. Safari is not adopting this standard and instead moving to their own format, with a strong reliance on Xcode. This would require significant investment from the development team to support the browser, as well as core developers having access to Xcode. Supporting this change would mean the codebase for RES would not be unified.

Dropping Safari support was never solely about money as many think it is, we do not have a vendetta against Apple. The discussion lasted many weeks and it was not something we took lightly.

Complain, complain, …or switch to another browser.


After you have rightfully complained to Apple, workarounds:

  1. go back to host based blocking (example) [do that anyway?]
  2. use a local proxy, like https://privoxy.og (alternative upto Sierra (discontinued)) [do that anyway?]
  3. combine both options with what is now available as extensions
  4. re-enable uBlockorigin (incomplete solution and development has apparently stopped. Seems to need the gallery version, not the developer version)
  5. switch to ka-block (not as effective as older methods, but efficient and free of charge, probably trustworthy?)

For the time being, you may want to stay with/downgrade to Safari 11.1.2 (not for very long though.) Or re-enable uBlockorigin in the preferences ignoring the misleading warnings about slow down or security. (This is cumbersome and I always lose all my custom settings on application relaunch. You will need the extensions-gallery version)


Not recommended, only listed to illustrate the dire situation!

The shady non-'origin' version of ublock seems to be back in the game, although with the 50000 limit mentioned above.
Plus: Use with caution, not sanctioned by upstream uBlockorigin https://github.com/gorhill/uBlock :

ublock.org says:

But that’s in the process of changing. If you’ve noticed recent updates to the product, that’s because uBlock has been acquired by the team responsible for AdBlock. We will be investing heavily into uBlock to help it deliver on the promise of being one of the best ad blockers available.

Equally shady Adblockplus is also back. Be informed that the owner company sells your data and sells ads ("only acceptable ones of course"). And limitations are still big. From the comments on that release:

The sense of Adblock Plus is totally lost without filter Lists. Button “Uninstall” is missing in Safari! How to remove your AdBlock-extension manually?