21–30 of 39 posts
So, who can have access to the data that fastly has access to? Because it seems that url by url the chrome browser will send the entire history to a third party.
The relay doesn't learn the content because it's not encrypted for it. The target receives the payload from the relay, so it doesn't know its IP, and everything the relayed removed.
So, who can have access to the data that fastly has access to? Because it seems that url by url the chrome browser will send the entire history to a third party.
It's similar to Anonymized DNS. The relay doesn't learn the content because it's not encrypted for it. The target receives the payload from the relay, so it doesn't know its IP, and everything the relayed removed.
Separately from this OHTTP product, we're working on that as well.
google uses this to further gatekeep the online advertising industry since non-google networks have to get Google's permission from the k anonymity server to show their ads. maybe someday someone will sue to break up this mess
The justice department is also suing them in (what I believe) is a separate lawsuit [0].
I'm actually connected to one of the lawyers consulting on the case. I could reach out and explain to her if I understood the details (which I don't in this particular instance).
[0] https://www.justice.gov/opa/pr/justice-department-sues-googl...
So, who can have access to the data that fastly has access to? Because it seems that url by url the chrome browser will send the entire history to a third party.
It's similar to Anonymized DNS. The relay doesn't learn the content because it's not encrypted for it. The target receives the payload from the relay, so it doesn't know its IP, and everything the relayed removed.
So, who can have access to the data that fastly has access to? Because it seems that url by url the chrome browser will send the entire history to a third party.
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 encapsu…
Earlier quoted context omitted.
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 encapsu…
Is Fastly planning to make their OHTTP service generally available (rather than just to specific deals)?
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: @ fastly dot com
Earlier quoted context omitted.
I appreciate that, but: 1. If google is paying fastly, what prevents google from paying fastly some more to divulge the user information as well? As far as I understand ohp, the model assumes that the three parties are not aligned which is not true for the fastly:google connection. 2. Even 1. is not true, if the encrypted body is not salted, it is effectively just a unique hash of the original url, which means that f…
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.
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...
Thanks though and good luck.
Earlier quoted context omitted.
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.…
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.
Their diagrams omit that the public key used for signing is fetched by the client directly from the Google k-anonymity server. Shouldn't the key used be either shipped with the client, or digitally signed by a shipped Google anchor & hosted by the relay? Fetching the key from Google's servers directly means that Google has a pool of IPs (and cert fetch timestamps) to help de-anonymise, and they also have the ability…
Just for everyone else.