5 ms·

The webRequest API is not supported in Safari, so extensions like uBlock Origin cannot be ported in their current form. It's unfortunate that Apple is not embr

The webRequest API is not supported in Safari, so extensions like uBlock Origin cannot be ported in their current form. It's unfortunate that Apple is not embracing the webRequest API, since it's so much more than a tool for content blocking. Requests are a core feature of any browser, and not allowing extensions to control and edit requests hinders innovation among browser extensions. The notifications API is also missing in Safari, so extensions must use the native messaging API to show notifications from the native app extension.

kitsunesoba 6y ago
I am not a browser developer, but the impression I get is that the issue with the webRequest API is that the amount of overhead that can be added to a function that's invoked extremely frequently (loading resources) is unbounded and difficult to optimize. It entrusts a pillar of browser performance to extension developers, which is a dicey proposition. This leads me to think that if Apple were to add support for something like the webRequest API, it'd likely be via the native half of the extension API and potentially even Swift-only so there can be stronger guarantees on things like execution time. This may also allow users of the API to better take advantage of multithreading for more complex operations. I may be misunderstanding something about how the webRequest API is traditionally implemented that deals with these concerns however, in which case feel free to correct me.
- gorhill 6y ago
  I tweeted recently about a research paper which found that the performance argument does not hold, see https://twitter.com/gorhill/status/1345743193179095040 https://twitter.com/gorhill/status/1345743193179095040
asiando 6y ago
Chrome will also drop that soon and only allow a tiny fraction of extensions to continue using it. This is in the name of security. Whether you believe that is up to you, but personally I don’t even install extensions that require access to all of my tabs, let alone something that can read pure requests (with the exception of uBlock)

kitsunesoba 6y ago

I am not a browser developer, but the impression I get is that the issue with the webRequest API is that the amount of overhead that can be added to a function that's invoked extremely frequently (loading resources) is unbounded and difficult to optimize. It entrusts a pillar of browser performance to extension developers, which is a dicey proposition. This leads me to think that if Apple were to add support for something like the webRequest API, it'd likely be via the native half of the extension API and potentially even Swift-only so there can be stronger guarantees on things like execution time. This may also allow users of the API to better take advantage of multithreading for more complex operations. I may be misunderstanding something about how the webRequest API is traditionally implemented that deals with these concerns however, in which case feel free to correct me.

gorhill 6y ago
I tweeted recently about a research paper which found that the performance argument does not hold, see https://twitter.com/gorhill/status/1345743193179095040 https://twitter.com/gorhill/status/1345743193179095040

asiando 6y ago

Chrome will also drop that soon and only allow a tiny fraction of extensions to continue using it. This is in the name of security. Whether you believe that is up to you, but personally I don’t even install extensions that require access to all of my tabs, let alone something that can read pure requests (with the exception of uBlock)