What is Oblivious HTTP (OHTTP)? Who sees what, and what it leaves exposed

The Morse teamPublished October 31, 20268 min read

Oblivious HTTP (OHTTP) is an internet standard, RFC 9458, for sending an encrypted web request through a relay run by a separate company, so the relay learns your IP address but not what you asked, and the server that decrypts the request learns what you asked but not your IP address. As of October 2026, Apple, Meta, Google, Brave, and Mozilla use it, and Cloudflare and Fastly sell relays for it.

We read RFC 9458 and its companion RFC 9540, Apple's Private Cloud Compute security guide, Brave's October 15, 2026 post on Leo's encrypted chats, Meta's post on WhatsApp's Private Processing, Google's Safe Browsing and Chrome pages, and Cloudflare's and Fastly's relay docs, all on October 31, 2026. RFC 9458 lists most of its own limits, and we quote them below. In plain OHTTP the gateway reads your whole request, so every AI deployment we read wraps the request a second time for an attested enclave.

How does Oblivious HTTP work?

Your app encrypts each request to the gateway's public key and hands it to a relay that can't open it. RFC 9458, published in January 2024 on the IETF's Standards Track by authors from Mozilla and Cloudflare, lays out the steps. The client builds an HTTP request, encodes it as a binary HTTP message, and seals it with Hybrid Public Key Encryption (HPKE). It sends the sealed request to the relay as a POST. The relay forwards it to the gateway, which "removes the HPKE protection to obtain an HTTP request," gets an answer, and seals the response for the trip back (RFC 9458).

Clients "MUST generate a new HPKE context for every request," so each request is sealed on its own (RFC 9458).

The client has to get the gateway's key first, and RFC 9458 leaves that to each app: "A specific method for a Client to acquire configurations is not included in this specification." RFC 9540, from February 2024, adds one way. A service can advertise OHTTP in its DNS records and serve its key at the well-known path ohttp-gateway, which means the gateway and target "need to be located on the same host" (RFC 9540).

A gateway that gave one person a unique key could pick out that person's requests, and RFC 9458 says "Client privacy depends on having each configuration used by many other Clients" (RFC 9458). Apple answers this by publishing the keys it hands out to a transparency log, so researchers can check "that only one set of keys is in use in a given time period" (Apple).

What is an OHTTP relay?

An OHTTP relay is the forwarding service in the middle, which sees where a request comes from but can't read it. The RFC defines it as "an intermediary that forwards Encapsulated Requests and Responses between Clients and a single Oblivious Gateway Resource." It "MUST NOT add information when forwarding requests that might be used to identify Clients," and "SHOULD NOT forward unknown fields" (RFC 9458).

Two relays are sold as products. Cloudflare's OHTTP Relay, "formerly Privacy Gateway," says the relay "learns nothing of the application data, beyond the length of the encrypted message and the server the client is interacting with" (Cloudflare). Fastly's Oblivious HTTP Relay "strips all request headers except those that are required," and Fastly says it "does not have the keys to decrypt messages" (Fastly).

Two of the products named "gateway" are relays. Cloudflare's relay used to be called Privacy Gateway, and Brave writes that "despite its name, the Brave AI Gateway plays OHTTP's relay role" (Brave).

What does the OHTTP gateway see?

The OHTTP gateway sees your whole request, decrypted. The RFC says gateways "learn only the Oblivious Relay Resource and the decrypted request" (RFC 9458). Google's Chrome team wrote in 2023 that its k-anonymity server and gateway "are unaware of the user's identity but can see the content of the request" (Chrome). Cloudflare lists what its relay customers receive, starting with "The application content of requests" (Cloudflare).

The gateway's key is also a single point of failure. OHTTP "does not provide forward secrecy for either requests or responses during the lifetime of the key configuration," and a stolen gateway key "could allow an attacker to recover the plaintext of all requests sent toward affected keys." The RFC adds that using a stolen key also needs the relay's cooperation or broken TLS (RFC 9458).

Who uses Oblivious HTTP, and who can read the request?

Apple, Meta, Brave, Google, and Flo Health use it, and of those only the three AI deployments keep the request from the company running the gateway. Each row comes from the operator's own pages, read October 31, 2026.

