Most relevant piece but the whole comment is worth a read:
> Archive.is’s authoritative DNS servers return bad results to 1.1.1.1 when we query them. I’ve proposed we just fix it on our end but our team, quite rightly, said that too would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service.
> The archive.is owner has explained that he returns bad results to us because we don’t pass along the EDNS subnet information. This information leaks information about a requester’s IP and, in turn, sacrifices the privacy of users.
Honestly it's that type of thing (the frankness, the presence on HN, willingness to participate, the principled stand on privacy) that got me into Cloudflare products. I now generate hundreds per month in revenue for them and that will likely be thousands in the next year or two. His time/effort on HN directly led to customer acquisition and revenue.
That said I do worry about the incentives Cloudflare has to their big customers. CF is a great tool for site owners, but like any tool has the potential to be a great evil (against the user) if the principles ever wane. It's already being used by a lot of sites to make life a living hell for people behind a VPN. As a site owner I absolutely get it: practically zero of my legitimate traffic comes from VPNs (our main demographic tend to skew older and much less technical than the average consumer), but all of the automated attacks against me do. Balancing freedom and rights is hard, but I deeply appreciate the thoughtfulness and principles that CF has displayed over the years.
[1] >>36197401
[2] https://www.ietf.org/archive/id/draft-private-access-tokens-...
I've tried raising this issue on their forum, where I've failed to get the attention of the engineering teams, and while posting the ray ID should be sufficient, all you'd really get is clueless, unpaid volunteers asking you questions in circles like "what website do you see this on" (everywhere), "are you using adblock" (no, and Adblock has never blocked their Turnstile scripts) and "what's your user agent?" (the default Chromium one).
If I had to hazard a guess, it's their bot management script seeing "Linux" in the user agent and detecting missing video codecs (which is par for the course for standard Chromium builds), and thinking it's a headless browser. Between the the fact that differences between the JS runtime of Chromium and Chromium headless are very small these days, and the ClientHello permutation has destroyed bot management vendors' ability to distinguish different browser builds, they decided blocking all Linux users using Chromium was fair enough.
For an issue that pointed to cloudflare, but ultimately was our hoster having an issue with completing the TLS handshake...
After infra update ofc.
Tldr: had the opposite experience, for a technical issue :)