> There’s an open source Android browser (now seemingly abandoned) that implements ad-blocking functionality
> The problem is that this browser has a very serious flaw. It tries to download filters updates on every startup, and on Android it may happen lots of times per day. It can even happen when the browser is running in the background
EasyList should be offered as a version-controlled copy you grab once, that then gets bundled with an app, rather than offering a download to be called from an app: https://easylist.to/easylist/easylist.txt (Currently down as of writing).
The only caveat is such a list needs to be updated, so then a version system should be implemented for EasyList and you periodically bundle the new version via app updates. It would save a lot of bandwidth doing this.
Bad app will just brutally fetch it every time with not even a cache on its side.
As a quick fix, there are many options for limiting per IP per timespan, e.g. fail2ban, you could configure it to punish bad apps without crippling functionality for others. Well, maybe crippling a little bit in some very special use cases, still better than it simply not working.
PiHole and PFBlockerng are two big ones that use these resources too and setting those up it struck me as it did you that simply polling these resources on a set schedule was a waste.
Podcasting 2.0 has been talking about podping as a solution because podcasting basically has the same problem with periodic polling of the RSS feed. Basically you subscribe and then receive notice there's been an update, THEN you go get it.
They're offering a text file. Presumably with an If-modified-since header, although it's hard to check now.
There is no approach you can describe that doesn't run afoul of the described badly-behaved browser app which willfully retrieves the entire file afresh at every init. If it can be downloaded, it will be downloaded directly by the badly-behaved mobile apps.
If I recall correctly there was some image on wikipedia that was getting billions of downloads a day or something, all from India, because some smart phone had made it a default "hello" image and hot linked it.
Unfortunately, I can't find a reference to it anymore.
Not that you’d do it, but the temptation there is always to repoint your real application to a different URL and change the original image to something subtly NSFW.
I was debugging a similar issue where a small marketplace run by a friend was being scrapped and the listings were being used to make a competing marketplace look more active than it actually was.
The thing is, they didn't host the scrapped images themselves, they just hot-linked everything.
So through a little nginx config, we turned their entire homepage to an ad for my friend's platform :)
In case anyone is inspired to do related things, I made a mistake once (troubling and embarrassing), which I'll mention in case it helps someone else avoid my mistake...
In earlier days of the Web, someone appeared to have hotlinked a photo from a page of mine, as their avatar/signature in some Web forum for another country, and it was eating up way too much bandwidth for my little site.
I handled this in an annoyed and ill-informed way, but which I thought was good-natured, and years later realized it was potentially harmful. I'd changed the URL to serve a new version of the image, to which I'd overlaid text with progressive political slogans relevant to their country. (Thinking I was making a statement to the person about the political issues, and that it would be just a small joke for them, before they changed their avatar/signature to stop hotlinking my bandwidth.) Years later, once I had a bit more understanding of the world, I realized that was very ignorant and cavalier of me, and might've caused serious government or social trouble for the person.
Sensitized by my earlier mistake, I could imagine ways that a subtly NSFW image could cause problems, especially in the workplace, and in some other cultures/countries.
Yeah, you could get someone gulag'd pretty easily if you wanted to and they were in the right location.
Subtle things like flipping the image upside down or reversing the colors or other "not quite harmful but quite annoying" responses are probably better, or just serve a 1x1 pixel image of nothing.
My mind must be in a dark place because once you mentioned politics I thought of how just sitting at home I could easily come up with some kind of image that could literally imprison or kill some one off from thousands of miles away, without even getting up from the couch. I think I spent most of my internet youth lusting for such power.
Widespread in the sense that social media users have done it for long time, and Chinese users are sometimes counteracting by rewriting those into pro-regime phrases, but not what considered safe for commercial entities to exploit. That one is not a professionally produced film.
Many years ago, back when eBay didn’t even have their own image hosting, I found someone hotlinking to the images from one of my completed auctions for their sale (of an identical product). I ended up swapping the images for ones from urinalpoop.com (seems to no longer exist, but at the time it featured pictures of exactly what you’d imagine by the URL). I ended up getting an angry message from the seller accusing me of “hacking” their auctions.
I still have a 5k pixel square blank white gif on my site for times like that (~4kB) that I sub in for anything that gets requested too often, or from particular places.
I was getting hotlinked from controversial sites a lot at one stage, and the common forum software they used didn't force image sizes. So a 5k pixel wide image pushed most of the content off the screen thanks to a centred element :)
I remember from a long time ago something about an image that was corrupted, and did some self referral internally so you could crash applications through out of memory issues even though the image was only a couple of kilobytes. I might have to find it again to serve to hotlinkers!
A startup I used to work for had a horror story from before I started, where a small .png file had been accidentally hotlinked from a third party server. The png showed up on a significant % of users' custom homepages (think myspace, etc). At some point the person operating the server decided that instead of emailing someone or blocking the requests, they'd serve goatse up to a bunch of teenagers and housemoms. Mildly hilarious depending on your perspective, I guess?
This once happened in a particular South Korean news website where it shamelessly stole and hot-linked to a JavaScript file in a third-party website. The domain owner responded it by replacing the file, and the website in question had a warning message and tilted [1] for a while.
That's a different list. It only contains the hosts/domains on easylist, because that's all pi-hole (and all host based blockers) can block. It's also hosted by someone else (and they too use Cloudflare, see firebog.net).
The normal easylist is way bigger and has lots of rules for ad blockers like uBlock Origin.
I am not speaking on behalf of the company, but if someone involved with EasyList can contact me (avani@cloudflare.com), I'll see if there is a way to help out.
> EasyList is hosted on Github and proxied with CloudFlare.
What is the reason for proxying through Cloudflare? Are there any bandwidth limits or performance issues when directly serving those files from GitHub?
> GitHub Pages sites have a soft bandwidth limit of 100 GB per month.
> In order to provide consistent quality of service for all GitHub Pages sites, rate limits may apply. These rate limits are not intended to interfere with legitimate uses of GitHub Pages. If your request triggers rate limiting, you will receive an appropriate response with an HTTP status code of 429, along with an informative HTML body.
> If your site exceeds these usage quotas, we may not be able to serve your site, or you may receive a polite email from GitHub Support suggesting strategies for reducing your site's impact on our servers, including putting a third-party content distribution network (CDN) in front of your site, making use of other GitHub features such as releases, or moving to a different hosting service that might better fit your needs.
GitHub has a soft limit of like 100 GB/month on transfers for Pages. According to the Adguard blog post traffic was already several TBs a day before the issue arose.
I'm curious, if an arbitrary GitHub repo suddenly started attracting hundreds of terabytes of egress, violating GitHub's ToS, would GitHub manage traffic in coordination with the repo's owner, or would they disable the repo and suspend the account?
I suspect the latter. I don't know how to make a repo public but limit web traffic to it. Do you?
I could see disabling viewing raw links. But if the repo becomes popular to fork what would GH do? The friction of using git instead of HTTP will prevent 99.9% of hotlinking. So it probably couldn’t become too popular.
Author here. Actually, it's getting better, I've just looked up the stats and for the last 30 days we only served 70TB of access denied pages, this is about 33-34B requests.
The thing with Access Denied is that these deprived clients retry with some vengeance. So, you're instead draining more resources than you'd like. I run a content-blocking DoH resolver, and this happened to us when we blocked IPs in a particular range and the result was... well... a lot of bandwidth for nothing.
This is what I was wondering. I'm taking a wild guess that maybe they don't have that level of firewall access and it was being done through filtering by the webserver to provide an access denied.
But why bother with deny? Just send a blank text file (or one with as minimal data as needed to satisfy the rogue adblock) to the "blocked IPs" to mitigate the traffic for now. If firewall access exists, just drop the offending incoming traffic entirely.
> Just send a blank text file (or one with as minimal data as needed to satisfy the rogue adblock) to the "blocked IPs" to mitigate the traffic for now.
The sent http body was blank, but I beleive we were still sending http head...
> If firewall access exists, just drop the offending incoming traffic entirely.
True, but the service we were using at the time didn't have a L3 firewall, and so we ended up moving out, after paying the bills in full, of course.
That reminds me of the absolutely insane amount of traffic my mother's Roku TV shits out when it can't resolve/reach its spyware and telemetry services. It's like 95-98% of the blocked traffic on her network.
Is there a clean solution to this problem these days? Like some kind of adblocking router that resolves these addresses correctly but then routes packets destined for these services into a black hole so the requests eventually timeout? That would at least slow the repeat request floods down significantly.
text/html is not text/plain but that doesn't matter: it's not a technical limitation that caused cloudflare to draw this line.
it's cloudflare deciding to protect "web content" and not videos or .iso images or other things that normally are not commonly served while you browse a contemporary website and read HTML.
> it's cloudflare deciding to protect "web content" and not videos or .iso images or other things that normally are not commonly served while you browse a contemporary website and read HTML.
That's false in two ways: first, text is normally served while you browse a contemporary website; second, so are images, which are explicitly called out as potentially violating this clause. Text is the only data that isn't covered by this clause.
...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.
Simple but will it will break all sorts of automation down the line? All the other adlists are txt and I don't know how they would handle other file types, even if the content is unchanged.
Transmitting in-band (headers) seems ripe for arbitrary complexity. Someone out there would write a Turing-complete header DSL. And then someone else would write an incompatible alternative implementation.
At least file extension is limited and externally visible (and thus accountable) to third party behavior, which should limit the worst complexity excesses.
Is filesystem metadata actually different (theoretically) from extension? Or just data in a different format?
Extension seems a nice balance between simplicity / brevity and utility, albeit as a hint, not a commandment.
I hear you there. I'm more thinking someone probably hard coded txt file extension somewhere so something is likely to fall apart in simply handling that file.
I imagine that might help with automated tos rate limiting, but eventually someone at Cloudflare will probably cut them off. It's plain text, but it's basically serving a distributed database. And a hint at their scale is "100TB of “Access Denied” served up monthly.
Cloudflare just seems to be trying to limit the free tier to "caching website html for the purpose of showing it to humans". They have pricing and plans for things other than that.
Cloudflare can decide whom they want to do business with. But a plain text file is in my opinion sort of HTML. At least it is not "non-html" content. A .pdf file would be non-HTML content.
What else is important to note that the client is being abused and not the client abusing the service. That should be taken into consideration, when deciding if someone is breaking the ToS.
I'd agree that's weird. Seems like if it were simply renamed to .html with no content changes, then it would be okay.
> What else is important to note that the client is being abused and not the client abusing the service. That should be taken into consideration, when deciding if someone is breaking the ToS.
My understanding has this as moot. The issue from Cloudflare's perspective is only that the content is non-HTML and doesn't have anything to do with the rate of traffic (the abuse).
> (i) serving web pages as viewed through a web browser or other functionally equivalent applications, including rendering Hypertext Markup Language (HTML) or other functional equivalents, and (ii) serving web APIs subject to the restrictions set forth in this Section 2.8.
The key is "as viewed through a web browser" imo, this is not really an API and it's not a webpage; it's a datafile and would fall into R2 or similar things.
Why do people keep talking like you can't just navigate to a txt file in your browser and have it serve as any old web content? Which is something I have actually done many years ago to search for a domain in these types of lists.
Cloudflare is balancing on a razer for this TOS technicality.
The TOS aren’t referring to content-type headers, magic bytes, TCP headers, browser support of file formats, or any technical implementation.
To oversimplify, they’re saying Cloudflare’s service is to be used for serving websites to browsers.
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. I’m not sure why you’re trying to “gotcha” through their ToS.
It would be great if Cloudflare would donate resources to EasyList - it would do a lot to help the free and open internet by giving users more power over what gets delivered to their browser. But call that what it is: a donation.
> I’m not sure why you’re trying to “gotcha” through their ToS.
People are doing the opposite, pointing out the hole and asking them to get a better rule. Surely they don't just want the list merely converted into html.
> They give that away for free [...]
So they should specify things that influence cost such as total bytes served, number of files, etc. Currently all you can do it bypass the rule because you don't know how to cooperate.
The minimal spec valid HTML5 document is currently:
<!DOCTYPE html>
<title>a</title>
Practically, browsers will accept omitting both of these, and the spec even allows for omitting the title "if it is provided by a higher level protocol"
So it's not that crazy an argument that a plain text file is a html document
They serve websites to browsers for people to view. This file (be it properly formatted .html or .txt) is not a website people go to in their browser - its used internally by an application. This is the key point.
You're looking at it backwards though. CF doesn't _actually_ care about what the content is, only that they can apply their DDoS protections to it. If you're serving a text file that's much more difficult as they can't replace it with their own content.
This limitation apparently doesn't apply to R2 / Workers [0].
May be EasyList could host them there? That's what we do [1] (and the dashboards show 400TB+ per mo [2], likely rigged by the traffic between Workers and Cloudflare Cache).
If the web apis were a disproportionate amount of what was served for some customers specific free CF plan, as compared to the cached HTML, then that doesn't match their TOS.
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 their scale.
From a legal perspective I can understand such a wording, but I wonder why an engineer simply tells a (non-paying) customer that he violates the ToS, without thinking about it.
I mean, one could simply wrap the content in a HTML body and change the extension, but that would actually increase the data load for no good reason. So it is complete non-sense to complain about txt files being served.
Cloudflare caches robots.txt by default when proxied (the only .txt-file that they automatically cache), for all other content the following from their ToS probably applies:
> 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 as part of a Paid Service or expressly allowed under our Supplemental Terms for a specific Service.
We will never know the reasoning of the support agent who replied to the EasyList maintainers, but I can imagine that it is indeed disproportionate for EasyList.
I really hope that Cloudflare actually sees that they are making a wrong decision here and actually help the EasyList maintainers.
Sounds like they’re just using the wrong service. R2 is designed for object storage, and has 0 egress fees. That’d be the way to go. Not sure why the support engineer didn’t mention it. The standard cloudflare web caching probably doesn’t work well for this use case for whatever reason. The price is only 0.015/GB/mo, so the ~MB(?) of list would be served in perpetuity for less than a dollar.
Actually, you're right. How would this work? Is Cloudflare really willing to foot the bill of 20 TB of bandwidth per day for a small text file that costs $0 to store?
Yes why not ? For reputation and attracting developers it seems to be worth it.
If it costs 75K USD/year, that's already paid back with one big enterprise customer only.
Though, adblocking is a big business, many actors there are getting large revenue.
For example, Eyeo's income was 50 million USD per year last time I checked (and I guess most of it is actually profit), so they can find a solution if they really want.
Egress is free but not public i.e. you can't just give anyone an url. You have to use your own server to fetch content from R2 and then serve it to your visitors. Each fetch costs money but first 10 mil reads are free and your own server probably has egress fees.
They're probably still getting many millions of requests a month so probably more than a dollar but even 20 million requests a month would only cost $3.60 (10 million free at first then 10 million @ $0.36/million)
I assume you probably know this but just wanting to share there are some pricing scales with R2 they're just pretty generous for a lot of things.
Imagine you're trying to block a DDoS attack. If the client is downloading HTML then they likely also have JS enabled giving you a ton of options for running code on their computer to help you decide if the traffic is legitimate.
If they're downloading text you can still use the headers, and some tricks around redirects, but overall you have far less data on which to decide.
This issue caused CF to irreversibly ban them though, so it's not "just a bandwidth issue" anymore.
> Based on the URL that are being requested at Cloudflare, it violates our ToS as well. All the requests are txt file extension which isn't a web content
> you cannot use Cloudflare to cache or proxy the request to these text files
To me, getting banned is when the provider locks out (or just deletes) your account and prevents you from using their service entirely.
CF didn't do this. They sent them an email telling them that what they were doing was a violation of their TOS and to cease doing it. They did not kill off their account. They still have the option to comply and continue with CF, which seems to be what they are going to do at the moment.
Hopefully, CF will grant them amnesty on this one. At the end of the day, an HTML file is just a text file, so I don't see why this would have even mattered to begin with.
> This issue caused CF to irreversibly ban them though
Do you have a source for that? The article only mentions them being throttled + the screenshot with the support engineer saying they seem to be breaking the ToS and asking them politely to move back into compliance.
Sponsorblock has saved me hundreds of hours from watching youtube ads and other time wasting bullshit. The devs deserve to be paid for making this awesome application.
> Companies are also paying influencers, twitch streamers, and YouTubers to promote their products in a way that conventional ad blockers can't prevent.
Which I'm okay with in the same sense that I'm okay with newspaper/magazine ads or billboards or TV/radio commercials: they're annoying, but easy to ignore compared to online ads chewing up CPU time and battery life while actively violating one's privacy.
> in a way that conventional ad blockers can't prevent
Yet. One day someone will create an ad blocker with machine learning that "sees" the ads and deletes them in real time. Should work on all content types, even on augmented reality.
They already have that part figured out. From the article:
> When we encountered a similar problem last year, we found a simple solution: block the undesired traffic from these apps. Even so, we continue to serve about 100TB of “Access Denied” pages monthly!
The difference is that serving Access Denied Leads to the users of these malicious browsers just getting more ads over time, as the filter lists can’t be updated anymore. Serving a special list containing popular sites would result in the users almost instantly not being able anymore to access these popular sites, resulting in requests to the developers to fix their shitty browser or switching altogether.
I'm sympathetic to their trouble but we're talking about serving a 330KB text file (150KB compressed), surely this isn't an insurmountable technical hurdle to overcome?
A 1000mbps dedicated server could serve it 70 MILLIONS times per day. Considering that most wouldn't be served (E-tags and whatnot), it can probably sustain a billion requests a day.
It’s not really the serving that’s the issue - it’s the amount of bandwidth used… in the case of serving simple content (like txt) bandwidth is always going to be the expensive element
It seems they need some form of UUID in order to rate-limit individual clients. I wonder what percentage of their traffic would drop if they started requiring some form of authentication to download this list?
It would seem like you could prevent hotlinking by adding 1-5 minutes of latency to every request to a list.
Almost no dev would hotlink an asset that took that much longer to display, at least in critical/common paths. It would force consumers (devs/businesses) of the lists to provide a caching/mirroring solution of some kind for their users.
But on the bankend, the request would be designed just for updating the list cache. Handling 1-5 extra minutes per request, on a request that runs less than a few dozen times a day, to update the mirror/cache is trivial.
The issue with this approach is it's too late. It might work if you designed it from the start, but adding it now would only destroy your poor balancer with all the connections they have to maintain (waiting for the 5 minutes to expire).
It was mentioned in this article that they are now serving up accessed denied, but the problem is one of just too many requests.
At this point, it's likely easier to just kill the domain all together and get a new one.
This is certainly not a cure to the problem Easylist has right now. This is prevention. About how to design publicly consumable resources to naturally discourage hotlinking, before it is a problem.
pool.ntp.org hands out specific subdomains for large-scale pool users. This way, it is possible to retire service for a subset of users that use devices that aren't updated anymore and are misbehaving.
The traffic issue is not just punted to DNS service. It's possible to return a cachable 127.0.0.1 response, and it's somewhat rare for DNS caches to be constantly powered up and down and reach out directly to authoritative DNS servers.
I worked on an ad-blocker a few months ago. I made the decision to have the filter-list files hosted on our own domain and CDN (similar to what Adguard does with their filters.adtidy.org).
This was done for 2 reasons:
1- Avoid scenarios like this where you ship code (extension in this case) that is hard to update. Then make that code depend on external resources outside of your control.
2- Leak our users' IP addresses to each random hosting provider.
So the solution was simple: Run a CRON once a day then host the files ourselves. Pretty happy with that decision now.
Except neither of those would help in this case. They’re already using their own domain name, and it’s unclear how they would even build their own CDN since they’re using that scale of bandwidth - AdGuard said they’re still pushing 100tb of access denied pages a month for their similar case. That is a LOT of bandwidth just for access denied messages.
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.
It was not implied, you added that implication yourself and started responding to things that were not said, which is why the other commenter who replied to you was also confused, my friend.
Edit:
OP was implying their approach was better for themselves than relying on third party servers. It’s hardly obtuse, it’s a related discussion from someone who would otherwise be impacted by the throttling.
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.
This sounds like a similar issue as Linux distros used to have, I'm not sure how many still do this, but use alternative sites.
On download.easylist.com have it shuffle and send a redirect to a mirror to download the list. I wonder if Universities are still offering these small amounts of space for Open Source projects?
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?
438 comments
[ 3.1 ms ] story [ 300 ms ] thread> The problem is that this browser has a very serious flaw. It tries to download filters updates on every startup, and on Android it may happen lots of times per day. It can even happen when the browser is running in the background
EasyList should be offered as a version-controlled copy you grab once, that then gets bundled with an app, rather than offering a download to be called from an app: https://easylist.to/easylist/easylist.txt (Currently down as of writing).
The only caveat is such a list needs to be updated, so then a version system should be implemented for EasyList and you periodically bundle the new version via app updates. It would save a lot of bandwidth doing this.
As a quick fix, there are many options for limiting per IP per timespan, e.g. fail2ban, you could configure it to punish bad apps without crippling functionality for others. Well, maybe crippling a little bit in some very special use cases, still better than it simply not working.
Podcasting 2.0 has been talking about podping as a solution because podcasting basically has the same problem with periodic polling of the RSS feed. Basically you subscribe and then receive notice there's been an update, THEN you go get it.
https://www.podcasthelpdesk.com/podping-and-other-stuff-with...
PFBlocker seems to default to once a day.
There is no approach you can describe that doesn't run afoul of the described badly-behaved browser app which willfully retrieves the entire file afresh at every init. If it can be downloaded, it will be downloaded directly by the badly-behaved mobile apps.
Unfortunately, I can't find a reference to it anymore.
https://en.wikipedia.org/wiki/Censorship_of_Wikipedia:
“Wikipedia has been blocked in China since 23 April 2019”
⇒ putting ads for Wikipedia on sites likely isn’t safe everywhere.
I think it will be very hard to find “some other organization” that is universally ‘approved’ everywhere.
The thing is, they didn't host the scrapped images themselves, they just hot-linked everything.
So through a little nginx config, we turned their entire homepage to an ad for my friend's platform :)
In earlier days of the Web, someone appeared to have hotlinked a photo from a page of mine, as their avatar/signature in some Web forum for another country, and it was eating up way too much bandwidth for my little site.
I handled this in an annoyed and ill-informed way, but which I thought was good-natured, and years later realized it was potentially harmful. I'd changed the URL to serve a new version of the image, to which I'd overlaid text with progressive political slogans relevant to their country. (Thinking I was making a statement to the person about the political issues, and that it would be just a small joke for them, before they changed their avatar/signature to stop hotlinking my bandwidth.) Years later, once I had a bit more understanding of the world, I realized that was very ignorant and cavalier of me, and might've caused serious government or social trouble for the person.
Sensitized by my earlier mistake, I could imagine ways that a subtly NSFW image could cause problems, especially in the workplace, and in some other cultures/countries.
Subtle things like flipping the image upside down or reversing the colors or other "not quite harmful but quite annoying" responses are probably better, or just serve a 1x1 pixel image of nothing.
https://news-ltn-com-tw.translate.goog/news/world/breakingne... (nsfw)
https://www.rfa.org/english/news/china/japan-piracy-09252022...
1: https://news-infoseek-co-jp.translate.goog/article/president... (og: https://news.infoseek.co.jp/article/president_61325/ )
2: https://i.imgur.com/5hjqu3L.jpg (label on bottle and window sign)
https://www.vice.com/en/article/bvxb94/is-this-beverly-hills...
I was getting hotlinked from controversial sites a lot at one stage, and the common forum software they used didn't force image sizes. So a 5k pixel wide image pushed most of the content off the screen thanks to a centred element :)
[1] https://twitter.com/dohoons/status/880347968800411648
https://www.ex-parrot.com/pete/upside-down-ternet.html
The normal easylist is way bigger and has lots of rules for ad blockers like uBlock Origin.
Meanwhile perhaps some other CDN provider wants to create some goodwill if Cloudflare isn't willing?
What is the reason for proxying through Cloudflare? Are there any bandwidth limits or performance issues when directly serving those files from GitHub?
---
> GitHub Pages sites have a soft bandwidth limit of 100 GB per month.
> In order to provide consistent quality of service for all GitHub Pages sites, rate limits may apply. These rate limits are not intended to interfere with legitimate uses of GitHub Pages. If your request triggers rate limiting, you will receive an appropriate response with an HTTP status code of 429, along with an informative HTML body.
> If your site exceeds these usage quotas, we may not be able to serve your site, or you may receive a polite email from GitHub Support suggesting strategies for reducing your site's impact on our servers, including putting a third-party content distribution network (CDN) in front of your site, making use of other GitHub features such as releases, or moving to a different hosting service that might better fit your needs.
---
'Legitimate' users of the list would clone/pull the repo to their own mirror?
EasyList updates frequently, many times each day, as the commits to that repo demonstrate.
I suspect the latter. I don't know how to make a repo public but limit web traffic to it. Do you?
This is hilarious in an unbelievably terrible and tragic way. The scale is mind boggling.
I wonder which browser it is.
What's the carbon footprint of this?
While still trying to allow valid traffic through.
The sent http body was blank, but I beleive we were still sending http head...
> If firewall access exists, just drop the offending incoming traffic entirely.
True, but the service we were using at the time didn't have a L3 firewall, and so we ended up moving out, after paying the bills in full, of course.
Is there a clean solution to this problem these days? Like some kind of adblocking router that resolves these addresses correctly but then routes packets destined for these services into a black hole so the requests eventually timeout? That would at least slow the repeat request floods down significantly.
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 cloudflare deciding to protect "web content" and not videos or .iso images or other things that normally are not commonly served while you browse a contemporary website and read HTML.
That's false in two ways: first, text is normally served while you browse a contemporary website; second, so are images, which are explicitly called out as potentially violating this clause. Text is the only data that isn't covered by this clause.
It's all 1s and 0s too
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.
But anyway, just rename .txt to .html and you're done.
At least file extension is limited and externally visible (and thus accountable) to third party behavior, which should limit the worst complexity excesses.
Is filesystem metadata actually different (theoretically) from extension? Or just data in a different format?
Extension seems a nice balance between simplicity / brevity and utility, albeit as a hint, not a commandment.
Cloudflare just seems to be trying to limit the free tier to "caching website html for the purpose of showing it to humans". They have pricing and plans for things other than that.
What else is important to note that the client is being abused and not the client abusing the service. That should be taken into consideration, when deciding if someone is breaking the ToS.
> What else is important to note that the client is being abused and not the client abusing the service. That should be taken into consideration, when deciding if someone is breaking the ToS.
My understanding has this as moot. The issue from Cloudflare's perspective is only that the content is non-HTML and doesn't have anything to do with the rate of traffic (the abuse).
The key is "as viewed through a web browser" imo, this is not really an API and it's not a webpage; it's a datafile and would fall into R2 or similar things.
Cloudflare is balancing on a razer for this TOS technicality.
To oversimplify, they’re saying Cloudflare’s service is to be used for serving websites to browsers.
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. I’m not sure why you’re trying to “gotcha” through their ToS.
It would be great if Cloudflare would donate resources to EasyList - it would do a lot to help the free and open internet by giving users more power over what gets delivered to their browser. But call that what it is: a donation.
People are doing the opposite, pointing out the hole and asking them to get a better rule. Surely they don't just want the list merely converted into html.
> They give that away for free [...]
So they should specify things that influence cost such as total bytes served, number of files, etc. Currently all you can do it bypass the rule because you don't know how to cooperate.
Imagine you do that and I DDoS the URL. CF will then mitigate this DDoS by, in part, replacing your html with their Browser Integrity Check html.
If you're serving 'web pages and websites' everything continues to work. What would happen if this list suddenly became an actual webpage.
If your site is serving 'a disproportionate percentage' of non-html you decrease the ability of CF to tell good traffic from bad.
So it's not that crazy an argument that a plain text file is a html document
They serve websites to browsers for people to view. This file (be it properly formatted .html or .txt) is not a website people go to in their browser - its used internally by an application. This is the key point.
May be EasyList could host them there? That's what we do [1] (and the dashboards show 400TB+ per mo [2], likely rigged by the traffic between Workers and Cloudflare Cache).
[0] https://news.ycombinator.com/item?id=20791660
[1] https://news.ycombinator.com/item?id=30034547
[2] https://nitter.net/rethinkdns/status/1546232186554417152
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 their scale.
Some think its very Oracle of Cloudflare to do so. I do not blame them.
I mean, one could simply wrap the content in a HTML body and change the extension, but that would actually increase the data load for no good reason. So it is complete non-sense to complain about txt files being served.
> 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 as part of a Paid Service or expressly allowed under our Supplemental Terms for a specific Service.
We will never know the reasoning of the support agent who replied to the EasyList maintainers, but I can imagine that it is indeed disproportionate for EasyList.
I really hope that Cloudflare actually sees that they are making a wrong decision here and actually help the EasyList maintainers.
Though, adblocking is a big business, many actors there are getting large revenue.
For example, Eyeo's income was 50 million USD per year last time I checked (and I guess most of it is actually profit), so they can find a solution if they really want.
https://img.phantasmagoria.me/img/96XJrjejoHNdrQv7.jpg
Even if you have a private bucket, you can give people a signed link with read access, for up to two weeks, IIRC.
But it'll still cost them money by number of reads
I assume you probably know this but just wanting to share there are some pricing scales with R2 they're just pretty generous for a lot of things.
If they're downloading text you can still use the headers, and some tricks around redirects, but overall you have far less data on which to decide.
Even more wtf- the file extension determines the file content?
It may be easy, and it may even be the only option, but it's a bad one that will need some thought from the maintainers I expect.
It's not ideal, but until the problem is fixed/better solutions are found, I think it's a good "first response".
> Based on the URL that are being requested at Cloudflare, it violates our ToS as well. All the requests are txt file extension which isn't a web content
> you cannot use Cloudflare to cache or proxy the request to these text files
This does not mean banned.
They didn’t ban the whole organization, but effectively told them to stop. I don’t see a difference.
CF didn't do this. They sent them an email telling them that what they were doing was a violation of their TOS and to cease doing it. They did not kill off their account. They still have the option to comply and continue with CF, which seems to be what they are going to do at the moment.
Hopefully, CF will grant them amnesty on this one. At the end of the day, an HTML file is just a text file, so I don't see why this would have even mattered to begin with.
Do you have a source for that? The article only mentions them being throttled + the screenshot with the support engineer saying they seem to be breaking the ToS and asking them politely to move back into compliance.
Google built an entire browser and used Manifest V3 as an excuse to cripple ad blockers.
Companies are also paying influencers, twitch streamers, and YouTubers to promote their products in a way that conventional ad blockers can't prevent.
The very interesting thing is that none of Google's ads have ever made it through this new version of Ublock for me.
Which I'm okay with in the same sense that I'm okay with newspaper/magazine ads or billboards or TV/radio commercials: they're annoying, but easy to ignore compared to online ads chewing up CPU time and battery life while actively violating one's privacy.
Yet. One day someone will create an ad blocker with machine learning that "sees" the ads and deletes them in real time. Should work on all content types, even on augmented reality.
> When we encountered a similar problem last year, we found a simple solution: block the undesired traffic from these apps. Even so, we continue to serve about 100TB of “Access Denied” pages monthly!
Instead, you need to break the user experience so they complain to the developer of the app, thus impacting reputation.
It’s unfortunate that the browsers developers are unresponsive and this circumstance limits the available options to easy list.
A 1000mbps dedicated server could serve it 70 MILLIONS times per day. Considering that most wouldn't be served (E-tags and whatnot), it can probably sustain a billion requests a day.
What am I missing?
A 1000Mbps server could only serve 10.8TB, and that's not even accounting for overhead/daily usage patterns/etc
https://web.archive.org/web/20220901000327if_/https://easyli...
If you're getting a 330KB file, maybe the server issues are causing the download to fail?
I would add a redirect to the makers of the browsers in question (so that the leechers got to deal with the traffic themselves; https://en.wikipedia.org/wiki/Inline_linking)
Almost no dev would hotlink an asset that took that much longer to display, at least in critical/common paths. It would force consumers (devs/businesses) of the lists to provide a caching/mirroring solution of some kind for their users.
But on the bankend, the request would be designed just for updating the list cache. Handling 1-5 extra minutes per request, on a request that runs less than a few dozen times a day, to update the mirror/cache is trivial.
It was mentioned in this article that they are now serving up accessed denied, but the problem is one of just too many requests.
At this point, it's likely easier to just kill the domain all together and get a new one.
The traffic issue is not just punted to DNS service. It's possible to return a cachable 127.0.0.1 response, and it's somewhat rare for DNS caches to be constantly powered up and down and reach out directly to authoritative DNS servers.
This was done for 2 reasons:
1- Avoid scenarios like this where you ship code (extension in this case) that is hard to update. Then make that code depend on external resources outside of your control.
2- Leak our users' IP addresses to each random hosting provider.
So the solution was simple: Run a CRON once a day then host the files ourselves. Pretty happy with that decision now.
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.
Edit: so if OP wasn’t implying that their approach was better, what was the point of posting it? Wow, obtuse much?
Edit:
OP was implying their approach was better for themselves than relying on third party servers. It’s hardly obtuse, it’s a related discussion from someone who would otherwise be impacted by the throttling.
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.
On download.easylist.com have it shuffle and send a redirect to a mirror to download the list. I wonder if Universities are still offering these small amounts of space for Open Source projects?