Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Partnering with Fastly–Oblivious HTTP relay for FLEDGE's 𝑘-anonymity server

developer.chrome.com

Post reply on HN
Print view View original

1–10 of 39 posts

Re: Partnering with Fastly–Oblivious HTTP relay for FLEDGE's 𝑘-anonymity server

#3

Post by jgrahamc »

gostsamo wrote: post #2

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.

There's a good explanation of this on the Cloudflare blog here: https://blog.cloudflare.com/stronger-than-a-promise-proving-... The relay server can't see the HTTP request contents as it is encrypted using the key of the gateway (i.e. Google).

Re: Partnering with Fastly–Oblivious HTTP relay for FLEDGE's 𝑘-anonymity server

#4

Post by gostsamo »

jgrahamc wrote: post #3
gostsamo wrote: post #2

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.

There's a good explanation of this on the Cloudflare blog here: https://blog.cloudflare.com/stronger-than-a-promise-proving-... The relay server can't see the HTTP request contents as it is encrypted using the key of the gateway (i.e. Google).

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 forth party could make inferences about the content of the message by encrypting many possible url-s of interest through the google key encryption. Salt is not mentioned in the article.

I'm not a chrome user, so it is just random curiosity. In fact I like Google and many of the things that they've made affordable to the world, but I also do not like tracking of people for most reasons and for most of the ways it is done.

Re: Partnering with Fastly–Oblivious HTTP relay for FLEDGE's 𝑘-anonymity server

#5

Post by garblegarble »

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 to serve particular clients unique public keys to deanonymise them.

Re: Partnering with Fastly–Oblivious HTTP relay for FLEDGE's 𝑘-anonymity server

#7

Post by meandmycode »

gostsamo wrote: post #4
jgrahamc wrote: post #3

Earlier quoted context omitted.

There's a good explanation of this on the Cloudflare blog here: https://blog.cloudflare.com/stronger-than-a-promise-proving-... The relay server can't see the HTTP request contents as it is encrypted using the key of the gateway (i.e. Google).

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…

How far does this scenario go though? it would be easier for Google to just deploy a changed client app (chrome) that skips the blinding infrastructure, or just sends the user information to them at the same time anyway. In the end, unless you're reading and building every line of code (and maybe even hardware) you are delegating trust.

Re: Partnering with Fastly–Oblivious HTTP relay for FLEDGE's 𝑘-anonymity server

#8

Post by jgrahamc »

gostsamo wrote: post #4
jgrahamc wrote: post #3

Earlier quoted context omitted.

There's a good explanation of this on the Cloudflare blog here: https://blog.cloudflare.com/stronger-than-a-promise-proving-... The relay server can't see the HTTP request contents as it is encrypted using the key of the gateway (i.e. Google).

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…

I don't think your #2 is a concern as OHTTP uses HPKE (https://blog.cloudflare.com/hybrid-public-key-encryption/).

Re: Partnering with Fastly–Oblivious HTTP relay for FLEDGE's 𝑘-anonymity server

#10

Post by gostsamo »

meandmycode wrote: post #7
gostsamo wrote: post #4

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…

How far does this scenario go though? it would be easier for Google to just deploy a changed client app (chrome) that skips the blinding infrastructure, or just sends the user information to them at the same time anyway. In the end, unless you're reading and building every line of code (and maybe even hardware) you are delegating trust.

How far would a multi billion company go in order to ensure its main source of income? They have a history of providing privacy assurances which fell through under serious inspection. The flock scheme was a few months back, the stop location history scandal was a few years back, and I'm mentioning only those on the top of my head.
Post reply on HN