alt Hacker NewsOkay, so the platform becomes valuable to its users when it's able to suggest things like "based on millions of users, people with cycles like yours typically ovulate around day 16."
In order to do the data mining in order to make those kinds of claims, traditionally you'd need to have access to the data.
As you point out, encrypted-at-rest is solved. But what about when it's not at rest?
In-use and in-transit is when FHE kicks in. Sure, you could just do it locally, but then you miss out on the aggregate data mining. Not for advertisers, but because it helps women with their bodies. The compelling product claim is "we literally cannot read your period data." Not "we pinky swear not to" but "we actually really really actually can't!"
Replies
If you can trust the app/platform developers to send encrypted anonymised personal data, then how can you trust them to properly use FHE personal data?
> "we literally cannot read your period data."
If the purpose is aggregated data for statistic, then surely the only per-user data they need centrally can already be aggregated (to some degree) on the device, e.g. send back only statistical-distribution variables of the personal data, for distributions over the 3-4 months? And at some point, does the service need to keep collecting data, once the model is good enough (at predicting ovulation etc)?
Another concern would be: If they are building a model, using user data, why should they own the model and thus monetise it (i.e. sell it back to its users) when users get no compensation for supplying that data in the first place.
A flow-tracking app should just stick to that, and purchase the model (for a fee) from a third party. The third party should concern itself with how to get the data without being able to leverage its position as a flow-app maintainer to trick or mislead the majority of its users into giving them free data.
> Okay, so the platform becomes valuable to its users when it's able to suggest things like "based on millions of users, people with cycles like yours typically ovulate around day 16."
I don't know much about period tracking apps, but is this really the main reason people install those apps? Wouldn't you be able to get similar results by simply monitoring (on-device) the cycle of the person who uses the app for a few months?
How do those apps work before they have millions of users?
All the warnings I've seen about period tracking apps were about unexpected data collection of the entered data. This would be pretty silly if the data collection was integral to what the user expects the app to do.
> Sure, you could just do it locally, but then you miss out on the aggregate data mining.
Ok, a bit of a technical question about FHE here: My understanding of FHE was that you have input data encrypted with some key (plus auxiliary inputs, if needed, that are not encrypted), then you do operations on that data and get a result that is (still) encrypted by that same key.
No questions there as long as you're dealing with a single key.
But the whole point of aggregation and data mining is to combine data from many different users, i.e. inputs that are encrypted by many different keys. Does that work with FHE at all? And if yes, by which key is the aggregation result encrypted?
I don't see how that would work without either "moving" data from one key to another - which would be practically equivalent to decryption - or getting a result that is simultaneously encrypted by all user keys, i.e. practically useless because no one could individually decrypt it.
> The compelling product claim is "we literally cannot read your period data." Not "we pinky swear not to" but "we actually really really actually can't!"
You could obviously read the data enough to do aggregations on it.
If you can do that for "good" purposes, what stops you to use the same aggregation algorithm for advertisers - except pinky promises again?