It's not for displaying a webpage but to power a separate application. Just because you can serve any kind of file over HTTP doesn't mean it's for serving a website. There's a reason Cloudflare doesn't allow large video files either - even though that probably counts even more as "web content".
This is a very straightforward interpretation of the terms and it's strange to see such pushback based on a pedantic technicality when it's clear what the file is being used for.
In fact, if this was the opposite situation and some automated rule was involved in isolating this file, I expect the same people would then want human intervention to clear up the difference based on the context.
> There's a reason Cloudflare doesn't allow large video files either - even though that probably counts even more as "web content".
And that's just as nonsensical. Bytes are bytes; the rationale should be based on bandwidth, not on arbitrary micromanagement of the format of the data consuming that bandwidth. If I encode that video in a giant self-contained blob of JavaScript that feeds the pixels into a canvas or something similarly ridiculous, does that magically fix the bandwidth issues?
No. It is about excessive resources/bandwidth usage. The customer service response reply isn't great but the context itself is clear because this file is clearly not for displaying any part of the web presence of the easylist site.
Again this is that "pedantic technicality" - why such a fuss when the actual issue is straightforward, and also clearly understood and reiterated by the easylist team themselves in the post?
> 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 fix the bandwidth issues associated with hosting videos? If I have a 10MB MP3 downloaded 1,000 times v. a 1MB HTML/CSS/JS static site downloaded 10,000 times, what difference does it make?
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. The free tier is just the demo version: I think at the end of the day the policy is about not everyone in HN using CF for their low-cost DIY video and/or music streaming or download platform.
And I can totally see them reverse the decision and sponsor that project (it's probably something a support engineer has no power to decide).
The issue is about bandwidth and resources. The policy is generic to provide reasonable allowances but stop usage that's clearly outside the limits. That's how "unlimited but with oversight" plans work.
The majority of of legitimate traffic to these txt files are by browsers(extensions) for the express purpose of displaying websites to a users specifications(without ads in this case).
A reasonably low estimate is that 20%-30% of global internet users are behind some kind of adblocker, almost all of which are default subscribed to easylists. So this txt file is potentially responsible for the way a BILLION+ internet users see and interact with near every single website.
Cloudflares claim that this isn't web content is full on reality warping. It only makes any kind of sense when masked under layers of abstractions and lawyer speak.
---
None this should even matter though, someone seeing the big picture at CF should have done the napkin math and realized that the easylist bandwidth pays for itself.
Ignoring the soft cushion of the huge amount of globally distributed caching of these files, if easylist suddenly stopped working for a week then global bandwidth usage could see a spike. A pretty little chunk of which CF may be on the hook to absorb at no cost.
But the support email didn't say it was a violation of the ToS because it is primarily used by non webpage applications (the ToS does say APIs may be allowed, but doesn't have specific details on when afaict), it says it is a violation because it is a txt file, and there is a txt couldn't be a part of a website. And in fact robots.txt and security.txt are standard and common txt files serves as part of websites. In the case if robots.txt it also is primarily consumed by web crawlers, not for actually rendering web pages. Does that mean robots.txt violates the ToS too?
This is a very straightforward interpretation of the terms and it's strange to see such pushback based on a pedantic technicality when it's clear what the file is being used for.
In fact, if this was the opposite situation and some automated rule was involved in isolating this file, I expect the same people would then want human intervention to clear up the difference based on the context.