[NoTranslationL]

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.

[kevinventullo]

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.

[NoTranslationL]

Yes, you have that right

[ethbr1]

(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?"

[fn-mote]

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.

[ethbr1]

Blocking network access by a specific app at the OS level would be the way to achieve this.

I don't believe iOS currently has this ability (all network, not just cellular).

Android has solutions like NetGuard.

[illiac786]

But you can make updates manual instead of automatic, that’s something.

[ethbr1]

The issue with this in practice is that it collapses to one of (a) never take updates ever again or (b) risk that any update changes privacy behavior.

Given that it's impossible for a user to vet each update's content effectively.

[illiac786]

I agree about a) but b) does not make sense to me, otherwise you cannot instal the app in the first place. I think that a quick internet search about the apps privacy is sufficient for b), definitely better than automatic updates. And it does not have to happen for every release.