Comment by leereeves
6 days ago
That sounds like a good idea with one obvious challenge: how can you prove that data will remain private forever?
6 days ago
That sounds like a good idea with one obvious challenge: how can you prove that data will remain private forever?
That’s a tough guarantee, ultimately you’re placing trust in the device’s security once you limit your attack surface to just local data. So that’s why we’re working on encryption with key custody. Any feature like cloud backups are explicitly opt-out by default so no one is putting their data onto someone else’s servers without knowing what they’re getting into.
Just to be clear, you’re saying cloud backups are off by default, and the user must explicitly enable them?
If so, just FYI I believe that pattern is usually referred to as “opt-in.” As in, the feature is off by default, and the user must opt in to using it.
Yes, you have that right
(Don't take any of the below in a negative sense! It's awesome you built a privacy-first solution and care about these things, to the extent practical. Below just musings)
I assume the attack vector here is more along the lines of 23andme bankruptcy -- if developer is bought by a new corporate entity / priorities change, what guarantees exist that privacy architecture won't backslide via updates?
Users shouldn't be concerned that a minor update or corporate sale will change the bargain they made around their privacy.
Honestly, it'd be great if there were scaled third-party cloud key escrow services coupled with enforced legal guarantees.* ^
It feels like we did cloud wrong from a legal/privacy perspective by not separating keyholder from data-at-rest-holder (legal entity wise). Tenant-based encryption is basically there... just still mingling data and key ownership in the same entity.
GDPR / right to be forgotten would be trivial if there were always a third party (who enforced requirements on any first party) I could submit a request to, that would burn my keys on their side, thus rendering first-party stored data un-practically-retrievable.
(And a third party because, similar to the browser+CA system, balancing power against each other to enforce guarantees of good behavior seems effective)
* Legal guarantees like "no caching keys for longer than X" or "no unencrypted user data at rest"
^ Cloud hosting encryption keys would also solve the ugly UX edge of strong encryption around "I lost my key... help?"
This is a wonderful comment, but also ...
Is there a way to prevent future versions of the app from uploaded the locally saved data? Even if none if it was in the cloud to begin with?
That's the route I would be most concerned about.
After that, I agree with the rest of your comment.
4 replies →
Simple + open source + no access to network + no updates (idk about Android/iOS cross-app data sharing).
Still data can be uploaded to the cloud and will be available to cloud providers.
So there is more vectors to protect user data.
Still, I can steal your phone or use my $5 wrench to get the data. There is no guarantee, so why bother. Hypotheticals can always be used to shit on any idea. They just are not always helpful
> no access to network ?
5 replies →
What's your threat model?
I was going to say operate it under a non-profit but then I laughed in Altman.