Firefox adopted Fastly as its relay in 2023. Fastly's announcement of October 12, 2023 says "Fastly never knows what information is in the request itself" (Fastly).

The three AI deployments all add a layer that OHTTP doesn't supply. Apple's device validates each server's attestation and wraps the request's key for the nodes it accepts, while the gateway gets only "a small amount of metadata" for routing (Apple). Meta also opens an attested TLS session (RA-TLS) between the device and the TEE (Meta). Brave puts the gateway itself inside the TEE; Leo's models, plans, and prices are in Duck.ai vs Lumo vs Brave Leo. In each case a trusted execution environment keeps the words from the company, and OHTTP keeps the sender from it. Apple and Meta also authenticate requests with anonymous credentials instead of an account. Apple explains why: "requiring an account or device credential when submitting a request would tie requests to an identity," so its tokens use RSA Blind Signatures, as in Privacy Pass (Apple). We cover the rest of Apple's design in is Apple Intelligence private.

What doesn't Oblivious HTTP hide?

OHTTP hides your IP address from the server and your words from the relay. RFC 9458 itself names most of what it leaves open:

• What you ask, from whoever runs the gateway. Unless the gateway sits in an attested enclave, as in the AI rows above, the operator reads every word.
• Anything inside the request that names you. "Cookies are the most obvious feature that might be used to correlate requests, but any identity information and authentication credentials might have the same effect" (RFC 9458). Sign in, and the gateway knows it's you again.
• A conversation as a whole. OHTTP removes linkage at the transport layer, "which is only useful for an application that does not carry state between requests." Requests stay "linkable by their content" (RFC 9458). A chat app has to resend the context each time. Brave's browser, on "each turn," generates "a fresh one-time key and re-encrypts the entire conversation history" (Brave).
• Your IP address, from the relay. Cloudflare's relay records "the connecting device's IP address," the service you use, your browser type and operating system, and the timestamp, and keeps those logs for "approximately 124 days" (Cloudflare). The IP address is one item on a longer list, which we set out in what data AI chatbots collect.
• Two operators working together. The relay "cannot be operated by the same entity as the Oblivious Gateway Resource" (RFC 9458). Apple wrote in 2024 that an attacker "would have to compromise both the third-party relay and our load balancer" (Apple).
• Timing and size. HTTPS "does not prevent traffic analysis," and the timing of messages "could be used to match messages that are forwarded by the relay." The RFC suggests padding and leaves traffic analysis "outside the scope" of the standard (RFC 9458).

How Morse separates who you are from what you ask

OHTTP gives who you are to one company and what you ask to another, but someone still reads the request, and a signed-in account puts your name back on it. Morse's modes handle the two halves separately. Anonymous mode keeps who you are from the model provider, and E2EE keeps what you ask from everyone but an enclave your browser has verified.

• Anonymous, to ask GPT, Claude, or Gemini without the provider knowing it's you. Our proxy removes your account, email, and IP address and sends the message under Morse's own account. The provider sees the message without knowing it's you, and may keep it for a limited time to check for abuse, under its own policy. Morse strips who you are but not what you write, so leave out names and details you'd rather keep to yourself. We compare this with logging out and VPNs in anonymous ChatGPT.
• E2EE, for a question no company should read. Your browser checks the enclave's hardware attestation itself, then encrypts the message so only that enclave can read it. Our servers pass along ciphertext they can't read, and only your browser can read the reply. Brave says its own gateway runs that check today; on Morse it runs in your browser before anything leaves your device. The guarantee depends on the enclave hardware and attestation working as designed, and how to verify AI enclave attestation walks through what the check proves.
• Private, when the host may read the request but mustn't keep it. Open-weight models like DeepSeek, Kimi, and GLM run here. Morse has zero data retention agreements with its inference, search, and other providers, so they keep nothing. Where a provider confirms zero retention on each reply, Morse checks it and refuses a reply that doesn't.

In every mode, your chat history is stored only in your browser, encrypted, not on Morse's servers, and our servers don't keep messages or log what you write. Morse doesn't train AI on your chats, sell your data, or show ads.

Try a chat from the Morse home page without an account, or start free with no card. E2EE chats come with Pro, at $19 a month.