When a third party serves an ad to a user, the third party gets information about that person (their IP address, etc.) When Apple serves an ad to one of their users on behalf of an advertiser, on the other hand, the third party doesn't get any information at all.
Sure, Apple now knows I saw an ad... but Apple knows a lot of stuff about me; I'm already assuming they're trusted with my personal information the moment I set up iCloud Keychain or Find My Mac. Reducing the number of companies that know things about me down to the bare minimum (i.e. the same number that I actually do business with) is not a bad deal.
...of course, if iOS shipped with a "hosts file"-like configuration point, such that one could block iAds, that'd be a much more interesting world. (And not, strictly speaking, an impossible one; "featureful" VPN-proxy services are becoming more common—even Google is giving one away as part of Project Fi, to avoid "dirty" wifi—and iOS supports system VPNs, so you could set up your ad filtering at the head-end. I have no idea what Apple would do if this became common, though. Maybe just give app developers an API to ask whether "the phone can reach the internet but the ads aren't loading", and switch to a separate "hey stop that" view controller.)
The way forward is native ads (no, native ads aren't advertorials) like podcast ads, radio ads, or sponsored posts on individual blogs like Daring Fireball.
Disclaimer: There may be reasons this wouldn't work, technical or approval-wise, that I'm not aware of.
That aside, iAds are way nicer than ads on other platforms. The platform protects user privacy and doesn't resort to trickery and deception, and ads and advertisers are vetted. This stuff matters.
And yes, the adblock devs were given money by google shortly before making that choice.
(No offense, but you're an anonymous writer on the internet.) Do you know of a URL or something I can use to verify that statement?
One concern I could see for browser based adblockers is the Server Push features of HTTP2, in which upon a client requesting a page, the server can deduce which subsequent requests a client will make (for example, if a client requests index.html, the server can assume that a request for styles.css and scripts.js will be coming shortly after) and 'push' them to client over the existing tcp stream without the client explicitly requesting them.
This could deprive an ablocker of the chance to deny content if I'm understanding it correctly. Then again, its very possible that I'm misunderstaning it. I should probably read the specification more thoroughly to answer some of my own questions.
Server operators are inclined to obey those hints, because otherwise they'd be wasting their own bandwith as well.
They gave an example of this with the "image" resource type: Whenever the engine loads an image (e.g., triggered by an <img src=...> declaration), those filters are triggered. It doesn't matter at all if the fetched resource actually has an image/... MIME type or not.
I could imagine the same thing working for HTTP2. The engine still knows which domain the request was initially for, even if all requests go to the same IP in the same connection in the end. Unless the filter says anything specific about the transport method, there is nothing stopping the engine from applying the existing filters to both HTTP and HTTP2. So domain-based blocking could actually become easier.
