5 ms·

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.

by krbzsq 6y ago

_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.
    - stephenr 6y ago
      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.
    - ffpip 6y ago
      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!

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.

by 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.
  - stephenr 6y ago
    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.
  - ffpip 6y ago
    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!