Introduction to WebKit Content Blockers

https://www.webkit.org/blog/3476/content-blockers-first-look/

by glasshead969 • 11 years ago

110 44 11 years ago

frik3• 11 years ago

Seem to be the technical details about the discussion two days ago: https://news.ycombinator.com/item?id=9695552

carlesfe2• 11 years ago

Apple: "We will allow ad blockers for Safari in iOS9. By the way, here's our new News app, which serves unblockable iAds"

derefr2• 11 years ago

It does make sense. Apple aren't helping people block ads because they don't like ads; Apple are helping people block ads to "enhance privacy" (and also for "if everyone's gonna do it anyway, it may as well be fast" reasons, but never mind those.)

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.)

IBM• 11 years ago

I think it will be a good change if publishers were forced to sell/deliver their own ads. The problem has always been third-party ad networks that track you across the web and sometimes delivers malware. Publishers have never had to take ownership for the ads they serve and the user experience has suffered.

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.

comex2• 11 years ago

In fact, yet another of iOS 9's features is a custom VPN protocol API, so you could probably do this purely client side as a "VPN" that just connects directly but blocks certain hosts.

Disclaimer: There may be reasons this wouldn't work, technical or approval-wise, that I'm not aware of.

seanp2k22• 11 years ago

And that's why I run my home wifi through Privoxy (runs on my router, a Ubiquiti ER-Lite which is just Debian MIPS + Vyatta) and jailbreak to install Adblocker Networks.

natch• 11 years ago

What's your source for the assertion that the News app will serve ads?

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.

carlesfe2• 11 years ago

https://developer.apple.com/news-publisher/

serve_yay• 11 years ago

This just brings iOS to parity with OS X though, I keep seeing people talking about this as if it's exclusive to iOS to make some strained point about Apple. Both OS X and iOS now use this same implementation, where the blocking extension is little more than a JSON blob of rules describing what should be blocked from loading or hidden on the page.

Animats• 11 years ago

This seems like a good idea. The big question is whether the structure can recognize enough ads, and whether it will continue to do so. For example, if a site is using HTTP2 and all the ads come in over the same TCP connection, domain-based blocking may have a problem. If (when) CDNs start doing that, ad recognition becomes tougher.

okbake• 11 years ago

Will two resources share the same tcp stream even if they are from different origins? I thought that each domain was given its own tcp stream in HTTP2. Is that even feasible to have a single tcp connection shared by multiple endpoints like that? I've read through some of the specs but not thoroughly enough to know for sure.

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.

Nursie• 11 years ago

The content could still be loaded, but not processed or rendered, perhaps?

xg152• 11 years ago

I'm no HTTP2 expert, but I think clients can choose to opt-out of push or at least tell the server "I already got this document, please don't push it again."

Server operators are inclined to obey those hints, because otherwise they'd be wasting their own bandwith as well.

xg152• 11 years ago

I think this is actually an argument in favor of the declarative approach they are trying: The filter are all defined in terms of what the engine intends to do, rather of what actually happens low-level.

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.

kibwen3• 11 years ago

Firefox is also dabbling with built-in tracking protection (https://news.ycombinator.com/item?id=9594158). I'll be curious to see how Google faces this trend with Chrome going forward. Apple may be able to get away with enabling users to block web ads while serving them native ads (in the guise of privacy), but if Google tried to do the same (i.e. with Google-served ads being somehow "blessed" by virtue of not sharing your personal details with advertisers) then they'd be painting a target on their forehead for antitrust lawsuits.

caryhartline• 11 years ago

Is it a guise of privacy when iAds is actually more private? Google has already done this with blocking Flash ads which blocks their own ad network as well.

kibwen3• 11 years ago

It is indeed more private, and I welcome the move. Users need choice. But let's not overlook the obvious bid here to entice content providers into Apple's walled garden while also taking a direct swipe at the business model of their biggest competitor.

cpeterso• 11 years ago

Google/DoubleClick has been using Swiffy to convert their customers' Flash ads to non-Flash HTML/SVG for mobile websites. It would be easy to use Swiffy ads on desktop, too. If other ad networks can't convert Flash ads, then ad agencies that want to continue use their Flash toolchain will move to Google/Doubleclick's ad network (to get Swiffy) thanks to a change in Google's own browser (which also happens to be the world's most popular browser).

tomjen3• 11 years ago

Personally I am more shocked that MS didn't include adblocking by default in their browsers. It would have been right up their alley and it would have given their users a better experience.

TheDong• 11 years ago

They can do the same justification AdblockPlus does: Don't disable unintrusive ads, only intrusive ones, and thus allow google text ads.

And yes, the adblock devs were given money by google shortly before making that choice.

hollerith• 11 years ago

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?

chrischen• 11 years ago

Is this going to lead to client-side content blocking in countries like China, where they could mandate that all iPhones now install the content blockers? The benefit is obviously that the content blocking gets distributed.

comex2• 11 years ago

No. Their country-wide firewall is sufficient, and there would be no way to enforce a rule that everyone install some iPhone app. (And most Chinese users aren't using iPhones.)

Introduction to WebKit Content Blockers

Related Stories