- King Lear
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!
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.
What about browsers making general website requests to services that support 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.
You can google the sentence directly to find it.
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?
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.
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.
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".
– WikipediaWhether they abide by that is another matter.
Also the NSA is a "signals intelligence" agency... Wouldn't the FBI be the local analog to the CIA? Or maybe the DHS?
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? :)
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?
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."
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?'.
Source: https://www.bbc.co.uk/news/business-37348016How 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?
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".
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.
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.
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.
But maybe I get privacy wrong.
I have a feeling that privacy is easier to protect if you just mix what you want to hide with a lot of garbage.
As I wrote, Cloudflare excel at marketing. And offers to consumers (as opposed to B2B).
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.
Although, that is still better than them having the source ip and the content.
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?)
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.
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.
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?
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.
There’s also room for a privacy-centric analytics offering
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
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.
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