But it's not JSON or HTML. And it's not meant for browsers. It's clearly a dataset as a text file and not meant as "web(page) content". What's nonsense about that when it's completely accurate?
And there is no reason a web app couldn't read data from a txt file instead of a json file.
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.
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?
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?
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?
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).
Also, the same ToS applies if you use the paid product. Unless you buy an additional addon for non-web traffic.
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?
> why such a fuss
Mockery isn't a fuss. And why? Because we can all picture having to deal with just this sort of idiot and their pet rule.
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.
It literally is - specifically, for extensions thereof.