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.
I wonder why they haven’t fixed it yet by removing bash and the other GPL-licensed tools. Even if they currently need one to boot the system, they have the resources to change that.
“NSMB (Netsmb and SMBFS) is a family of in-kernel SMB client implementations in BSD operating systems. It was first contributed to FreeBSD 4.4 by Boris Popov, and is now found in a wide range of other BSD systems including NetBSD and macOS“
“The upcoming release of Mac OS X 10.7 Lion Server will remove the formerly bundled open source Samba software and replace it with Apple's own tools for Windows file sharing and network directory services”
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.
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].
>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.
So the Relay knows the requested URL? That’s not masked by the client?
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.
OHTTP encapsulates a complete request, so the 1-1-1 mapping isn't right. The target can be any resource, but it generally should be on the same host/origin as the gateway. The gateway sees the request and the response, so there are very few cases where you would trust it to handle requests for any URL.
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.
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.
First, thanks for the answers - both this comment and the other in the thread. HN shines again when it comes to access to the sources of information.
Second, as I said in another comment, I'm not a chrome user and I'm asking more for personal entertainment. However, I think that I'm asking questions that everyone not in the space would ask looking from the outside. Hopefully, your answers are of use for someone else.
Third, my personal biased opinion is that this will not resolve any of the issues surrounding Google and the online tracking. I lost my personal trust in Google many years ago and things haven't change since then. Even this initiative which is supposed to underpin the privacy and the choice of the user is provided as a corporate project with Google choosing who decides on the allowed urls, the ohp provider, and everything else about the parameters of the "deal". As I said, I cannot comment on the cryptography, but anything else in the whole story does not provide me with the confidence that the user choice has been uphold as a value. I doubt that anyone will have their opinion change from all of this.
Possible measures which could've demonstrated some transparency could've been if Google wasn't the only authority on the allow list, if people could choose the ohp provider, if the authority was granted to a ngo with transparent rules and decision taking process, and independent oversight...
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.
