Enabling privacy on the Internet with Oblivious HTTP

Businesses that provide these Internet services face tough challenges when deciding how to balance competing concerns around product usefulness versus maintaining privacy. Simply receiving end user data through the normal course of operating a service can expose businesses to significant compliance requirements and regulatory pressure, and these challenges only get harder as a service becomes more successful.

Fastly is already a trusted edge delivery provider for some of the largest brands on the Internet, and we continue to offer our customers new products and technologies to help them scale services while managing user privacy. We’re excited to announce the latest product in our privacy enablement portfolio — the Fastly OHTTP Relay, now in beta with availability for select partners. The Fastly OHTTP Relay is a component of the Oblivious HTTP architecture that allows you to receive critical request data from your end users without any of the identifying metadata that you don't need.

HTTP was not built for privacy

Simply receiving an HTTP request from an end user, absent any special added headers or identifying details included in the request body, inherently delivers metadata that may be used to distinctly identify or narrow down the online identity to an actual person. Browser details in headers such as User-Agent and Accept, along with network details such as AS and IP address, can be combined in order to pierce the veil of end user identity. Even if this request metadata isn't logged or sent to a data warehouse, it is still being sent by the end user and received by the service's origin — and it's a simple matter to start logging at a later date. Ultimately your customer is being asked to trust that you will be a good steward of their information, as well as any successor organization or government entity that inherits your collected data and who may not operate under your same principles.

Retooling an existing HTTP service to be inherently privacy respecting is possible, but it commonly suffers from a lack of standardization and repeatable practices. This can lead to increased engineering effort to both create and maintain the service, with the added potential for accidental leakage of sensitive information. It also places a higher burden on the provider of the HTTP service to explain their privacy preserving solution both to their customer and to industry observers in order to establish trust that it behaves as intended.

Having a standardized mechanism to send HTTP requests to API endpoints, while preserving end user privacy, can help overcome these hurdles. The emerging Oblivious HTTP standard is a mechanism that can be deployed for a variety of API-driven use cases, while enabling you to build repeatable, thoroughly tested and well understood services. This standard is still evolving, but already shows a lot of promise as a key building block technology to enable privacy preserving Internet services.

What does OHTTP actually do and how does it work?

Oblivious HTTP (OHTTP) is both a specification for message passing and a high level service architecture. When used in conjunction, this allows an HTTP service provider to receive messages from a special HTTP client at a standard HTTP origin without also receiving unneeded and unwanted request and network level metadata. The double-blinded nature of the OHTTP service is essential for enabling user privacy: one layer handles end user identifying metadata (the Relay) while another handles the end user's request data (the Gateway). These two layers communicate but do not collude.

The OHTTP architecture has four layers, outlined as:

1. OHTTP Client

The OHTTP Client is a special HTTP client which encapsulates (and encrypts) an HTTP request intended for the OHTTP Target, and sends it to the OHTTP Relay. In its current revision, OHTTP Clients are suited for communicating to specific, pre-configured and known OHTTP services because the encryption key and encapsulated request formats are unique to a given service and must be known ahead of time.

2. OHTTP Relay

The OHTTP Relay is the first of a pair of services which operate the double-blinded core of the OHTTP architecture.

It receives the encapsulated request directly from the OHTTP Client, along with the standard HTTP request headers and related network connection information. As a result, it inherently knows identifying details about the Client, which it removes before sending the request along to the OHTTP Gateway.

Because the encapsulated request is encrypted with a key it does not possess, the OHTTP Relay does not know what data the Client has sent to the Target.

3. OHTTP Gateway

The OHTTP Gateway is the second in the pair of double-blinded services that forms the core of the OHTTP architecture.

It receives the privatized version of the Client's request from the OHTTP Relay, and decrypts and de-encapsulates the inner request. It then forwards this request to the OHTTP Target.

Because the outer request has been privatized, the OHTTP Gateway does not know identifying metadata about the Client.

4. OHTTP Target

The OHTTP Target is a standard HTTP service which receives the Client's original encapsulated request in a de-encapsulated form, which functionally appears as a common HTTP request. It notably does not know any identifying information about the client or end user, except for the HTTP request headers permitted through the OHTTP Relay and the data the OHTTP Client inserted into the encapsulated request.

The OHTTP Target processes this request, doing work such as providing a JSON API response back to the Client (without having received or processed identifying information about the Client), which is then encapsulated by the Gateway and routed back through the OHTTP service stack.

How does Fastly help me deliver an OHTTP-enabled service?

It is technically feasible for the HTTP service provider to implement and operate every layer of the OHTTP architecture (client, relay, gateway and target). Each piece works in close coordination to deliver the OHTTP-enabled service, and so running them together makes a certain kind of sense. The use of OHTTP in this way would appear at a glance to deliver on its privacy preserving promise except that if any single entity were to operate the two double-blinded OHTTP services in conjunction (OHTTP Relay and Gateway), this would create a fundamental compromise in the ability for OHTTP to meet its privacy preserving goals. Not only does this create operational risks of trust breaking behavior, but even the appearance of a compromise in trust is anathema to privacy enablement services. 

While the critical request path would remain privacy enabled, the operator could readily perform side-channel operations to combine the pieces of information that only the Relay knows (Client request metadata and network details) with those that only the Gateway knows (the body of the encapsulated request), and thus effectively bypass the privacy protections afforded by the OHTTP architecture.

Even the perception of this capability, absent the actual steps to implement it, serves to erode user trust in the provider and the OHTTP-enabled service. Ultimately the end user needs to be able to trust both that the OHTTP specification is well designed and that the provider has  implemented its architecture in a way that will actually deliver on the promise of privacy preservation!

The OHTTP Relay is therefore ideally deployed not by the HTTP service provider themselves, but by using a trusted partner with a solid reputation for operating highly available services using a secure and scalable infrastructure. Fastly is an ideal partner for our customers who look to build privacy-preserving services and improve user experiences across the Internet.

OHTTP Relay by Fastly

Fastly has created an OHTTP Relay service which leverages our global edge compute platform for easy extensibility and rapid scaling to meet all of your service's needs. We can support a variety of OHTTP use cases, including:

• A mobile app that periodically sends crash logs to an API endpoint; often latency-insensitive and with larger payloads.

• A web browser that validates client requests against a bad-actors API before allowing the connection to be made; highly latency-sensitive, with very small payloads.

• Going beyond the core OHTTP spec to enable custom service logic such as anonymized log delivery, token authentication, and more.

Our first OHTTP-enabled service is Google Chrome's FLEDGE service, which at launch will exclusively utilize Fastly's OHTTP Relay to enable behavioral ads to be delivered k-anonymously and without utilizing third-party cookies. By operating this service, Fastly:

• Receives OHTTP requests from Google Chrome clients.

• Performs certain validations to ensure that these are actual OHTTP requests.

• Removes all HTTP headers not included on the allow list (initially Content-Type, Content-Length and Host).

• Passes the request to explicitly defined Google backends.

• Additionally, only service-level metrics are provided to Google. Google does not have access to configure the OHTTP Relay service or to view raw request information (including request logs).

Looking Ahead

The Fastly OHTTP Relay is available in beta now. If you're building or thinking about privacy enabled Internet services we would love to talk to you about how Fastly can help you build, operate and scale these services to help ensure that your user privacy practices are as strong as possible while still delivering the very best experience.