Same. I can't use Safari without Ublock Origin. The web is a horrible place without it.

[1] https://github.com/el1t/uBlock-Safari/issues/158

I’ve been using safari + Wipr and I haven’t noticed any big difference.

I will actually second this. Wipr is really good.

Also, generally speaking, the way Safari implements this means that the extension passes on the block list to the browser and Safari itself implements the blocking. This means,

1. It is more private since the extension does not have access to your webpage. 2. It is faster because Safari can do it natively and it is not done in JavaScript.

Too true. I have Safari with 1Blocker / Wipr, through a PiHole that uses NextDNS for DNS resolution. All other browsers feel like wading through treacle. Whenever I'm forced to use Chrome on someone else's device I'm gobsmacked at how anyone could put up with something so slow and clunky.

for what it's worth I've got a Pi-Hole running on my local network instead of in-browser adblock, and it's pretty good, and before that i had some success with 1Blocker, which IIRC uses the same lists as uBlock Origin.

YMMV (probably depends on the subset of the web that one visits) but I've had good luck with Wipr under Safari. Once in a while something slips through but it's generally ~99% as effective as uBO when it comes to visible ads. The difference is small enough that I'm not inclined to use a different browser.

> Vimium and uBlock Origin are pretty much the only two plugins keeping me from switching away from Chrome/Firefox to Safari.

+1, especially uBO

Does anyone know the latest on uBO coming to Safari (or not)?

I’ve been pretty happy with 1blocker for Safari. It’s not as flexible as Ublock, but it seems to do a good enough job.

I was under the impression that certain functions required by uBlock Origin still weren't available even though Apple embraced WebExtensions. I may be wrong.

You are correct. Safari does not support webRequest blocking and will almost certainly never support it. Indeed, Google Chrome has already announced its deprecation of this API.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Did Apple give a reason? Privacy?

I could see a privacy case in not letting any and every extension have access to all requests.

> a privacy case in not letting any and every extension have access to all requests.

People keep making that argument, and I keep having to correct this.

Their webRequest is not blocking but it does support _observing_ all network requests[1], just as is planned with ManifestV3.

The privacy argument can't and shouldn't be used to justify the removal of the blocking capability from the webRequest API.

---

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

It should be noted that there's a significant difference between Safari and Chrome in this respect, however. Safari content blockers are not actually JavaScript at all, they're nothing more than JSON rules, so content blockers have no webRequest API usage whatsoever. Whereas Chrome extensions are JavaScript, with webRequest capabilities.

Safari Mac does have JavaScript extensions too (iOS only supports content blockers), and everything gorhill says does apply to them. And indeed some vendors ship both a content blocker and a Safari JavaScript extension in the same Mac app (though each one has to be enabled separately in Safari). Thus, it could be argued that this is a distinction without a difference. But from a technical perspective they're entirely different technologies.

The macOS 10.15 SDK did add an API for a Safari JS extension to receive information from a content blocker embedded in the same Mac app, allowing for example the extension to show stats for blocked resources: https://developer.apple.com/documentation/safariservices/sfs...

My personal theory is that Safari content blockers were designed primarily for iOS, which has no Safari web extensions, and the Mac side was a bit of an afterthought.

Thanks for this. I'll stop propagating that.

What reason does Apple give for not allowing blocking, then?

My guess would be maintenance cost.

I think the privacy argument is that extensions cannot steal cookies. The current model grants extensions permission to steal cookie values right?

I am unfamiliar, so please feel free to correct me. Thanks for uBO!

You can observe `Cookie` header with a webRequest.onHeadersReceived listener.

Documentation about what can be observed or not is all available online, there is no need to make any assumption:

Firefox: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Chromium: https://developer.chrome.com/docs/extensions/reference/webRe...

That should answer all questions regarding what can be observed.

Thanks for the links. I should read up on that. So the privacy argument is false.

The difference is that I can choose to enable a content blocker that has no JavaScript component and know that it can’t observe what I browse.

I can also choose to enable an extension that does have JavaScript and know that it could observe what I browse.

That's almost certainly what it is, in addition to performance. Apple supports ad-blockers, but they work by providing a list of rules to Safari, which uses the rules to filter resource loading (rather than allowing the ad-blocker to intercept individual requests).

It’s probably not.

https://github.com/el1t/uBlock-Safari/issues/158