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

31–40 of 49 posts

Re: Introduction to WebKit Content Blockers

#31

Post by tomjen3 »

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…

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.

Re: Introduction to WebKit Content Blockers

#32

Post by natch »

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"

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.

Re: Introduction to WebKit Content Blockers

#33

Post by carlesfe »

natch wrote: post #32
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"

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.

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

Re: Introduction to WebKit Content Blockers

#34

Post by _up »

frik wrote: post #23
IBM wrote: post #6

Earlier quoted context omitted.

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…

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

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.

Re: Introduction to WebKit Content Blockers

#35

Post by _up »

millstone wrote: post #21
derefr wrote: post #8

Earlier quoted context omitted.

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?

It's possible to have ad networks, but for publishers to host the software themselves. This would eliminate the tracking and cookies that follow you from site to site.

You expect them to discard click fraud and also pay out on self reported impressions?

Re: Introduction to WebKit Content Blockers

#36

Post by TheDong »

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…

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.

Re: Introduction to WebKit Content Blockers

#37

Post by frik »

_up wrote: post #34
frik wrote: post #23

Earlier quoted context omitted.

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

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.

Re: Introduction to WebKit Content Blockers

#38

Post by xg15 »

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.

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

Re: Introduction to WebKit Content Blockers

#39

Post by xg15 »

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…

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.

Re: Introduction to WebKit Content Blockers

#40

Post by _up »

frik wrote: post #37
_up wrote: post #34

Earlier quoted context omitted.

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