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

411–420 of 439 posts

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

#411

Post by yellowapple »

kenmacd wrote: post #401
celestialcheese wrote: post #290

Earlier quoted context omitted.

Ok, so then why not make a structured HTML page that's served and parsed as the list.. that would be perfectly fine? Cloudflare's stance on this makes no sense

That would be fine because then CF could replace that HTML with their "Checking your browser before accessing" content. What's the app going to think of that though?

> That would be fine because then CF could replace that HTML with their "Checking your browser before accessing" content.

They could do that anyway by putting up the "Checking your browser before accessing" page and redirecting to whatever file was being accessed. There's precisely zero need to outright modify the HTML files being served to inject such checks.

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

#412

Post by yellowapple »

archi42 wrote: post #322
yellowapple wrote: post #318

Earlier quoted context omitted.

> It is about excessive resources/bandwidth usage. Then the policy would focus on that rather than micromanage the format of the data using those resources/bandwidth. Again: bytes are bytes. > why such a fuss Because a policy as nonsensical as "no non-HTML files allowed" artificially limits the usefulness of CloudFlare for precisely zero legitimate reason. I ask again: does wrapping a video in a blob of JavaScript fi…

The difference is in the amount of cache you need. In one case you save 10GB per 1MB of cache, in the other just 1GB per 1MB and the big file is going to evict many small files (even if the user only listens to the first 10s). It's no huge difference for a single user/site, but across all users this quickly means needing a multiple of the current cache; which doesn't come for free. Also, CF have a product to sell. Th…

> The difference is in the amount of cache you need.

Okay, now run the same thought experiment with 10,000 downloads of a 1MB MP3 v. 10,000 downloads of a 1MB HTML/CSS/JS site. What difference then?

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

#413

Post by kenmacd »

yellowapple wrote: post #411
kenmacd wrote: post #401

Earlier quoted context omitted.

That would be fine because then CF could replace that HTML with their "Checking your browser before accessing" content. What's the app going to think of that though?

> That would be fine because then CF could replace that HTML with their "Checking your browser before accessing" content. They could do that anyway by putting up the "Checking your browser before accessing" page and redirecting to whatever file was being accessed. There's precisely zero need to outright modify the HTML files being served to inject such checks.

No they couldn't. If you replace a .txt file with random html data bad things are going to happen.

Tell me, how does CF put a 'Checking your browser' page in my `wget https://easylist.to/easylist/easylist.txt`

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

#414

Post by kenmacd »

yellowapple wrote: post #410
kenmacd wrote: post #400

Earlier quoted context omitted.

there's a lot of similar comments to this one. In short, it's much harder to protect a text file against DDoS. The ToS say 'a disproportionate percentage ... non-html' likely because they need to be able to apply their browser checks to clients.

> there's a lot of similar comments to this one. and a lot of similar rebuttals to this one. > In short, it's much harder to protect a text file against DDoS. It's exactly the same difficulty. Bandwidth is bandwidth, bytes are bytes. The only suggestion I've seen where HTML/CSS/JS might be relevant is using JS for client-side probing, and if Cloudflare is indeed injecting arbitrary JS into HTML pages it serves then t…

>> there's a lot of similar comments to this one.

> and a lot of similar rebuttals to this one.

My point is that a lot of people don't seem to understand the 'why' of this issue and instead appeared to just jump to the conclusion that:

> It's exactly the same difficulty.

When that's not at all the case.

> using JS for client-side probing, and if Cloudflare is indeed injecting arbitrary JS into HTML pages it serves then that's utterly horrifying and is a problem in and of itself.

Well they are. From CF:

>> Cloudflare’s bot products include JavaScript detections via a lightweight, invisible code injection that honors Cloudflare’s strict privacy standards

But even before we consider that, if the request is for html then it's likely coming from a browser. If CF replaces that html with their own then the browser will likely run it allowing them to run all kinds of probes then run the redirect. The same is not true for a .txt file or an image.

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

#416

Post by denton-scratch »

lmz wrote: post #341
denton-scratch wrote: post #339

Earlier quoted context omitted.

Access Denied is an HTTP status code, not a page that you serve. 100Tb per month of status codes suggests something like 30 trillion requests per month. Is that possible?

Just because it's a status code doesn't mean it has no content. Response headers and some basic text?

Point taken, thanks.

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

#417

Post by vifon »

prvit wrote: post #377
GekkePrutser wrote: post #249

Earlier quoted context omitted.

But it is web content, really. A txt file renders fine in every browser. Many websites also push text through HTML as part of AJAXy stuff. If they actually enforced this for all sites, their service would no longer be usable.

Movies will render in browsers just fine too, doesn’t mean that cloudflare will allow you to cache them.

Their documentation seems to disagree. https://developers.cloudflare.com/cache/about/default-cache-...

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

#418

Post by yellowapple »

