“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.
“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? :)