Introduction to WebKit Content Blockers(webkit.org)
webkit.org
Introduction to WebKit Content Blockers
https://www.webkit.org/blog/3476/content-blockers-first-look/
48 comments
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.
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.
And yes, the adblock devs were given money by google shortly before making that choice.
>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?
(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?
http://www.theverge.com/2015/2/2/7963577/google-ads-get-thro...
http://www.theverge.com/2013/7/5/4496852/adblock-plus-eye-go...
I was using Adblock Plus, but this made me think a lot about this. Now, I'm using Privoxy + NoScript with custom filters.
I was using Adblock Plus, but this made me think a lot about this. Now, I'm using Privoxy + NoScript with custom filters.
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.
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.
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).
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.
The content blockers stuff is not a "block Google" checkbox.
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.
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.
It won't affect Google ads if they're loaded in native apps, but what's keeping Apple from ousting Google ads from their platform entirely? iOS doesn't have a monopoly on mobile, so Google would have no recourse if Apple decided that all new apps must use iAd rather than AdMob. App developers wouldn't care, advertisers wouldn't care, and users definitely wouldn't care.
Some developers may care. I'm not saying they should or shouldn't do that, I'm just saying that while this can be used to prevent GA tracking via web ads it isn't an out-and-out attack on googles ad network
Are free websites going to last much longer if we keep attacking ads?
I'd take you more seriously if you referred to them as "ad supported websites" rather than "free" websites.
I think "free" is the most accurate succinct terminology to be used here, when used with it's most common definition. An ad-supported site/service can still cost money to use (e.g. Hulu Plus), so just referring to a site as ad-supported to distinguish the business model is no clearer than calling it free. The way to resolve this is to be more explicit, such as saying it's "monetarily free".
But we all knew what was meant, so why bother?
But we all knew what was meant, so why bother?
brendal(1)
Yeah; Google seems to make quite a bit of coin off their "free" search engine and with their "free" maps website.
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.
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.
Ads aren't being attacked, they're being ignored. This is a reflection of that.
Ads seem to be paid attention to enough for webmasters to bother using them. Vendors blocking them by default could be problematic
Apple: "We will allow ad blockers for Safari in iOS9. By the way, here's our new News app, which serves unblockable iAds"
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.)
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.)
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.
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.
The problem is with publishers too small to individually attract the attention of advertisers... which is most of the ones that use advertising to begin with. Any way to solve that problem reintroduces an ad network in some form or another.
Or would you say that advertising is only for big shots, and small-time publishers should just rely on up-front payment?
Or would you say that advertising is only for big shots, and small-time publishers should just rely on up-front payment?
Third party ad networks should pivot and provide a single binary executable (e.g. Go/Rust/C++ application) that a website owner adds to his website. And that binary app delivers the ads from the ad network and the website can choose how he integrates it to the website. The ad network will receive a list of URLs from the binary where it checks (with different IPs) if the ad is displayed to the user and if the image file hash is the same. Such an ad would be good for the users privacy (no more third party JS), good for the website owner (more ads delivered, more money), and good for the ad network (ads delivered also to users with adblockers) - a win-win-win situation.
Even with all that data, ad networks have massive problems with click fraud. Now you want them to discard all that and even pay the website owners according to their self reported visitor numbers? Good Luck with that.
How is a binary blob self reported? It can be signed and is totally in control of the ad network, just runs on the actual website. And click fraud wouldn't even exist if the ad network would pay per page impression/view. And ad networks will have to adapt in some way anyway for iOS9.
The Question is how does the website owner prove real organic impressions to the Advertiser? If people can buy ad clicks, they also can buy fraudulent ad impressions. A manipulated reverse proxy could also simulate fake impressions.
What could work is if cloudflare becomes an ad network and injects advertising into your site.
even big publishers like Yahoo can't do that because there's an average of 20 companies between then and the brands advertising. publisher would love to be alone in the field and pocket the .20 per click. but ad agencies go a long way to doubt the publisher reports etc and try to pay less.
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.
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.
But the other way could work. A service like Cloudflare could become an ad network and inject ads in transit.
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.
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...
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.
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.
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 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.
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.
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.
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.
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.
Server operators are inclined to obey those hints, because otherwise they'd be wasting their own bandwith as well.
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.
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.
Seem to be the technical details about the discussion two days ago: https://news.ycombinator.com/item?id=9695552
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.
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.)