3 ms·

It definitely can’t be replaced by a traditional blacker. All the blockers for Safari are one step above worthless, and have been since they changed their plug

by parsimo2010 6y ago

It definitely can’t be replaced by a traditional blacker. All the blockers for Safari are one step above worthless, and have been since they changed their plugin architecture.

acdha 6y ago
It’s interesting that you make this claim when the hostname & type scheme described above is what Safari uses. Can you explain what’s different?
- parsimo2010 6y ago
  Disclaimer: I don't develop ad blockers or any other plugins, and the change I'm actually the maddest about is that uBlock Origin stopped working when Apple stopped supporting WebExtensions. I may be less mad about uMatrix simply because it wasn't on Safari in the first place. I'm not 100% sure on the reason why uMatrix wasn't available on Safari, but I think it's because content blockers aren't allowed to see any user data. Ad blocking plugins just send a list of content to block to the content blocking API, and Safari does all the blocking and doesn't send any data to the plugin. So uMatrix's intuitive UI that GP was talking about isn't possible. Apple claimed that they stopped supporting WebExtensions and made the content blocking API in the interest of user privacy, but all it really did was drive users to other browsers. In typical Apple fashion, they decided what was best for me when (AFAIK) I've never had a problem with an untrustworthy plugin stealing my information. It might technically be possible to functionally implement uMatrix with multiple plugins (one to interact with the DOM to figure out what to block, then generate the blocking list, and one to deal with the content blocking API) but all the plugins I've seen don't do it. Maybe it's not possible, maybe the extra development effort isn't worth it to support a single browser that has fairly low usage.
  - acdha 6y ago
    > Apple claimed that they stopped supporting WebExtensions and made the content blocking API in the interest of user privacy, but all it really did was drive users to other browsers. I’m not sure I’ve seen that - the number of Safari users had been pretty constant on my sites, and the main pressure seem to be the Chrome pushes on Google sites. I think the UI challenges of Safari’s approach are a big problem but on the other hand there were years of people blaming browsers for ABP’s bad performance and users privacy was definitely sold out by unethical developers. As a user it definitely is easier to trust one over the other.
  - saagarjha 6y ago
    > one to interact with the DOM to figure out what to block, then generate the blocking list, and one to deal with the content blocking API No, it's not possible to do performantly. You can't dynamically update your blocking list that quickly, the JSON rule list must go through WebKit and that can easily take multiple seconds.
bscphil 6y ago
When I have to use Safari, I use AdGuard, which has been surprisingly decent though less reliable than uBlock on Firefox. I believe that, for reasons unknown to me, it's allowed to install and use a local component outside the web browser, which significantly increases its capabilities. I was under the impression that WebExtensions was supposed to vastly reduce your security exposure from using extensions, but if anything in AdGuard's case it seems more intrusive.
- saagarjha 6y ago
  Apple uses this model because they believe that an application on your computer that has been codesigned is more secure than a web extension that you could ostensibly install without Apple being in the loop. This is very clear if you look at how they've implemented their Web Extensions support in Safari 14.

It definitely can’t be replaced by a traditional blacker. All the blockers for Safari are one step above worthless, and have been since they changed their plugin architecture.

acdha 6y ago

It’s interesting that you make this claim when the hostname & type scheme described above is what Safari uses. Can you explain what’s different?

parsimo2010 6y ago
Disclaimer: I don't develop ad blockers or any other plugins, and the change I'm actually the maddest about is that uBlock Origin stopped working when Apple stopped supporting WebExtensions. I may be less mad about uMatrix simply because it wasn't on Safari in the first place. I'm not 100% sure on the reason why uMatrix wasn't available on Safari, but I think it's because content blockers aren't allowed to see any user data. Ad blocking plugins just send a list of content to block to the content blocking API, and Safari does all the blocking and doesn't send any data to the plugin. So uMatrix's intuitive UI that GP was talking about isn't possible. Apple claimed that they stopped supporting WebExtensions and made the content blocking API in the interest of user privacy, but all it really did was drive users to other browsers. In typical Apple fashion, they decided what was best for me when (AFAIK) I've never had a problem with an untrustworthy plugin stealing my information. It might technically be possible to functionally implement uMatrix with multiple plugins (one to interact with the DOM to figure out what to block, then generate the blocking list, and one to deal with the content blocking API) but all the plugins I've seen don't do it. Maybe it's not possible, maybe the extra development effort isn't worth it to support a single browser that has fairly low usage.
- acdha 6y ago
  > Apple claimed that they stopped supporting WebExtensions and made the content blocking API in the interest of user privacy, but all it really did was drive users to other browsers. I’m not sure I’ve seen that - the number of Safari users had been pretty constant on my sites, and the main pressure seem to be the Chrome pushes on Google sites. I think the UI challenges of Safari’s approach are a big problem but on the other hand there were years of people blaming browsers for ABP’s bad performance and users privacy was definitely sold out by unethical developers. As a user it definitely is easier to trust one over the other.
- saagarjha 6y ago
  > one to interact with the DOM to figure out what to block, then generate the blocking list, and one to deal with the content blocking API No, it's not possible to do performantly. You can't dynamically update your blocking list that quickly, the JSON rule list must go through WebKit and that can easily take multiple seconds.

bscphil 6y ago

When I have to use Safari, I use AdGuard, which has been surprisingly decent though less reliable than uBlock on Firefox. I believe that, for reasons unknown to me, it's allowed to install and use a local component outside the web browser, which significantly increases its capabilities. I was under the impression that WebExtensions was supposed to vastly reduce your security exposure from using extensions, but if anything in AdGuard's case it seems more intrusive.

saagarjha 6y ago
Apple uses this model because they believe that an application on your computer that has been codesigned is more secure than a web extension that you could ostensibly install without Apple being in the loop. This is very clear if you look at how they've implemented their Web Extensions support in Safari 14.