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.
Five years later Mr Prince was doing a Master of Business Administration (MBA) at Harvard Business School, and the project was far from his mind, when he got an unexpected phone call from the US Department of Homeland Security asking him about the information he had gathered on attacks.
Mr Prince recalls: "They said 'do you have any idea how valuable the data you have is? Is there any way you would sell us that data?'.
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.
Well, their operations are (intended to be) foreign... But that hasn't stopped them from selling drugs to American to raise money for their operations.
Also the NSA is a "signals intelligence" agency... Wouldn't the FBI be the local analog to the CIA? Or maybe the DHS?
Well, the problem with that is then you have to deal with the legalities of the USA. What you do instead is have the UK (and a couple other eyes, up to five or eighteen) do the spying on Americans, and in exchange, the Americans will spy on the UK. All perfectly extra-legal.
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?
Cloudflare Proxy, which is required for their ddos protection - and which as I recall accounts for like half of internet traffic - handles TLS termination at CF servers.
When you capture traffic at internet backbones, which the NSA does (Room 641A), you don't get to middle-man the encrypted traffic. Cloudflare gets access to unencrypted traffic, because they act as the TLS termination.
Most companies take this trade-off because "we can trust cloudflare", or "the data isn't that important, and besides it's encrypted the rest of the way anyway."
I may be naive, but they offer a privacy service which adds a hop on the way. They don't control both their server and the third-party, and that is the whole point of the design, right?
How is that exactly what you would expert from a covert government operation?
Do we agree that the design goes through two hops, only one of which is controlled by Cloudflare? And that it is the whole point of the design?
>They don't control both their server and the third-party, and that is the whole point of the design, right?
Yeah I'm not sure what everyone's complaining about. The lack of criticism of anything specific about OHTTP makes me think it's just kneejerk "cloudflare = bad".
> makes me think it's just kneejerk "cloudflare = bad".
I mean, sure. There is that against BigTech all the time, and I understand where it comes from.
What I don't get is that... I don't know, I feel like it should be possible to be against the fact that there are monopolies and criticise them on the one hand, and on the other hand to actually have technical discussions about technical solutions. Here it feels like many comments denigrate Cloudflare without even understanding what the OHTTP gateway does.
For example:
- "Google sucks, they just optimise for profit like all BigTech and that makes it worse for everybody" -> criticises a monopolist entity, all good. No need to be constructive here, it's just sharing a feeling.
- "Android's security model is soooo bad because Android is developed by Google, you should use Linux on mobile it's a lot more secure" -> criticises a technical solution (Android's security model) in a completely uninformed manner, not good.
In other words, BigTech companies "suck" by being BigTech companies, but they do hire brilliant engineers and develop nice stuff (when they don't develop technology to screw us, that is), and I think it would be worth acknowledging that. Cloudflare does contribute a lot of cool stuff open source. One doesn't have to like that Cloudflare is as big as it is, but that's not a reason to say that what they open source is bad software.
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.
This separates who sees what. Cloudflare (or any OHTTP gateway) sees who talks to who, but can't see the content. The service sees the content but not who you are/your IP.
You can imagine a lot of threat models where who you talk to isn't sensitive, nor is "someone talked to them about X" but knowing both facts is a risk.
For a single transaction that's great. The problem is whene a large fraction of the internet is served by a single entity (say cloudflare), then that entity has information about what sites/customers were visited by a specific ip address, and which ip addresses visited a certain site/customer.
Although, that is still better than them having the source ip and the content.
If a human was manually reviewing your logs, maybe. But that isn't the problem. Your stream is already a pile of garbage amongst billions of other piles of garbage. Programs will find the keywords they are looking for no matter if they are looking in a big pile of garbage or small.
Many of those websites are hosted by big tech companies via their cloud offerings. These clouds have even developed software for reading files within the VMs they are hosting.
> 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. HPKE is a good choice to use for the inner layer.
OHTTP is designed for a relatively narrow use case: stateless requests where you don't want the gateway to be able to correlate multiple requests from the same client (i.e., it's not just about hiding the IP address).
A clear example of when this might be a good idea is DNS-over-HTTPS — you don't want the resolver being able to correlate multiple requests from the same client.
You _can_ try and do this with SOCKS5, however you need to be very careful to avoid sharing any state:
* You must use a new TCP connection for each request, with a new TLS and HTTP connection atop.
* You must ensure you do not use TLS Session Resumption or 0-RTT data.
* You must, to the maximum extent possible, be very conservative with what you send in the TLS ClientHello to avoid exposing fingerprinting data.
SOCKS5 is also unencrypted, and the request contains the destination: the hostname if the proxy resolves it, or the IP if the client resolved it itself (and ECH doesn't help here, since it only protects the SNI inside the TLS handshake that follows). With OHTTP, that's all inside the TLS connection to the relay.
OHTTP doesn't have the client sending up-front metadata about all the different encryption methods it supports to the gateway (it relies on the gateway to tell it what it supports, and the client just picks one); the gateway doesn't get to see any of the TLS fingerprinting surface (because that is only visible to the relay).
OHTTP also doesn't require there to be multiple new TCP connections made for every request (whereas with SOCKS5 you're looking at a new TCP connection from the client to the proxy, and from the proxy to the server, per request) — you can have a long-lived connection to the relay, and the relay can have a long-lived connection to the gateway (shared by many clients). That's a big latency win for applications like DNS-over-HTTPS.
The risks of key disclosure also differ between the two — with OHTTP, disclosure of the gateway key essentially means the relay can decrypt recorded traffic that used that key (as there is no forward secrecy), whereas disclosure of the client <-> relay and relay <-> gateway keys matters a lot less (because there is forward secrecy); with SOCKS5, you have forward secrecy via the end-to-end TLS connection.
For the use-case of a general-use proxy, work such as MASQUE provides a multi-hop approach to limit exposure to any single party, and that does provide an end-to-end TLS connection — but you with that you're back to exposing all the fingerprinting associated with it, though for a general use proxy you may also be sending session-specific data (like auth tokens) that clearly tie requests together anyway.
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
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.
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.
> I've never seen an actual CGNAT IP addresses from a consumer ISPs being shared by a legitimate user and a persistent abusive one.
If you work for an ISP you'll see it all the time. It's a constant fight to keep your subnet reputations high, which is hard when the subscribers don't care unless you shut off their service, but then your IP block still has a reputation issue to clean.
Isn't the point of residential proxies to spread traffic accross a large number of IPs to avoid "persistent abusive" traffic from any single address or subnet?
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.
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.
It adds some level of privacy without going as far as something like Tor. As a result, it's a lot faster than Tor, but a lot less private.
The "privacy" it adds is that it separates your IP from your request, so no one actor on the way knows "X requested Y". A server knows "X requested something", another one knows "someone requested Y".
Maybe you don't need it, but I don't see how this is slightly creepy.
> 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.
> 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
Lots of words about how site owners can enable this "thing". But is it true that they can toggle it off at any moment? How as a visitor can I know in advance, whether OHTTP is enabled for my request and prevent making it, if OHTTP is not available?
Yes, but that shifts the trust even moreso onto Apple, and now they know every site you visit AND can see all your unencrypted traffic from their servers, and can associate that traffic across multiple devices/accounts/IPs with it.
Collusion between the relay and gateway is exactly the situation they warn breaks the privacy features of OHTTP.
And while some might think "well Apple controls the whole OS, they can always spy on you"... yes, but I'm operating under the assumption that they're not currently doing this, and that collecting data at the relay level may be easier/more desirable/discrete for them.
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.
I think an issue is that with such design, you want to "hide in the crowd". If you add a hop for your friends, then the third-party service knows that whoever connects from your server is one of your friends and it somehow defeats the purpose of the system, right?
> 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.
"For example, Flo Health uses OHTTP for their app's Anonymous Mode, and Apple's Private Cloud Compute uses OHTTP to disassociate AI inference requests from user identities."
"While most of the PCC system specifications are public, compiled binaries add a layer of opaqueness. There are no reproducible builds, and there are no symbols within those binaries, creating potential discrepancies between the specification and what is shipped to the user."
"Researchers have previously opened other proprietary Apple interfaces, such as AirDrop, Apple Watch, iCloud Private Relay, satellite communication, and more (Stute et al., 2019; Rollshausen et al., 2025; Kiesel and Classen, 2025; Classen et al., 2025). These works repeatedly show that, even though Apple makes significant efforts to secure its systems and add privacy features, the lack of public research leads to trivial mistakes that cause severe shortcomings in user privacy and security."
It's literally not MITM because they can't see the ciphertext, and specifically went out of their way to prevent themselves from being able to decrypt it (ie. you can't set up an OHTTP service where both hops are cloudflare).
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.
Is the DHS story not widely known?
Source: https://www.bbc.co.uk/news/business-37348016first thing i thought of. cloudflare is like the most successful widely scaled man in the middle attacker who may or may not be attacking of all time
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.
Well, their operations are (intended to be) foreign... But that hasn't stopped them from selling drugs to American to raise money for their operations.
Also the NSA is a "signals intelligence" agency... Wouldn't the FBI be the local analog to the CIA? Or maybe the DHS?
Two branches from the same trunk with their leaves touching. The boundaries are pure show.
Well, the problem with that is then you have to deal with the legalities of the USA. What you do instead is have the UK (and a couple other eyes, up to five or eighteen) do the spying on Americans, and in exchange, the Americans will spy on the UK. All perfectly extra-legal.
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.
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?
Cloudflare Proxy, which is required for their ddos protection - and which as I recall accounts for like half of internet traffic - handles TLS termination at CF servers.
When you capture traffic at internet backbones, which the NSA does (Room 641A), you don't get to middle-man the encrypted traffic. Cloudflare gets access to unencrypted traffic, because they act as the TLS termination.
Most companies take this trade-off because "we can trust cloudflare", or "the data isn't that important, and besides it's encrypted the rest of the way anyway."
I may be naive, but they offer a privacy service which adds a hop on the way. They don't control both their server and the third-party, and that is the whole point of the design, right?
How is that exactly what you would expert from a covert government operation?
Do we agree that the design goes through two hops, only one of which is controlled by Cloudflare? And that it is the whole point of the design?
>They don't control both their server and the third-party, and that is the whole point of the design, right?
Yeah I'm not sure what everyone's complaining about. The lack of criticism of anything specific about OHTTP makes me think it's just kneejerk "cloudflare = bad".
> makes me think it's just kneejerk "cloudflare = bad".
I mean, sure. There is that against BigTech all the time, and I understand where it comes from.
What I don't get is that... I don't know, I feel like it should be possible to be against the fact that there are monopolies and criticise them on the one hand, and on the other hand to actually have technical discussions about technical solutions. Here it feels like many comments denigrate Cloudflare without even understanding what the OHTTP gateway does.
For example:
- "Google sucks, they just optimise for profit like all BigTech and that makes it worse for everybody" -> criticises a monopolist entity, all good. No need to be constructive here, it's just sharing a feeling.
- "Android's security model is soooo bad because Android is developed by Google, you should use Linux on mobile it's a lot more secure" -> criticises a technical solution (Android's security model) in a completely uninformed manner, not good.
In other words, BigTech companies "suck" by being BigTech companies, but they do hire brilliant engineers and develop nice stuff (when they don't develop technology to screw us, that is), and I think it would be worth acknowledging that. Cloudflare does contribute a lot of cool stuff open source. One doesn't have to like that Cloudflare is as big as it is, but that's not a reason to say that what they open source is bad software.
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.
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.
This separates who sees what. Cloudflare (or any OHTTP gateway) sees who talks to who, but can't see the content. The service sees the content but not who you are/your IP.
You can imagine a lot of threat models where who you talk to isn't sensitive, nor is "someone talked to them about X" but knowing both facts is a risk.
For a single transaction that's great. The problem is whene a large fraction of the internet is served by a single entity (say cloudflare), then that entity has information about what sites/customers were visited by a specific ip address, and which ip addresses visited a certain site/customer.
Although, that is still better than them having the source ip and the content.
There are other CNDs, and Cloudflare isn't event the largest one, it has best marketing and free solutions.
Cloudflare provides so much more than just CDN, and in a very nice package
As do others, they had to because CDN is not that good source of income nowadays, so most went into other offerings that are more profitable.
As I wrote, Cloudflare excel at marketing. And offers to consumers (as opposed to B2B).
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.
If a human was manually reviewing your logs, maybe. But that isn't the problem. Your stream is already a pile of garbage amongst billions of other piles of garbage. Programs will find the keywords they are looking for no matter if they are looking in a big pile of garbage or small.
Many of those websites are hosted by big tech companies via their cloud offerings. These clouds have even developed software for reading files within the VMs they are hosting.
Why not both? When browsing Microsoft, give your IP to Cloudflare. When browsing Pouet, give your IP to Pouet.
> 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. HPKE is a good choice to use for the inner layer.
OHTTP is designed for a relatively narrow use case: stateless requests where you don't want the gateway to be able to correlate multiple requests from the same client (i.e., it's not just about hiding the IP address).
A clear example of when this might be a good idea is DNS-over-HTTPS — you don't want the resolver being able to correlate multiple requests from the same client.
You _can_ try and do this with SOCKS5, however you need to be very careful to avoid sharing any state:
* You must use a new TCP connection for each request, with a new TLS and HTTP connection atop.
* You must ensure you do not use TLS Session Resumption or 0-RTT data.
* You must, to the maximum extent possible, be very conservative with what you send in the TLS ClientHello to avoid exposing fingerprinting data.
SOCKS5 is also unencrypted, and the request contains the destination: the hostname if the proxy resolves it, or the IP if the client resolved it itself (and ECH doesn't help here, since it only protects the SNI inside the TLS handshake that follows). With OHTTP, that's all inside the TLS connection to the relay.
OHTTP doesn't have the client sending up-front metadata about all the different encryption methods it supports to the gateway (it relies on the gateway to tell it what it supports, and the client just picks one); the gateway doesn't get to see any of the TLS fingerprinting surface (because that is only visible to the relay).
OHTTP also doesn't require there to be multiple new TCP connections made for every request (whereas with SOCKS5 you're looking at a new TCP connection from the client to the proxy, and from the proxy to the server, per request) — you can have a long-lived connection to the relay, and the relay can have a long-lived connection to the gateway (shared by many clients). That's a big latency win for applications like DNS-over-HTTPS.
The risks of key disclosure also differ between the two — with OHTTP, disclosure of the gateway key essentially means the relay can decrypt recorded traffic that used that key (as there is no forward secrecy), whereas disclosure of the client <-> relay and relay <-> gateway keys matters a lot less (because there is forward secrecy); with SOCKS5, you have forward secrecy via the end-to-end TLS connection.
For the use-case of a general-use proxy, work such as MASQUE provides a multi-hop approach to limit exposure to any single party, and that does provide an end-to-end TLS connection — but you with that you're back to exposing all the fingerprinting associated with it, though for a general use proxy you may also be sending session-specific data (like auth tokens) that clearly tie requests together anyway.
I was at Thibault's talk when he explained the OHTTP this summer, for those interested: https://passthesalt.ubicast.tv/videos/2026-oblivious-http-wh...
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
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.
But the whole point of this gateway is that Cloudflare doesn't learn "who makes the request" and "what they request", only one of them, right?
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?
“Well you see, it’s better because of the fact the _we_ do it!” - Cloudflare, probably.
I guess the point is that a site owner can opt-out from the possibility to locate end-users. I think the use case is fair but not that common.
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.
> I've never seen an actual CGNAT IP addresses from a consumer ISPs being shared by a legitimate user and a persistent abusive one.
If you work for an ISP you'll see it all the time. It's a constant fight to keep your subnet reputations high, which is hard when the subscribers don't care unless you shut off their service, but then your IP block still has a reputation issue to clean.
Isn't the point of residential proxies to spread traffic accross a large number of IPs to avoid "persistent abusive" traffic from any single address or subnet?
Banning a couple of faraway datacenters by ASN (and thus IP address) took out like >80% of the bot traffic to a site I help. They won't "just".
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.
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.
Im at a loss as to what I or anyone else would actually use this for. But it is slightly creepy. Ill give it that.
It adds some level of privacy without going as far as something like Tor. As a result, it's a lot faster than Tor, but a lot less private.
The "privacy" it adds is that it separates your IP from your request, so no one actor on the way knows "X requested Y". A server knows "X requested something", another one knows "someone requested Y".
Maybe you don't need it, but I don't see how this is slightly creepy.
yeah i’m genuinely interested if there is an actually service that uses this today
OHTTP is a neat split: the relay learns who you are, the gateway learns what you ask, and neither gets both.
> 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?
> 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
Agreed, but hopefully this gives people who would pay for it a way to do it and then, either by scale or by popularity, it becomes de facto.
Lots of words about how site owners can enable this "thing". But is it true that they can toggle it off at any moment? How as a visitor can I know in advance, whether OHTTP is enabled for my request and prevent making it, if OHTTP is not available?
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?
Cloudflare is like the systemd of the internet
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.
Yes, but that shifts the trust even moreso onto Apple, and now they know every site you visit AND can see all your unencrypted traffic from their servers, and can associate that traffic across multiple devices/accounts/IPs with it.
Collusion between the relay and gateway is exactly the situation they warn breaks the privacy features of OHTTP.
And while some might think "well Apple controls the whole OS, they can always spy on you"... yes, but I'm operating under the assumption that they're not currently doing this, and that collecting data at the relay level may be easier/more desirable/discrete for them.
If sharing your IP address with a website is a privacy concern we need to fix that problem, not hide the IP addresses
[dead]
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.
Has strong TOR (Onion Routing) feeling
how can i run this for my friends and me selfhosted? is there a ohttp server?
I think an issue is that with such design, you want to "hide in the crowd". If you add a hop for your friends, then the third-party service knows that whoever connects from your server is one of your friends and it somehow defeats the purpose of the system, right?
OHTTP is like a two-hop Tor circuit with a predetermined gateway, so if they can pin you as the first hop it's similar
Tor exists for that, extend support to it.
> 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?
[flagged]
Next step: ClInternet: the World Wide Web by Cloudflare. :)
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!
"Jesters do oft prove prophets".
- King Lear
"Ful ofte in game a sooth I have herd saye!" (Chaucer, The Cook's Tale)
Bots are going to love this.
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?
I think you misunderstand. This is for inbound traffic, not outbound.
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.
"For example, Flo Health uses OHTTP for their app's Anonymous Mode, and Apple's Private Cloud Compute uses OHTTP to disassociate AI inference requests from user identities."
Flo Health
https://www.ftc.gov/news-events/news/press-releases/2021/06/...
https://www.ftc.gov/enforcement/cases-proceedings/1923133/fl...
https://www.ftc.gov/system/files/documents/cases/192_3133_fl...
https://www.cbsnews.com/news/facebook-reportedly-received-se...
https://www.labaton.com/cases/frasco-v-flo-health-inc
https://natlawreview.com/article/jury-finds-meta-liable-coll...
1789644223 | Frasco v. Flo Health 3:21-cv-00757-JD Wiretap liability, Meta Platforms [pdf] | https://www.govinfo.gov/content/pkg/USCOURTS-cand-3_21-cv-00... | https://news.ycombinator.com/item?id=49739197 | 0 comments
https://www.cbc.ca/news/canada/british-columbia/flo-health-p...
Apple Private Cloud Compute
Unlocking Apple's Private Cloud Compute: An Analysis of Privacy-Preserving Artificial Intelligence
Proceedings of the 19th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec 2026)
https://arxiv.org/html/2605.24239v1
"While most of the PCC system specifications are public, compiled binaries add a layer of opaqueness. There are no reproducible builds, and there are no symbols within those binaries, creating potential discrepancies between the specification and what is shipped to the user."
"Researchers have previously opened other proprietary Apple interfaces, such as AirDrop, Apple Watch, iCloud Private Relay, satellite communication, and more (Stute et al., 2019; Rollshausen et al., 2025; Kiesel and Classen, 2025; Classen et al., 2025). These works repeatedly show that, even though Apple makes significant efforts to secure its systems and add privacy features, the lack of public research leads to trivial mistakes that cause severe shortcomings in user privacy and security."
For example, iCloud Private Relay
https://www.bloomberglaw.com/api/v1/public/download/X2K9PC2C...
1744651630 | macOS Sends Locally-Served DNS Zones to iCloud Private Relay | https://developer.apple.com/forums/thread/780720 | https://news.ycombinator.com/item?id=43683780 | 1 comment
1776183767 | iCloud Private Relay is not secure | https://webrtchacks.com/apples-not-so-private-relay-fails-wi... | https://news.ycombinator.com/item?id=47767673 | 1 comment
1785886306 | IP and DNS Leaks in WebKit Affecting Proxy Browsers and iCloud Private Relay | https://mysk.blog/2026/08/04/webkit-proxy-icloud-private-rel... | https://news.ycombinator.com/item?id=49176697 | 43 comments
1785949588 | iCloud Private Relay leaks real IP addresses | https://proton.me/blog/icloud-private-relay-ip-leak | https://news.ycombinator.com/item?id=49185697 | 1 comment
1785952050 | Apple's 'Private Relay' Is Exposing Users' Real IP Addresses | https://www.404media.co/apples-private-relay-is-exposing-use... | https://news.ycombinator.com/item?id=49186320 | 1 comment
Well played, CIA!
I’m honestly puzzled as to who the customer is that they built this for.
They really want to be MITM
It's literally not MITM because they can't see the ciphertext, and specifically went out of their way to prevent themselves from being able to decrypt it (ie. you can't set up an OHTTP service where both hops are cloudflare).
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.
[flagged]
[flagged]