Unfortunately this will never be fixed. It's not a technical problem. They refuse to ship software licensed under GPL v3, and bash 3.2 is the final GPL v2 version.
The Relay doesn't know the requested URL or the request body -- but it does know the next-hop destination (the OHTTP Gateway), and by virtue of the way most OHTTP services are currently deployed this tells you the destination service. It does not tell you the specific details of what is being asked for / returned by that service.
These services are implemented in different parts of Fastly's production stack, but they share the same global infrastructure footprint and a lot of the same people/teams are involved with both.
Yes, that's true. However in practice most deployments that I've worked on are a relay which maps all requests to a gateway which maps all requests to a target. It's not an inherent property of the protocol, and I expect that to evolve over time.
Without going into trust / motivation / etc. of various organizations, OHTTP is not used for general purpose web browsing. This Fastly service is used by Mozilla in conjunction with their own origins, not to random origins on the Internet.
This service with Mozilla utilizes OHTTP, whereas iCloud Private Relay uses MASQUE.
OHTTP is ideally suited for privacy enablement of APIs, whereas MASQUE is more for general purpose traffic.
OHTTP has similarities to MASQUE in that it uses a two hop proxy design where each proxy only knows part of the total requestor / request information. And in both cases these proxies must be operated by separate entities that do not collude.
However, the key difference is that in OHTTP the end destination is known, because there is a 1-1-1 mapping between OHTTP Relay -> OHTTP Gateway -> Target. This could become more generalized in future revisions to OHTTP, but right now it's all hardcoded behavior.
For more about OHTTP at Fastly, I wrote a blog post a while back at [1]. There is also the IETF draft spec at [2].
Appreciate your questions and feedback. There's nothing wrong with some healthy skepticism. Ultimately this solution depends on the tech and implementation but it also requires a degree of user trust. I've been happy to see both Fastly and Google being pretty transparent about what's going on and how it works, in order to start establishing that trust.
I can't speak to your points about Google specifically, but I have appreciated in my interactions with the Privacy Sandbox team that they are putting a lot of energy in to delivering these services while also respecting user privacy.
On the Fastly side, I see an opportunity to deliver OHTTP services for a bunch of additional use cases and to other customers. I think this could be a powerful tool to enable privacy for all sorts of things, like metrics and log collection and other kinds of API access. The spec right now needs the client to know various things which requires a tight coupling between client -> relay -> gateway -> target, but I think that there are ways that could be adjusted in future revisions. And not all of the opportunities that I'm exploring are for commercial entities, to your point about NGOs.
I'm also working on some other privacy enablement services, like Fastly Privacy Proxy (which is one of the underlying providers for Apple's iCloud Private Relay) and some un-announced things. Between these various technologies I think that Fastly can help to raise the level across the industry for end user privacy.
Ultimately we are a business and we like making money. I think we can do that in this space by delivering real value to our customers and their end users via these building block services that help them to build privacy enabled products. I'm hopeful that, as we explore more opportunities in this space and OHTTP adoption increases, user trust continues to be built in both the OHTTP technology and Fastly's privacy enablement services.
Yes, I'm working on bringing Fastly's OHTTP Relay to GA, which will allow us to offer it to more customers. That's ultimately more of a pricing and business process thing than any additional technical work. The implementation is feature complete at this point. Planning for that in Q2 (mid-April if all goes well).
I'm not (currently) planning to support customer self-service for this, because I anticipate that most customers may want:
1. Fastly to operate the OHTTP relay service, so that they can clearly state that they can't interfere with its operation to their end users.
2. Customization around business logic. We do plan to re-use the core service implementation across customers, but I've found with the initial implementations that there is an additional layer of business logic that's valuable (things like specifically which headers to strip / pass, using backend API key, verifying a client shared secret, etc.).
However, if it becomes apparent that self-service is desirable here, I'll definitely consider that. There would be a bit more work on the engineering side to enable that.
If you might be interested in that service, I'm happy to discuss: <hn username> @ fastly dot com
OHTTP does require that the parties don't collude, which is why Google has engaged Fastly to run the relay service (which knows end user identifying data) and are themselves running the gateway service (which knows the end user request body).
Part of the contract terms include not delivering log data to Google for this service, among other things that help ensure that this separation of knowledge is upheld.
More about Oblivious HTTP and what Fastly is doing here is in a blog post that I wrote [1]. I wrote the OHTTP relay service for Fastly and was heavily involved in this deal.
Some points about how the service operates:
- Fastly does not receive your Chrome browsing history by virtue of running this service, because there is not a 1-1 mapping between URLs browsed and OHTTP requests made. We also cannot view the encapsulated request (which is passed to Google).
- Fastly does not capture access logs for this service, and no logs are sent to Google. There is only access to service-level metrics.
- Google does not have access to modify the configuration of this Fastly service, and does not own the domain or TLS key associated with it.
So Yoel posted a link to an article published in Salon titled "Student-teacher sex: When is it OK?" which discusses the broad strokes of a legal case and is in no way advocating on behalf of pedophiles. In fact, the case discussed could not be pedophilic because the student in question was 18.
In your mind this means that Yoel maybe doesn't deserve to be threatened, but still he should have expected this?
So how about for yourself? You posted a link to a link to an innocuous article titled "Student-teacher sex: When is it OK?" What were you thinking?