The app works without root by using the internal backup API of the OS, but to do this it needs to be installed as a system app. Ideally, it ships with whatever non-Google Android you are using, e.g. , , etc.
Conversation
While it could also work on other versions, the development is targeting Android 10 exclusively. The reason for that has been explained by here: github.com/stevesoltys/ba
2
1
17
Two questions:
1. Why is there no option to store the mnemonic as a file, instead of having to either memorize it or go find some physical pen and paper around you?
2. Does this requirement of Android 10 or up mean there's no hope of seeing this integrated on LineageOS as of now?
1
1. This would leak the encryption key to shared storage where it can potentially get picked up by malicious apps.
2. LineageOS is working on Android 10 as we speak. Also, people are free to keep supporting older Android versions.
1
Just a last question: is the choice of having the app generate the recovery mnemonic for the user, instead of the user typing a chosen password, based on security concerns as well?
2
It provides an ~128-bit entropy key so it can't be brute forced as opposed to a passphrase where it's highly unlikely the user will choose anything strong enough to withstand any substantial brute force attack. Passwords are an anti-pattern and should be avoided when they can be.
1
Still, shifting the onus to the user to either memorize twelve random words by heart, or search a second device (or pen and paper) to type it manually, is probably an usability issue. There is a high chance that the user will forget part of the mnemonic, or lose the paper.
1
They're expected to write it down with pen and paper on a few pieces of paper and store those in safe locations. You aren't supposed to memorize them. Users are extremely likely to forget strong passwords especially when they aren't regularly entering them on a day to day basis.
1
It's how Signal backups work too, although it's a long series of numbers rather than making it more user friendly by using BIP39. Using a passphrase isn't very appropriate because the data is extremely sensitive and a tiny subset of users are going to choose a strong passphrase.
1
It might make sense to support the BIP39 passphrase to enhance the generated seed phrase with one but that seems overcomplicated for the app especially at this stage. If users really want, they could also memorize a subset of the words and not write those down but that's risky.
1
Since it's not regularly entered but rather only entered once to set up backups, a strong unique passphrase is also going to end up being forgotten. That's just the reality of passphrases. This way, the user gets a strong key and can choose how they want to store it (if at all).
It would also be possible to support generating a longer seed phrase so that it could be split up into multiple portions, such as splitting it up into 3 parts where any 2/3 of them are required to restore. It's really not worth dealing with the complexity at this point though.
1
One idea was to later allow an OS to use a single BIP39 phrase and then deterministicly derive a key for each app that needs a client-side secret, so that the user needs to only write down ONE phrase.
1