Don't lose your device while it has data on it or hope the OS has good enough security to stand up to an adversary with local access to the device. The sql encryption on the database is mostly useful for backups which wouldn't send the key along with it.
If they document it, it becomes a standard and people start to rely on it. Even if the documentation itself is merely to explain the how and why of the database's encryption.
> Last time I checked, they switched to SqlCipher as well, but with the password in an unencrypted file right next to the database file.
> What's the threat model of such an odd design choice?
The only thing that is more secure is to use Window's Credential Manager to store the key, which is what Bitwarden does [0].
But those credentials can also be easily dumped [1]. But at least this means that a system-wide data dump doesn't reveal the DB's content.
I am not well-versed in the credential manager, but I wonder if it is possible to tie the credential to the executable (signer? hash?).
[0] https://github.com/bitwarden/clients/blob/89d7e96b25594e51a7...
[1] https://gist.github.com/micjabbour/654e67d29cbd62be3587b9f1d...
Easy and not odd at all, I would say: if your computer/smartphone is compromised, you're screwed. If an external program can read what appears on the screen, then no matter what kind of encryption you have at rest, they will be able to read the text.
So if it matters to you, you should make sure that your device is not compromised; it cannot be done by Signal. What Signal can guarantee, though, is that it can transmit messages securely between non-compromised devices. And that it does well.
Another example: For years the database for the desktop app was unencrypted, because "you can just use FDE" (according to GitHub commenes). Last time I checked, they switched to SqlCipher as well, but with the password in an unencrypted file right next to the database file.
What's the threat model of such an odd design choice? Are there any docs on that?