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