5 ms·

Interesting, I had not heard about this (looks like it was announced at the most recent WWDC), but the Vimium devs already have![1] Vimium and uBlock Origin ar

by jez 6y ago

Interesting, I had not heard about this (looks like it was announced at the most recent WWDC), but the Vimium devs already have![1] Vimium and uBlock Origin are pretty much the only two plugins keeping me from switching away from Chrome/Firefox to Safari. Given all the hype around Safari’s performance on new M1 Macs (and the fact that only Safari supports Apple Pay), I’d love to have parity on these two extensions extensions. It seeems like Web Extensions will not provide enough to fully support uBlock Origin, but maybe their Content Blockers will be a close enough approximation. At the very least, I hope that Safari will gain a larger userbase from these changes, regardless what I choose to use. Having multiple large, evenly distributed userbases will only make web developers think more about Chrome-first or Chrome-only development. [1] https://github.com/philc/vimium/issues/3610 https://github.com/philc/vimium/issues/3610

Merman_Mike 6y ago
> 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)?
- krbzsq 6y ago
  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.
  - _qulr 6y ago
    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/WebExtensions/API/webRequest/BlockingResponse https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
    - Merman_Mike 6y ago
      Did Apple give a reason? Privacy? I could see a privacy case in not letting any and every extension have access to all requests.
      - machello13 6y ago
        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).
      - gorhill 6y ago
        > 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/WebExtensions/API/webRequest/onBeforeRequest#Browser_compatibility https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
        Merman_Mike 6y ago
        Thanks for this. I'll stop propagating that. What reason does Apple give for not allowing blocking, then?
        paulryanrogers 6y ago
        My guess would be maintenance cost.
        _qulr 6y ago
        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/sfsafariextensionhandling/3238030-contentblocker 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.
- fiddlerwoaroof 6y ago
  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.
- runjake 6y ago
  It’s probably not. https://github.com/el1t/uBlock-Safari/issues/158 https://github.com/el1t/uBlock-Safari/issues/158
jumpman500 6y ago
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 https://github.com/el1t/uBlock-Safari/issues/158
- neurobashing 6y ago
  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.
  - kitsunesoba 6y ago
    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.
- lotsofpulp 6y ago
  I’ve been using safari + Wipr and I haven’t noticed any big difference.
  - ashishgandhi 6y ago
    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.
    - drcongo 6y ago
      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.

by jez 6y ago

Merman_Mike 6y ago

> 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)?

krbzsq 6y ago
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.
- _qulr 6y ago
  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/WebExtensions/API/webRequest/BlockingResponse https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
  - Merman_Mike 6y ago
    Did Apple give a reason? Privacy? I could see a privacy case in not letting any and every extension have access to all requests.
    - machello13 6y ago
      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).
    - gorhill 6y ago
      > 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/WebExtensions/API/webRequest/onBeforeRequest#Browser_compatibility https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
      - Merman_Mike 6y ago
        Thanks for this. I'll stop propagating that. What reason does Apple give for not allowing blocking, then?
        paulryanrogers 6y ago
        My guess would be maintenance cost.
      - _qulr 6y ago
        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/sfsafariextensionhandling/3238030-contentblocker 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.
fiddlerwoaroof 6y ago
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.
runjake 6y ago
It’s probably not. https://github.com/el1t/uBlock-Safari/issues/158 https://github.com/el1t/uBlock-Safari/issues/158

jumpman500 6y ago

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 https://github.com/el1t/uBlock-Safari/issues/158

neurobashing 6y ago
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.
- kitsunesoba 6y ago
  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.
lotsofpulp 6y ago
I’ve been using safari + Wipr and I haven’t noticed any big difference.
- ashishgandhi 6y ago
  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.
  - drcongo 6y ago
    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.