kenmacd wrote: post #414
yellowapple wrote: post #410

Earlier quoted context omitted.

> there's a lot of similar comments to this one. and a lot of similar rebuttals to this one. > In short, it's much harder to protect a text file against DDoS. It's exactly the same difficulty. Bandwidth is bandwidth, bytes are bytes. The only suggestion I've seen where HTML/CSS/JS might be relevant is using JS for client-side probing, and if Cloudflare is indeed injecting arbitrary JS into HTML pages it serves then t…

>> there's a lot of similar comments to this one. > and a lot of similar rebuttals to this one. My point is that a lot of people don't seem to understand the 'why' of this issue and instead appeared to just jump to the conclusion that: > It's exactly the same difficulty. When that's not at all the case. > using JS for client-side probing, and if Cloudflare is indeed injecting arbitrary JS into HTML pages it serves th…

> My point is that a lot of people don't seem to understand the 'why' of this issue

We understand the "why" of the actual issue - i.e. the bandwidth consumption - just fine. It's Cloudflare's decision to micromanage data formats consuming that bandwidth (instead of just, you know, evaluating the bandwidth itself and being done with it) and using that as their basis for a ToS violation that's entirely whackadoodle.

> Well they are.

Then that is indeed absolutely horrifying and a problem in and of itself. Privacy concerns (of which there are a multitude) aside, this seems like a really great way to break all sorts of things, and I'd trust the claims of "lightweight", "invisible", and "strict privacy" about as far as I can throw them.

> If CF replaces that html with their own then the browser will likely run it allowing them to run all kinds of probes then run the redirect. The same is not true for a .txt file or an image.

The same is absolutely true for a .txt file or an image. Consider two flows:

1. You click on a link, your browser loads a text file.

2. You click on a link, your browser loads an HTML+JS file, the embedded JS redirects your browser, your browser loads a text file.

Same end result, same client-side probing opportunities, and without needing to rely on swinging JS into the end document like Patrick Bateman swinging an axe into his coworker's face while ranting about "Hip To Be Square".

Or better yet: just don't do this and only care about the raw bandwidth consumed, instead of actively making the World Wide Web a worse place with "clever" tricks like anally probing my browser to see if it's browsery enough for some arbitrary standard of browserness (for the sake of a "protection" that's almost certainly trivial to break with one of the umpteen headless browser solutions anyway).

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

#419

Post by yellowapple »

kenmacd wrote: post #413
yellowapple wrote: post #411

Earlier quoted context omitted.

> That would be fine because then CF could replace that HTML with their "Checking your browser before accessing" content. They could do that anyway by putting up the "Checking your browser before accessing" page and redirecting to whatever file was being accessed. There's precisely zero need to outright modify the HTML files being served to inject such checks.

No they couldn't. If you replace a .txt file with random html data bad things are going to happen. Tell me, how does CF put a 'Checking your browser' page in my `wget https://easylist.to/easylist/easylist.txt `

> If you replace a .txt file with random html data bad things are going to happen.

Bad things are already happening. Random HTML data is no less useful than no data at all.

> Tell me, how does CF put a 'Checking your browser' page in my `wget https://easylist.to/easylist/easylist.txt`

By serving the HTML instead (with JS that does whatever checks and then redirects to the intended resource), and if the client can't cope with that, then tough shit; the absurdity of such arbitrary evaluation of whether or not clients are sufficiently browsery to be worthy of consuming bandwidth aside, ain't "only browsers directly navigating to this will be able to cope with this and gain access" exactly the point of using such JS-based client checks in the first place?

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

#420

Post by Joel_Mckay »

zaarn wrote: post #337
codalan wrote: post #135

Earlier quoted context omitted.

That would only work if they had an API; AFAICT, they're just hosting a file. At this point, they might be better off coordinating with the other major adblocker providers and just outright move the file elsewhere. Breaking other people's garbage code is better than breaking yourself trying to fix it. Especially on a budget of $0.00. If the defective code for the browsers are in public repos, it might also be more ef…

Moving the file elsewhere won't fix it. They are serving terabytes of traffic on Access Denied, it won't go away if that changes to "Not Found" instead, the developers seem already entirely ready to ignore their adblocker just not working.

The query limit from the lets encrypt SSL service operates in a similar manner. If you hit it more than a few times a week for the same domain/token/key, than you are banned for 5 days.

In general, it is easier to setup filters after differentiating legitimate from nuisance traffic. For example, fail2ban looks at the log of errors from invalid hits, and bans the IP or entire ISP block ranges for 5 days. This ban than get propagated to the rest of the web via spamhaus.org listing.

i.e. the users start to see the worlds internet become unreachable, as admins start to block traffic at the NOC's routers, and so on... India knows about Karma.

I am more surprised the app store for the apk isn't getting sued for theft of service.

Post reply on HN