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

11–20 of 39 posts

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

#11

Post by gostsamo »

jgrahamc wrote: post #8
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…

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

Correct me if I'm wrong, but either the user encryption key is unique and hence the user is identifiable to Google, or a finite number of keys is used which makes the encrypted text subject to identification because a finite number of inputs can produce a given output.

My cryptography education is rather superficial, so I might be missing something.

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

#12

Post by amluto »

> We will require a crowd of 50 users per creative within the past 7 days before the ad can be rendered.

Am I missing something? 50 is not a big number. And 50 over 7 days is less than one per three hours, which suggests that coarse-grained time-based attacks or simply changing the targeting every few hours could end up effectively targeting a single user. Or just asking for the ad 49 times before unleashing it?

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

#13

Post by meandmycode »

gostsamo wrote: post #10
meandmycode wrote: post #7

Earlier quoted context omitted.

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.

That's fair, I suppose my point is there are easier ways, I don't think there's any way to technically achieve full privacy on the current design of the internet that couldn't be circumvented by operational changes. But perhaps the point is more that technologies like this are maybe used more to provide false assurance through obscurity. Although it does sound skeptical and bleak given there is no real solutions to that.

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

#14

Post by jgrahamc »

gostsamo wrote: post #11
jgrahamc wrote: post #8

Earlier quoted context omitted.

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

Correct me if I'm wrong, but either the user encryption key is unique and hence the user is identifiable to Google, or a finite number of keys is used which makes the encrypted text subject to identification because a finite number of inputs can produce a given output. My cryptography education is rather superficial, so I might be missing something.

I know nothing about what has been implemented by Google/Fastly. All I can point you to is the details of Cloudflare's implementation and RFCs (which we co-authored): https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/

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

#15

Post by pornel »

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…

If you don't trust Google, you can't use Chrome. It's as simple as that.

Remember that the Chrome binary is closed-source and can't be reproduced from Chromium source code.

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

#16

Post by jsnell »

VWWHFSfQ wrote: post #9

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

As far as I can tell from reading the proposal, this claim is not true. The API is used from the bidding scripts run locally by the browser, and it is the ad space seller that decides which buyers' scripts are eligible to run.

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

#17

Post by jsnell »

malf wrote: post #6

It’s not immediately clear what stops me from preparing k-1 sybils?

According to this:

https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonym...

You'll need to spend a Private State Token to call the k-anon API, minting PSTs is rate limited on the server side, and the client and server still cooperate to make forging PST requests hard (e.g. device integrity attestation, requiring the user be signed into Chrome). What I think this means is that you could undermine the k-anonymity in individual cases by large amounts of manual work, but not do so at scale.

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

#18

Post by skuhn »

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.

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.

[1] https://www.fastly.com/blog/enabling-privacy-on-the-internet...

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

#19

Post by skuhn »

jgrahamc wrote: post #14
gostsamo wrote: post #11

Earlier quoted context omitted.

Correct me if I'm wrong, but either the user encryption key is unique and hence the user is identifiable to Google, or a finite number of keys is used which makes the encrypted text subject to identification because a finite number of inputs can produce a given output. My cryptography education is rather superficial, so I might be missing something.

I know nothing about what has been implemented by Google/Fastly. All I can point you to is the details of Cloudflare's implementation and RFCs (which we co-authored): https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/

I can confirm that this is also the spec that we implemented at Fastly for this OHTTP relay service.

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

#20

Post by skuhn »

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…

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.

Post reply on HN