I have absolutely no reason to think Cloudflare is a covert CIA operation. In fact, I’m sure there are plenty of good reasons to think it isn’t. But if it were, pretty much everything it does is exactly what you'd expect from one.
NSA's mission, as outlined in Executive Order 12333 in 1981, is to collect information that constitutes "foreign intelligence or counterintelligence" while not "acquiring information concerning the domestic activities of United States persons".
Well, you see, Your Honor, when the foreign entities do the spying inside the US, they inevitably become one side in the domestic activities of United States persons. So it's only reasonable to conclude that this part of the Executive Order is null and void.
Other than platforming some of the worst people on the web … a lot of the stuff coming out of Cloudflare has been really awesome. No egress fees R2 is top of mind.
Ok, so grant for the moment that it’s both the largest conspiracy ever and the best kept secret ever.
How is anyone worse off using their OHTTP gateway than not using it? Is the idea that CF is this spectacular conspiracy, but nobody thought of capturing traffic from backbones?
> Customers will be able to enable our new OHTTP Gateway as a paid add-on to their zone and start receiving OHTTP traffic with just a few clicks.
I love to see privacy improvement in tech. However I do wonder at this. Cloudflare is obviously a business and can't do everything for free, but charging extra for websites to add privacy Seems like a poor incentive if the goal is to improve privacy generally
As cloudflare is the gateway for half the Internet and the other half is meta Google and Microsoft, I would prefer to share my IP with the website I visit instead some big tech companies.
I’ve wanted this for a while. I make private desktop software for transcribing meetings. It’s essentially offline, but things like checking for updates require the network. I looked at ohttp but it was still private, and ended up pinging GitHub releases directly.
There’s also room for a privacy-centric analytics offering
> such that only the client and app server can see plaintext, and the relay sees only a jumble of ciphertext. A “gateway” sits between the relay and app server to handle all of this cryptography — decapsulating requests, encapsulating responses — and the app server handles only plain HTTP
Wouldn't that be better if you design an oblivious encryption method so the encryption and decryption is handled by the origin server (a.k.a Target Resource in the RFC) and the Client? Instead of letting anyone in the middle to handle that data?
Their current design looked not that different than if you just connect to a public anonymous SOCKS5 server (which don't decrypt TLS traffic) and uses it to connect to a website hosted behind Cloudflare. It would probably work the same way too, since someone has to host a "OHTTP Relay" the same way they host a anonymous SOCKS5 server.
Nothing really prevents you from doing double encryption in OHTTP. The gateway decrypts once, and the origin (target resource) decrypts a second time. Typically HPKE is used for the inner layer.
> Meanwhile, some app developers end up knowing more about their users than they’d care to: a typical client-server exchange creates a trail of user data, like the client’s IP address or TLS fingerprint. This level of visibility can be a burden.
Can someone expand on “burden” here? Scenarios that come to mind for me are something like: “I now need to ensure my log files are stored securely but that’s a PITA.” This doesn’t feel like the best example of why I’d use this though. (Edit: Secure messaging servers for a service like Signal?)
Every data point you keep can be leaked, or abused, and has to be protected (at least in jurisdictions that don't just go eeh, whatever when it comes to protecting their citizens). There are tons of scenarios where I don't want your IP address, ideally I'd not even like to store your password. The more you store, the more you paint crosshairs on your back for hackers. You need to adhere to regulations, anonymise or delete it as customers leave, and solve problems like "should backups be immutable, or pruned from data I should no longer retain". At a certain size, you even need to defend on the inside to avoid more ruthless managers from abusing data you have been entrusted with for illegal analysis or data sales to analytics companies.
If your view on data protection or privacy is "I don't care about it, my users can go to hell as long as they pay"--then sure, this whole discussion probably seems pointless to you. But otherwise, storing and handling as little data as you can probably resonates with you as a good solution to many problems.
"I don't care about it, my users can go to hell as long as they pay"
The above is also a good reason why you wouldn't want to get any of their data.
Users who are not consumers are of no interest, and users who become customers will give the necessary data to make a purchase without any need to spy on them.
So.. they continue having access to private identifiers, while you willingly give it up to "protect privacy"? Piping all of that data into a massive central database instead of your nginx logs? How is this supposed to be better?
Hm. Interesting. I wonder how you would add "banning abusers by IP" functionality to it though — you first need to identify the abuse somehow and then link it to the originating IP (or any other kind of identifier)...
Cloudflare Warp has been more of an issue for a small webapp I run than residential proxies. Because it's a mix of legitimate users whom I guess installed the 1.1.1.1 app and have no idea they're tunnelling all their traffic through Cloudflare, and abusive users. I've never seen an actual CGNAT IP addresses from a consumer ISPs being shared by a legitimate user and a persistent abusive one.
CF seems to end up in the business of making problems worse, and selling the fix way too often. Before this, I had someone try to DDoS a webapp by setting up their own domain to proxy to my backend and running their attack traffic through CF. But that was easy, I could just block CF's IP range entirely as I don't use their reverse proxies.
At my previous job we routinely gave out IP-based bans, and it worked pretty well; the most insistent guys gave up after their third or fourth IP banned at most.
If I want to preserve the privacy of my users I will avoid using massive behavior capturing networks like Cloudflare. The is no world where giving them the tracking is better then just ensuring I anonymize my logs. If my users don't trust me; and are informed enough to understand what this service dose and doesn't cover they are just going to assume I can fingerprint them in some other way.
I'm seeing more and more organizations that I neither can identify nor pin down now using more and more cloudflare privacy offerings to "hide" their intentions.
I respect customer privacy. But I also need to know who is abusing my platforms as well. The balance here is very difficult to manage, now that we have entire agentic platforms capable of deploying highly technical capable "abuse" platforms.
To those missing it, it’s a reference to an internal NSA presentation that shown this sentence with an arrow at the boundary of google network and the internet.
> a typical client-server exchange creates a trail of user data, like the client’s IP address or TLS fingerprint. This level of visibility can be a burden.
Does Cloudflare's WAF (which relies on TLS Fingerprinting) stop working if OHTTP is enabled? If not, does this imply the client metadata is read and processed by Cloudflare but not passed on to the application server?
The irony is that the majority of people that need this don’t have the cognitive time or skill to process and set it up for themselves. But the agents and bad actors like North Korean hackers would absolutely have the time and ability to implement and use it. Then you have the market for lemons problem - if requests coming from here are malicious most requests coming from here will be seen as malicious. Aka dark alleys earn their reputation over time.
Pathetically, people probably won't even erase cookie, let alone JavaScript. To begin with, any websites are not designed to be viewable without js. There are countless ways to find fingerprints. It is impossible to prevent tracking anyway in current the internet.
It’s entirely possible if the application developers have made the choice to intentionally avoid tracking and tying personal data to user identity, which is exactly who this product is aimed at.
I have absolutely no reason to think Cloudflare is a covert CIA operation. In fact, I’m sure there are plenty of good reasons to think it isn’t. But if it were, pretty much everything it does is exactly what you'd expect from one.
Of course it's not a CIA operation — that agency is foreign intelligence agency. The domestic intelligence agency is called NSA.
Whether they abide by that is another matter.
https://en.wikipedia.org/wiki/NSA_warrantless_surveillance_(...
Well, you see, Your Honor, when the foreign entities do the spying inside the US, they inevitably become one side in the domestic activities of United States persons. So it's only reasonable to conclude that this part of the Executive Order is null and void.
Two branches from the same trunk with their leaves touching. The boundaries are pure show.
Other than platforming some of the worst people on the web … a lot of the stuff coming out of Cloudflare has been really awesome. No egress fees R2 is top of mind.
You want to say the intelligence agencies are the biggest protectors of piracy (Piracy websites love Cloudflare)?
The way I look at it is more like civil vs criminal.
The US Gov can just ask, and American corporations will deliver. No need to get their hands dirty.
The more people join in and become dependent on CF, the more incentive there is to subvert CF. Or am I being dumb?
Another thing is the motivation to send people to work for CF. And another thing is the question of preparation vs hope.
Are you, by chance, an operative, sir? :)
I dare say that Cloudflare would represent excellent value for money to the intelligence agencies.
And Google. And Apple. And Microsoft.
Less good value though. Cloudflare is currently 1/20th the valuation and is actively operating as a MITM attack on half of the internet.
Ok, so grant for the moment that it’s both the largest conspiracy ever and the best kept secret ever.
How is anyone worse off using their OHTTP gateway than not using it? Is the idea that CF is this spectacular conspiracy, but nobody thought of capturing traffic from backbones?
> Customers will be able to enable our new OHTTP Gateway as a paid add-on to their zone and start receiving OHTTP traffic with just a few clicks.
I love to see privacy improvement in tech. However I do wonder at this. Cloudflare is obviously a business and can't do everything for free, but charging extra for websites to add privacy Seems like a poor incentive if the goal is to improve privacy generally
As cloudflare is the gateway for half the Internet and the other half is meta Google and Microsoft, I would prefer to share my IP with the website I visit instead some big tech companies.
But maybe I get privacy wrong.
What if the solution is garbage? There are ad blockers that click every ad. Random google searches, random chatbot searches, random clicks.
I have a feeling that privacy is easier to protect if you just mix what you want to hide with a lot of garbage.
Why not both? When browsing Microsoft, give your IP to Cloudflare. When browsing Pouet, give your IP to Pouet.
I’ve wanted this for a while. I make private desktop software for transcribing meetings. It’s essentially offline, but things like checking for updates require the network. I looked at ohttp but it was still private, and ended up pinging GitHub releases directly.
There’s also room for a privacy-centric analytics offering
https://github.com/scosman/Biscotti
OHTTP is a neat split: the relay learns who you are, the gateway learns what you ask, and neither gets both.
> such that only the client and app server can see plaintext, and the relay sees only a jumble of ciphertext. A “gateway” sits between the relay and app server to handle all of this cryptography — decapsulating requests, encapsulating responses — and the app server handles only plain HTTP
Wouldn't that be better if you design an oblivious encryption method so the encryption and decryption is handled by the origin server (a.k.a Target Resource in the RFC) and the Client? Instead of letting anyone in the middle to handle that data?
Their current design looked not that different than if you just connect to a public anonymous SOCKS5 server (which don't decrypt TLS traffic) and uses it to connect to a website hosted behind Cloudflare. It would probably work the same way too, since someone has to host a "OHTTP Relay" the same way they host a anonymous SOCKS5 server.
Nothing really prevents you from doing double encryption in OHTTP. The gateway decrypts once, and the origin (target resource) decrypts a second time. Typically HPKE is used for the inner layer.
> Meanwhile, some app developers end up knowing more about their users than they’d care to: a typical client-server exchange creates a trail of user data, like the client’s IP address or TLS fingerprint. This level of visibility can be a burden.
Can someone expand on “burden” here? Scenarios that come to mind for me are something like: “I now need to ensure my log files are stored securely but that’s a PITA.” This doesn’t feel like the best example of why I’d use this though. (Edit: Secure messaging servers for a service like Signal?)
Every data point you keep can be leaked, or abused, and has to be protected (at least in jurisdictions that don't just go eeh, whatever when it comes to protecting their citizens). There are tons of scenarios where I don't want your IP address, ideally I'd not even like to store your password. The more you store, the more you paint crosshairs on your back for hackers. You need to adhere to regulations, anonymise or delete it as customers leave, and solve problems like "should backups be immutable, or pruned from data I should no longer retain". At a certain size, you even need to defend on the inside to avoid more ruthless managers from abusing data you have been entrusted with for illegal analysis or data sales to analytics companies.
If your view on data protection or privacy is "I don't care about it, my users can go to hell as long as they pay"--then sure, this whole discussion probably seems pointless to you. But otherwise, storing and handling as little data as you can probably resonates with you as a good solution to many problems.
"I don't care about it, my users can go to hell as long as they pay"
The above is also a good reason why you wouldn't want to get any of their data. Users who are not consumers are of no interest, and users who become customers will give the necessary data to make a purchase without any need to spy on them.
Reading between the lines: privacy regulaton?
So.. they continue having access to private identifiers, while you willingly give it up to "protect privacy"? Piping all of that data into a massive central database instead of your nginx logs? How is this supposed to be better?
Hm. Interesting. I wonder how you would add "banning abusers by IP" functionality to it though — you first need to identify the abuse somehow and then link it to the originating IP (or any other kind of identifier)...
You already can't do that since the abuser will just buy residential proxies.
Cloudflare Warp has been more of an issue for a small webapp I run than residential proxies. Because it's a mix of legitimate users whom I guess installed the 1.1.1.1 app and have no idea they're tunnelling all their traffic through Cloudflare, and abusive users. I've never seen an actual CGNAT IP addresses from a consumer ISPs being shared by a legitimate user and a persistent abusive one.
CF seems to end up in the business of making problems worse, and selling the fix way too often. Before this, I had someone try to DDoS a webapp by setting up their own domain to proxy to my backend and running their attack traffic through CF. But that was easy, I could just block CF's IP range entirely as I don't use their reverse proxies.
At my previous job we routinely gave out IP-based bans, and it worked pretty well; the most insistent guys gave up after their third or fourth IP banned at most.
I have a public facing website that is blocking about 500 obviously botted requests per second. About half are from residential proxies.
If I want to preserve the privacy of my users I will avoid using massive behavior capturing networks like Cloudflare. The is no world where giving them the tracking is better then just ensuring I anonymize my logs. If my users don't trust me; and are informed enough to understand what this service dose and doesn't cover they are just going to assume I can fingerprint them in some other way.
I'm seeing more and more organizations that I neither can identify nor pin down now using more and more cloudflare privacy offerings to "hide" their intentions.
I respect customer privacy. But I also need to know who is abusing my platforms as well. The balance here is very difficult to manage, now that we have entire agentic platforms capable of deploying highly technical capable "abuse" platforms.
This is slightly worse than Cloudflare's usual excellent writing.
But that aside - surely this won't help for websites with Google tracking code embedded, which are the sorts of sites that track you anyway?
SSL added and removed here :-)
To those missing it, it’s a reference to an internal NSA presentation that shown this sentence with an arrow at the boundary of google network and the internet.
You can google the sentence directly to find it.
If sharing your IP address with a website is a privacy concern we need to fix that problem, not hide the IP addresses
They really want to be MITM
Well played, CIA!
Has strong TOR (Onion Routing) feeling
> a typical client-server exchange creates a trail of user data, like the client’s IP address or TLS fingerprint. This level of visibility can be a burden.
Does Cloudflare's WAF (which relies on TLS Fingerprinting) stop working if OHTTP is enabled? If not, does this imply the client metadata is read and processed by Cloudflare but not passed on to the application server?
Next step: ClInternet: the World Wide Web by Cloudflare. :)
"Jesters do oft prove prophets".
- King Lear
"Ful ofte in game a sooth I have herd saye!" (Chaucer, The Cook's Tale)
They're already sort of inventing this by making the choice for everyone to block non-registered bots by default. (calling them "AI Training bots")
Like, bots are a huuuge problem but I am a huge believer in the case-by-case basis, and identity verification isn't a good default!
Self Service Relay https://oblivious.network/
The irony is that the majority of people that need this don’t have the cognitive time or skill to process and set it up for themselves. But the agents and bad actors like North Korean hackers would absolutely have the time and ability to implement and use it. Then you have the market for lemons problem - if requests coming from here are malicious most requests coming from here will be seen as malicious. Aka dark alleys earn their reputation over time.
Not sure how north korean hackers benefit from not knowing who is accessing their servers?
We have Cloudflare Tunnels to thank for this. I wish Cloudflare did more to stop malicious use of Cloudflare Tunnels.
I thought ohttp is opt-in. You have to participate their beta to enable the relay/gateway.
Same applies to Apple's Private Cloud Compute. A service provider has to join the program to avoid reading visitor's source IP.
It will handicap service provider's capability if I am not mistaken.
I think you misunderstand. This is for inbound traffic, not outbound.
Does any current proxy/tunnel/VPN software support OHTTP as a transport method?
What about browsers making general website requests to services that support it?
iCloud Private Relay (available on every macOS and iOS device in recent years) uses OHTTP to obscure your identity from sites you visit.
Pathetically, people probably won't even erase cookie, let alone JavaScript. To begin with, any websites are not designed to be viewable without js. There are countless ways to find fingerprints. It is impossible to prevent tracking anyway in current the internet.
It’s entirely possible if the application developers have made the choice to intentionally avoid tracking and tying personal data to user identity, which is exactly who this product is aimed at.