The OHTTP provider.
One side. Never both.
Oblivious HTTP only works when someone trustworthy holds one side of the path. ohttp.io exists to be that someone, a provider of OHTTP infrastructure, starting with the relay, with a hard rule that keeps us honest.
Privacy needs a
third party.
Every HTTP request carries two kinds of information: what you're asking for, and who's asking. Most of the web lets one server see both. Oblivious HTTP (RFC 9458) fixes this by splitting the path, and its promise is simple: a relay knows who you are but never what you're doing; a gateway knows what you're doing but never who you are.
The catch is structural: the RFC is explicit that no single entity may hold both sides of the same flow, or the privacy guarantee collapses. Someone has to be the independent party. That is a business model problem disguised as a protocol requirement, and it's the problem ohttp.io exists to solve.
We are an Oblivious HTTP provider, not a relay company. We launch with the relay; a gateway service follows. Which side of the flow we run depends on what a customer needs, what will never change is the rule that makes either one trustworthy: no customer may use ohttp.io for both ends of a flow. Relay customers pair us with their own or a third party's gateway; gateway customers will pair us with an independent relay. The unlinkability the protocol promises stays intact, commercially enforced, not just politely suggested.
What we promise,
in writing.
Zero logging
We retain nothing beyond billing records. Client IP addresses, connection metadata, timing, ciphertext bodies, discarded the moment a request completes. There is no log to subpoena, breach, or mine.
No collusion, legally
We are legally unconnected to every other relay and gateway operator: no shared ownership, no investors in common, no partnerships, no data-sharing agreements. Collusion resistance is a corporate fact, not a promise.
One side, never both
A customer may use ohttp.io as their relay or, when it launches, as their gateway. Never both. We enforce the separation RFC 9458 §6 requires at the contract level.
Structural blindness
On the relay, payloads are HPKE ciphertext on our wires by construction, not by policy. We strip unknown header fields and never add Forwarded or Via metadata, per RFC 9458 §6.2.
Standards-first
We track the IETF specs, RFC 9458, Binary HTTP, HPKE, chunked OHTTP, Privacy Pass, service-binding discovery, and interoperate with every conformant implementation rather than building a walled garden.
Honest limits
OHTTP gives unlinkability, not absolute anonymity. We publish what we can and cannot see, and we'll tell you when OHTTP is the wrong tool for your problem.
GDPR, by architecture
Compliance here isn't a policy we enforce, it's a property of the design. The relay never sees request payloads and retains nothing beyond billing records, so most of what GDPR regulates never touches us. What little we do process is set out in our privacy policy.
The people behind
the promise.
A privacy service is only as trustworthy as the people who run it. These are ours.
Keith Wilson
Keith founded ohttp.io with a simple idea: good privacy technology is only useful if people can actually deploy it. He has worked with internet technology for more than 25 years, from the early commercial web through to modern cloud, security, and edge infrastructure, including a decade at Akamai and working directly with some of the UK's largest enterprises. Along the way he founded a managed service provider that has helped countless businesses run their infrastructure. That experience shaped ohttp.io: turning Oblivious HTTP from an emerging privacy protocol into practical infrastructure organisations can confidently deploy. He leads the company's direction across the relay service available today and the gateway platform being built next.
Lucy Hume
Details to be confirmed.
Where we're headed.
Now, the relay, generally available. Dedicated relay endpoints for any conformant gateway, chunked OHTTP and Privacy Pass support, served from a global edge over HTTP/1.1 through HTTP/3.
Next, the gateway. A managed Oblivious Gateway service: hosted decapsulation, HPKE key management and rotation, and vertical gateways for anonymous inference and telemetry. Available only to customers whose relay is operated elsewhere - the one-side rule applies from day one.
Later, ecosystem tooling. Conformance test suites, key-config consistency checking, and discovery tooling for RFC 9540 service-binding records.
Verifiable, not just promised. Public status page, SLA-backed paid plans, a versioned RFC 9458 §6.2 conformance statement, and regular transparency reporting, because a service whose product is trust should have to prove it.
Building something that
shouldn't know its users?
We'd like to hear about it. Gateway operators, client developers, and privacy researchers all welcome.