> The files on disk are already encrypted (or at least are encryptable: there is a flag the developer can technically turn off), remember, by iOS itself;
Just to clarify on this, I had been thinking that the user had to opt into full disk encryption on iOS, does it come enabled by default?
> (unless the app itself has to be separately unlocked each time you use it--to prevent this key from being stored on disk--which I don't think is true of Signal? or, if it is, is not how that user is clearly using it)
At least for the way I use Signal on iOS, the screen can lock and be unlocked by Face ID, but yes, no separate key I have to enter to unlock the SQLCipher database.
So yeah, maybe it doesn't add too much to the current implementation, especially if files are encrypted by default by iOS. If not, then I can see the benefit in adding the "well the device isn't encrypted but at least the Signal files are."
For my case, it was more like this:
> or putting passwords on specific files; which, of course, fits perfectly with sqlite being used as an app-specific file format, but that definitely isn't the case for here.
I built an app for micro-journaling about how I was feeling and I wanted it to be super private, so, at the time, it was local-only and stored the data in a SQLCipher database. The user had to enter a password each time to enter the app and unlock the database, AFAIK, I coded it so the password wasn't stored anywhere.
Yes, the idea was defense in depth, maybe too intense at the time and maybe even less necessary now that more phones seem to have full encryption than they did in 2012-14 when I was making this.
Anyway, I'm grateful for your insight—thank you!