Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to WebKit Content Blockers

webkit.org

Post reply on HN
Print view View original

11–20 of 49 posts

Re: Introduction to WebKit Content Blockers

#11

Post by kibwen »

caryhartline wrote: post #10
kibwen wrote: post #9

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 shar…

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.

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.

Re: Introduction to WebKit Content Blockers

#12

Post by okbake »

Animats wrote: post #7

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.

Re: Introduction to WebKit Content Blockers

#13

Post by comex »

derefr wrote: post #5
carlesfe wrote: post #4

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 beha…

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.

Re: Introduction to WebKit Content Blockers

#14

Post by Nursie »

okbake wrote: post #12
Animats wrote: post #7

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…

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

Re: Introduction to WebKit Content Blockers

#15

Post by rdsnsca »

Nursie wrote: post #14
okbake wrote: post #12

Earlier quoted context omitted.

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…

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

This sucks because the user is still downloading the ads, and most likely paying for the bandwidth todo so.

Re: Introduction to WebKit Content Blockers

#16

Post by stephenr »

kibwen wrote: post #11
caryhartline wrote: post #10

Earlier quoted context omitted.

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.

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.

Re: Introduction to WebKit Content Blockers

#17

Post by conradev »

comex wrote: post #13
derefr wrote: post #5

Earlier quoted context omitted.

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 beha…

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.

    Each of the network extension points requires special permission from Apple.
Whatever that means.

https://developer.apple.com/library/prerelease/ios/releaseno...

Re: Introduction to WebKit Content Blockers

#18

Post by asdf99 »

IBM wrote: post #6
derefr wrote: post #5

Earlier quoted context omitted.

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 beha…

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 po…

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.

Re: Introduction to WebKit Content Blockers

#19

Post by jimmaswell »

kibwen wrote: post #11
caryhartline wrote: post #10

Earlier quoted context omitted.

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.

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.

Are free websites going to last much longer if we keep attacking ads?

Re: Introduction to WebKit Content Blockers

#20

Post by stephenr »

jimmaswell wrote: post #19
kibwen wrote: post #11

Earlier quoted context omitted.

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.

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.
Post reply on HN