Comment by pton_xd
1 month ago
> This is what a good privacy story looks like.
I have an idea: send an encrypted, relayed, non-reversible, noised vector representation of your daily phone habits and interactions. That way you can be bucketed, completely anonymously of course, with other user cohorts for tracking, advertising, and other yet-to-be discovered purposes.
It's a great privacy story! Why would you have a problem with that?
What would be the value to the user in your scenario? In the photos app real scenario, it’s to enable a search feature that requires pairing photos with data not on the phone. (I understand you’re being sarcastic.)
Maybe we can do some analysis and optimize phone battery life based on your cohorts usage patterns.
I don't know, I'm sure we'll figure something out once we have your data!
That doesn’t make sense, and the other user is right that you can’t give up personal data with this scheme. Perhaps focus on the real privacy leaks from cell phones like tower connections and sign-ins to Instagram.
The entire point is that you don't actually have the data, only the client can decrypt any of it.
1 reply →
They don't "have your data," even at an aggregated and noised level, due to the homomorphic encryption part.
Restating the layers above, in reverse:
- They don't see either your data or the results of the query (it's fully encrypted even from them where they compute the query -- this is what homomorphic encryption means)
- Even if they broke the encryption and had your query data / the query result, they don't know who "you" are (the relay part)
- Even if they had your query hash and your identity, they couldn't reverse the hash to identify which specific photos you have in your library (the client-side vectorization + differential privacy part), though by the this point they could know what records in the places database were hits. So they could know that you took a photo of a landmark, but only if the encryption and relay were both broken.