Hacker News Reader

Comment by webmobdev | Hacker News Reader

I don't know if it is cartelisation (both Apple and Google have an ad division and it is in their interest to work together on some aspects of this business) or Google bribed Apple (through its ios search engine deal), but Safari webkit also has limitations in ad blocking through the content blocking API which Apple created for Safari. (See Explanation of the state of uBlock Origin (and other blockers) for Safari #158 - https://github.com/el1t/uBlock-Safari/issues/158?ysclid=l7g3... ).

View on HN

Saying they both “have an ad division” is a remarkably unbalanced comparison.

Google ads revenue 2021: 209 billion out of 256 billion, 80%

Apple ads revenue 2021: $3.7 billion of 365 billion, 1%

We further need to understand the difference between operating an ad exchange:

https://www.eff.org/deeplinks/2020/03/google-says-it-doesnt-...

And allowing first party and purchased ads for products within a marketplace the user is already visiting:

https://searchads.apple.com/help/get-started/0001-compare-ap...

They can only be validly compared once this is true of both ad services:

> [Ad service] doesn’t buy or share users’ personal information with other companies. We don’t track people by linking user or device data collected from [first party] apps with user or device data collected from third parties for advertising targeting or measurement. And we don’t share user or device data with data brokers.

https://searchads.apple.com/privacy

Not saying they’re “all good”, just “least worst”.

Scroll down in the second link to see what Apple do gather and use for targeting. Unhappily, the user consent more about personalization than about aggregation in the first place. Note also the missing word “sell” in “doesn’t buy or share”, perhaps they think sell is implied by share, but also perhaps not.

Ad Guard works great in Safari, I have yet to see ads it doesn't block

We did our best with Safari, but believe me, it actually works worse than AdGuard in Chrome and Firefox. Safari with all its limitations is no better than Chrome with MV3.

I'm sure, it's also slightly worse then uBlock Origin for Chrome. But it works well enough and the fact that Safari isn't run by Google by far outweighs any other drawbacks it might have.

Is it possible that Apple’s implementation uses less power and hence conserve battery life? Also, is it possible Apple’s implementation requires less trust in extension and is more private because no browsing information can exit?

It is also possible for the above, and collusion to all simultaneously happen, and or Apple advancing their own ad business.

It won't be lower battery if ads slip through (they do).

It won't be more private if ads slip through, or if the whole web experience is degraded and users prefer native apps.

Think about it from a mathematical perspective: How much CPU time is actually spent evaluating ad blocker rules? It's going to be proportional to the number of HTTP requests you issue. On a good website the number of requests is in the dozens or a hundred tops per page load, on a bad website maybe it's in the low thousands. But that's it. Let's say you have 300000 rules (I think the actual number tends to be much lower than this), worst case even if you brute forced that, you're evaluating 300000 regexes maybe a thousand times. That'll take some time, but not that much time, because modern CPUs are really fast. It's simply implausible that an ad blocker could have a significant negative impact on battery life unless you wrote it in some sort of forth interpreter that was checking strings one byte at a time - compared to the rule evaluations happening once per request, you're rasterizing frames ~60 times a second and handling input events and timers and all of that stuff constantly.

If you optimize the rules engine - which you can definitely do - you can skip evaluating most of those regexes, you can evaluate them in parallel, etc. You could start preparing the request and only gate the actual tcp packets on approval from the ad blocker. You could cache the approve/deny state for each URL so that the ad blocker overhead is only paid on first visit to a site. There are lots of ways to make this stuff super fast without breaking it, but Google and Apple don't want to do the work.

People like the uBlock Origin author have already demonstrated in the past that their ad blockers are fast despite the severe limitations of current browser extension APIs. If browser vendors actually supported extension developers ad blockers could probably become faster. Instead they're attacking them and forcing people to move over to intentionally sabotaged APIs with limited feature sets and arguing that now things will be "faster" even though you're going to be wasting resources downloading a bunch of ads.

Sure. The content blocking API is more secure as it doesn't allow any code by the extension to run and modify a web page. And so logically sounds like it should use less cpu / power. It is also true that it is a much, much inferior ad-blocking solution. If a feature is popular, it doesn't make sense to remove it. Instead, you can choose to make it opt-in. That both Apple and Chrome haven't opted for that speaks for itself - it is clear that they are prioritising crippling adblockers than letting users control what code run on their browser.

> Is it possible that Apple’s implementation uses less power and hence conserve battery life?

On WebKit, you can still use WebRequest to intercept and log all traffic, you just can't block it. I don't think that intercepting/recording all traffic and selectively blocking it would have a meaningful difference compared to just intercepting it all and letting it through.

Reply on news.ycombinator.com