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

EasyList is in trouble and so are many ad blockers

adguard.com

Post reply on HN
Print view View original

211–220 of 439 posts

Re: EasyList is in trouble and so are many ad blockers

#211

Post by ignoramous »

spatley wrote: post #197
tyingq wrote: post #33

Earlier quoted context omitted.

It's from this tos page: https://www.cloudflare.com/terms/ 2.8 Limitation on Serving Non-HTML Content ...Use of the Services for serving video or a disproportionate percentage of pictures, audio files, or other non-HTML content is prohibited, unless purchased separately... A huge text/plain artifact, requested often, would seem to fall into that category of "disproportionate percentage" compared to text/html served.

My best guess is that CloudFlare wrote this to prevent folks from serving big binary files like photo, music, or video and this txt file case was an unintended condition that happens to work to CloudFlare's advantage. text/plain though is decidedly not text/html and I would expect CloudFlare to potentially do some on-the- fly optimizations that are aware of the structure of an html file that save terabytes a day at t…

> My best guess is...

Some think its very Oracle of Cloudflare to do so. I do not blame them.

Re: EasyList is in trouble and so are many ad blockers

#212

Post by democra »

iforgotpassword wrote: post #158
metalliqaz wrote: post #100

Earlier quoted context omitted.

that would break everyone in India not using one of those broken browsers

They are already serving access denied replies, so I assume they can identify the browsers via user agent or similar? If so, returning a bogus file that blocks everything and adding a comment in that list asking the developers to use caching or mirroring the file should be fine. I wonder if those browsers honor the list when fetching the update though. Would be awesome if you could just add easylist and lock out furt…

Browser developers can choose to fake user-agents. Brave uses a generic chrome user agent so it cannot be differentiated from regular Chrome.

Re: EasyList is in trouble and so are many ad blockers

#213

Post by cr3ative »

noasaservice wrote: post #193

Really? "text files" arent web content? What the fuck does cloudflare think CSS and HTML files are?

To be fair to them, this is configuration data, not a piece of a website you would read in a browser. I don’t agree with the policy but it is reasonably clearly worded.

Re: EasyList is in trouble and so are many ad blockers

#214

Post by bergenty »

JimWestergren wrote: post #79

A great opportunity right now for CloudFlare to win some goodwill and PR by helping out EasyList for free right now. But what about simply enable a firewall and show captcha or similar if the origin IP is from India and requesting that URL until the situation is under control? I did that with the free plan recently in CloudFlare in a similar situation and it worked perfectly (of course on a much smaller scale).

A captcha for all 600 million internet users seems like overkill. Maybe a smaller subnet range.

Re: EasyList is in trouble and so are many ad blockers

#215

Post by chrismeller »

girvo wrote: post #210
chrismeller wrote: post #203

Earlier quoted context omitted.

Except it wouldn’t make them resilient since, as I pointed out, neither of the things they did would be of any help at all to Easylist in this situation. It’s great that they’re happy with their choices, but the choices would, in this same situation, likely saddle them with a crippled infrastructure and/or some insane bandwidth bills for suddenly pushing 100 extra TB/m.

It was never suggested that what the original commenter was doing would help EasyList.

I didn’t say the OP did, though it was implied. I was responding to a comment which did… context, my friend.

Edit: so if OP wasn’t implying that their approach was better, what was the point of posting it? Wow, obtuse much?

Re: EasyList is in trouble and so are many ad blockers

#216

Post by ignoramous »

therealmarv wrote: post #151

Bittorrent, switch in long-term to that. Not saying every end-user should be a seeder but there is big bittorrent community out there and everyone could help a little bit. Other options: - A kind of mirror network (it only needs to keep sure that integrity can be checked, maybe with a public key) - And while doing that why not also support compression (why not? only devs need to read it and they can run easily a deco…

> Bittorrent, switch in long-term to that.

S3 buckets in IAD with I'd imagine, some tech IPFS/Filecoin/Sia might come in handy, too, but unsure of how healthy most of these web3 projects are right now.

There's also fosstorrents.com that help seed projects.

Re: EasyList is in trouble and so are many ad blockers

#217

Post by r3trohack3r »

anigbrowl wrote: post #168
JimWestergren wrote: post #79

A great opportunity right now for CloudFlare to win some goodwill and PR by helping out EasyList for free right now. But what about simply enable a firewall and show captcha or similar if the origin IP is from India and requesting that URL until the situation is under control? I did that with the free plan recently in CloudFlare in a similar situation and it worked perfectly (of course on a much smaller scale).

I can't understand their argument that a text file 'isn't a web content'; seems like a bullshit excuse.

This doesn’t sound like bullshit to me. Serving a static text file that is primarily used by applications is not in line with their terms of service.

Cloudflare provides a significant service to the free and open web by subsidizing the hosting costs of static content for websites. They give that away for free under what appears to be reasonable terms.

Re: EasyList is in trouble and so are many ad blockers

#218

Post by ff7c11 »

Easylist should serve the Indian browser (based on user-agent) with a giant file (expensive), a corrupt file, or some response which causes the app the crash. If the browser crashes on every startup due to a malicious response from the Easylist server, users will likely delete it.

Re: EasyList is in trouble and so are many ad blockers

#219

Post by lolinder »

chrismeller wrote: post #203
lolinder wrote: post #188

Earlier quoted context omitted.

Their point isn't that EasyList could have done anything differently, their point is that they are glad that they didn't decide to rely on others' infrastructure for their own ad blocker, because that makes them resilient against the fallout from this and similar.

Except it wouldn’t make them resilient since, as I pointed out, neither of the things they did would be of any help at all to Easylist in this situation. It’s great that they’re happy with their choices, but the choices would, in this same situation, likely saddle them with a crippled infrastructure and/or some insane bandwidth bills for suddenly pushing 100 extra TB/m.

EasyList got here because they want all (respectful) apps to be able to use their list. They invited traffic, the problem is only occurring because this unknown browser violates the implicit "as long as you're considerate" rule.

OP, in contrast, wrote their own ad blocker targeting their own servers. They're in control of their ad blocker code and can write it to be respectful of their servers. They're not hosting the lists with the intent of allowing other people to use it, and they're unlikely to attract lazy app developers because the endpoints are (presumably) not listed publicly on the internet to anyone who wants an easy ad blocker list.

Re: EasyList is in trouble and so are many ad blockers

#220

Post by layer8 »

tyingq wrote: post #33
tomschwiha wrote: post #15

I'm confused about the ToS comment by Cloudflare. The txt is on a website so it is a web content? So robots.txt is not supported by Cloudflare to cache/proxy it? That would be a weird regulation. And I bet everyone violates the Cloudflare ToS then.

It's from this tos page: https://www.cloudflare.com/terms/ 2.8 Limitation on Serving Non-HTML Content ...Use of the Services for serving video or a disproportionate percentage of pictures, audio files, or other non-HTML content is prohibited, unless purchased separately... A huge text/plain artifact, requested often, would seem to fall into that category of "disproportionate percentage" compared to text/html served.

The solution seems simple, just wrap it in a trivial HTML envelope. Enclose it in 
 tags if needed.
Post reply on HN