Comment by 1vuio0pswjnm7
3 hours ago
If Cloudflare (CF) has r/w access to the response body, which CF does have by default, then CF can easily modify or remove that <meta> tag. The risk is not abated
The risk of third parties injecting scripts, etc., e.g., analytics, advertising, etc., into response bodies (web pages) is usually cited as a rationale for using HTTPS^1
CF somehow avoids the usual objections. CF is a MiTM but few people object
1. For example, a data collection, surveillance and advertising services company that operates a www search engine and releases a web browser may not want an ISP to inject scripts, etc., e.g., analytics, ads, etc., into web pages as it might compete with the company's business. As a defense against such ISPs and other third parties that are potential competitors for data collection/surveillance/advertising services, it might favor HTTPS sites in its www search engine results, promote HTTPS at conferences discussing its web browser, etc.
FWIW, I operate own DNS (including own custom root.zone) and I MiTM own TLS traffic with a localhost forward proxy. With this setup I get r/w access to response bodies, I add a CSP as an HTTP response header, and a long list of other traffic manipulation. There is no tracking, ads, telemetry, etc. Nothing leaves the computer unless I allow it. Operating DNS plus forward proxy gives me lots of control
Letting Cloudflare (CF) operate DNS and direct traffic through its proxies gives CF control
It's interesting to see how they use it under market pressures
This is a tangent, but your setup sounds interesting to me — would you share more about how to configure such for myself?
Thanks for the background context, very interesting and realistic. Yes, of course it also has read/write access, though I always make sure there’s no interference of that kind. It has only happened to me once, where a binary I hosted on Pages didn't work when downloaded with wget (though that happened several years ago).