Molly dev here. For security, the app is helpful in case the device is stolen or searched. In short, it tries to defeat smartphone forensics.
The scenario is that someone grab the device and wants to read the chats, contacts, or access any information stored in the app. And you realize or suspect that. For example, because you lost the phone, or because it was left out of sight in an unsafe place.
Under the big assumption that the device was clean of malware when Molly was locked there are no technical means to access the data without the password. This is the goal. If there was any security guarantee it would be this one.
When Molly is locked, the database is closed, and the only way to open it again is by entering the password. While locked, the app cannot display notifications. I guess this is the main blocker why Signal has not implemented password encryption yet. I have some ideas to fix this in a secure way, but it would require to modify all Signal clients not just Molly.
To lock the app, there are two options. Either you tap "lock" in the menu, or you set up a timeout. This timer starts counting down with the Android screen lock. Therefore, it should be adjusted by considering the time you expect an attacker could bypass the Android lock screen, and gain root access to the device, and the period of time you want to be able to receive notifications. There are more lock triggers in the roadmap, like the action of connecting an USB cable... many exploits works through USB.
I agree that in a perfect world with zero vulns, all this should be handled by the OS. But even that, there are use cases for Molly. Should your fingerprints or a weak pattern give access to everything stored in your phone? Let me tell you someone's else analogy, "The keys to my front door shouldn’t also unlock my safe. You can rifle through my cutlery, but not my banking records."
“Stolen or searched” isn’t a very specific description. Does the attacker have the screen lock? Or is the screen unlocked but they don’t have the screen lock factor?
Does the attacker have the ability to inject code into the running OS, or only to read memory contents?
Etc.
I’m not saying this is unreasonable, but it seems like your design philosophy is sort of “belt and suspenders”—-i.e. layer on any defense you can. This can increase safety, but at cost of features or usability (as you noted) or complexity.
To your specific case (“you realize or suspect that”)—why wouldn’t I just use the lock screen? :)
> “Stolen or searched” isn’t a very specific description. Does the attacker have the screen lock? Or is the screen unlocked but they don’t have the screen lock factor?
> Does the attacker have the ability to inject code into the running OS, or only to read memory contents?
As long as Molly is locked, it doesn't really matter. It offers protection in the worst case scenario, under the premises I noted before.
> This can increase safety, but at cost of features or usability (as you noted) or complexity.
You are right. Just keep in mind not everyone need a safe, but the people who need it appreciate having the option to buy one.
> why wouldn’t I just use the lock screen?
Because you know there have been working exploits in the past to bypass the lock screen, or to read physical RAM directly from the USB port of a locked phone (1). And thus it is reasonable to believe there are still more vulnerabilities to be discovered and patched in Android.
To be specific, for many phones if they are turned on you can just plug them into a Cellebrite box and get immediate unlock. Unless you follow strict message discipline in keeping the phone powered off it is very difficult to avoid this attack.
Tossing the database encryption key when idle is a form of segmentation in time, and is a considerable constraint on attackers.
The scenario is that someone grab the device and wants to read the chats, contacts, or access any information stored in the app. And you realize or suspect that. For example, because you lost the phone, or because it was left out of sight in an unsafe place.
Under the big assumption that the device was clean of malware when Molly was locked there are no technical means to access the data without the password. This is the goal. If there was any security guarantee it would be this one.
When Molly is locked, the database is closed, and the only way to open it again is by entering the password. While locked, the app cannot display notifications. I guess this is the main blocker why Signal has not implemented password encryption yet. I have some ideas to fix this in a secure way, but it would require to modify all Signal clients not just Molly.
To lock the app, there are two options. Either you tap "lock" in the menu, or you set up a timeout. This timer starts counting down with the Android screen lock. Therefore, it should be adjusted by considering the time you expect an attacker could bypass the Android lock screen, and gain root access to the device, and the period of time you want to be able to receive notifications. There are more lock triggers in the roadmap, like the action of connecting an USB cable... many exploits works through USB.
I agree that in a perfect world with zero vulns, all this should be handled by the OS. But even that, there are use cases for Molly. Should your fingerprints or a weak pattern give access to everything stored in your phone? Let me tell you someone's else analogy, "The keys to my front door shouldn’t also unlock my safe. You can rifle through my cutlery, but not my banking records."