What to know
- Cloudflare launched a closed beta for a self-service OHTTP Gateway.
- Its former Privacy Gateway is now named OHTTP Relay.
- Relay and gateway need independent operation to preserve the intended boundary.
Two different roles in the request path
Cloudflare’s October 2 announcement introduces a closed beta for a self-service OHTTP Gateway and renames its existing Privacy Gateway as OHTTP Relay. Oblivious HTTP separates a relay forwarding encrypted requests from a gateway processing their contents. Cloudflare describes using its relay with a separately operated gateway, or its new gateway with a third-party relay, depending on the application’s architecture.
The product names now make the roles easier to distinguish. A gateway is not a replacement word for a relay, and deploying both under one observer would undermine the separation the design seeks. Closed beta status also limits what developers should infer about immediate access. The announcement establishes a new managed option, rather than universal availability.
Analysis: Privacy claims need a defined observer
A privacy architecture should explain what each participant can see. The useful question is whether any one party can connect the client’s network identity to the content of the request. Splitting those views can reduce exposure, but the design must preserve the split in operation, including logging and surrounding services.
Application content can also reveal identity independently of a network address. If a request carries a user’s account identifier, hiding the originating IP address does not make that account anonymous to the application. Teams should therefore describe the protection precisely and avoid presenting a network-privacy mechanism as a complete anonymity guarantee. That distinction follows from the design question, not from a claim that a particular deployed service is leaking data.
Practical implications: Draw the visibility map
Developers evaluating the beta can list the relay, gateway and application backend, their operators and the metadata each retains. They can then test requests and failure cases to confirm that the intended separation survives ordinary diagnostics. A rejected request can expose different information from a successful one, so the map needs to include error handling.
Performance and operational responsibility remain part of the decision. The application must understand how relay or gateway failure affects a user and which operator can investigate without reconstructing a combined identity record. Cloudflare’s new option may reduce the work of running a gateway, while leaving the privacy architecture’s requirements intact. The meaningful outcome is a service whose stated privacy boundary matches what its components actually observe. The beta provides infrastructure for that work; a complete application evaluation must still account for content, identifiers and logs throughout the request path.
The documented privacy promise should state the information it protects and the assumptions it relies on. Users can then understand a precise network-identity boundary without being asked to infer broader protection from the presence of a cryptographic protocol.
Sources & further reading
Factual statements are grounded in the linked material. Interpretation and illustrative examples are Byte Watchr analysis. Vendor claims are identified as claims, rather than independent testing.
The event date records the source announcement or documented operation. The coverage edition groups recent developments and is separate from the publication date. Actual publication is recorded above.
Corrections policy · About this byline
