Preferences

Isn't the phone filesystem encrypted?

anonym29
Depends on quite a few other factors, but if someone with a GrayKey or Cellebrite appliance gets your phone, there's a good chance they can get in both in BFU and AFU states, even if locked. Once unlocked (or broken into), stock Signal offers you zero protection, while Molly forces them to start a brute force attack against the password you gave Molly.

This is less true for fully patched GrapheneOS devices than it is for fully patched iOS and other Android devices, but this space is basically a constantly evolving cat and mouse game. We don't get a press release when GrayKey or Cellebrite develop a new zero day, so defense in depth can be helpful even for hardened platforms like GOS.

ufmace
I don't think this makes a lot of sense because, if the password is quick and easy to type, it can probably be cracked by any such device in the time it takes for a single keystroke. A long and complex password might hold up okay, but for it to actually be secure, you would have to type in the whole password on a phone keyboard every single time you opened the app, which sounds like a terrible experience.

I think, if you were actually willing to do that, it would probably be about as convenient and at least as effective to leave the device powered off and rely on the device full disk encryption and hardware security to protect the data at rest, only powering it on occasionally to check or send messages, then immediately powering back off.

anonym29
You do not have to type the whole password every time you open the app, only when the database is locked. You can manually lock from an unlocked state whenever you want, even from other contexts (the button to lock it is available in the background notification) or configure an automatic timeout (which is granular down to the second) to lock the database.
mhitza
Used to be supported in Android (and how I had my phones setup before). Since Android 13 it's no longer possible https://source.android.com/docs/security/features/encryption...

Their justification here https://source.android.com/docs/security/features/encryption is that

> Upon boot, the user must provide their credentials before any part of the disk is accessible.

> While this is great for security, it means that most of the core functionality of the phone is not immediately available when users reboot their device. Because access to their data is protected behind their single user credential, features like alarms could not operate, accessibility services were unavailable, and phones could not receive calls.

I'm sure they could have found a better approach, instead of file based encryption, but must have been nice to simplify engineering overhead and giving 3 letter agencies, at the same time, something that simplifies their work.

This item has no comments currently.