5 ms·

And ironically Safari has the worst adblocking capability of the 3. Open source is the only effective weapon against corporate control of software.

• hombre_fatal 7y ago
  Safari's (Webkit's) declarative adblocker is really good while optimizing for performance and battery life. Have you tried 1Blocker X? Though, for fun, I've rolled my own Safari extension for content blocking. You get 90%+ of the way just concatenating lists of ad domains and feeding them into the blocker. But, for example, you can encode all of Easylist as content-blocker rules.
  • shawnz 7y ago
    Chrome is now moving to a declarative model and it is widely considered to be a downgrade purposely meant to stifle ad-blocking technology. I think the ideal system would support declarative and non-declarative modes (since a fully declarative system could never account for every possible use case).
    • hombre_fatal 7y ago
      I can see that given the choice between declarative rules vs. a "onRequest(req)" handler, almost every developer would just opt for the latter because it's more general and open-ended. And there's no pressure from users to choose the more restrictive but performant option because people basically have zero insight into what's killing their battery, much less which competitor is better in that regard. Given the gulf between Safari vs Chrome battery performance, I'm not all that convinced that the declarative api is pure downside like HN cynicism and Twitter outrage might suggest. I can agree that it would be nice to have competing implementations, but that's just the result of browsers being so complex that once your hobby horse feature is removed from one, you basically have nowhere to turn.
      • bangonkeyboard 7y ago
        > Given the gulf between Safari vs Chrome battery performance, I'm not all that convinced that the declarative api is pure downside like HN cynicism and Twitter outrage might suggest. Safari was already beating Chrome on battery life before its extension API was neutered. This is post hoc revisionist rationalization.
        • themacguffinman 7y ago
          So obviously the correct response from the Chrome team is to continue avoiding an approach that is known to save battery life /s
          • bangonkeyboard 7y ago
            To clarify: Safari was already beating Chrome on battery life before _Safari's_ extension API was neutered.
            • themacguffinman 7y ago
              What's your point? That Chrome now can't adopt Safari's extension API to save battery life because...? Improving Chrome's battery life by adopting a simpler extension API helps close the gap. That's a significant benefit whether or not Safari did it first or whether Chrome still has room for improvement.
              • shawnz 7y ago
                The grandparent was implying that Safari's better battery life justifies their decision to use the declarative API. But that was already the case before they adopted the declarative API, so it's not obvious that the declarative API has anything to do with that success. Maybe it's just a minor improvement, or maybe it isn't an improvement at all.
                • themacguffinman 7y ago
  • tyingq 7y ago
    Static blacklists versus live heuristics is a pretty obvious compromise, and prone to lose in the long term arms race. That's exactly why Chrome proposed manifest V3...which is basically implementing Safari rules.