Introduction to WebKit Content Blockers
webkit.org
webkit.org
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?
I was using Adblock Plus, but this made me think a lot about this. Now, I'm using Privoxy + NoScript with custom filters.
It's a way a safari extension on OS X or iOS can prevent load or hide literally any object requested by the browser/web view
It won't affect Google ads if they're in loaded in native apps.
Personally I view this as being inevitable given their recent high profile privacy push. I'm not saying they weren't pro-privacy before, but they're enhancing and promoting that factor more now than ever.
But we all knew what was meant, so why bother?
As for why bother discussing this: I don't think I'm alone in believing in a better B2C business model for the internet than "we'll get lots of users to spend lots of time with our thing, then make them look at ads". It's been said many times here before, but I'll repeat that it seems like a waste to have so many smart and talented people spending so much time on making people look at ads.
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.
Or would you say that advertising is only for big shots, and small-time publishers should just rely on up-front payment?
every month a new layer show up, with the sole promise of allowing the ad vendor to pay less for the publisher. the fad du jour is viewable.
Disclaimer: There may be reasons this wouldn't work, technical or approval-wise, that I'm not aware of.
Each of the network extension points requires special permission from Apple.
https://developer.apple.com/library/prerelease/ios/releaseno...
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.
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.