Comment by kenmacd | Hacker News Reader

Comment by kenmacd | Hacker News Reader

Parent Full thread

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

> <sigh> 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.

> 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).

Reply on news.ycombinator.com