Earlier quoted context omitted.
Then the app can make a bog-standard encrypted-at-rest backup to somewhere and make all the computations on the device on the cleartext data. I don't see the need to do computations on the encrypted data here, which is what FHE would provide in addition to traditional encryption. > and don't have access to the account anymore. This would be trouble with or without FHE. Even if the backend wouldn't need to decrypt the…
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." 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 whe…
> "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.