Using nsIOSKeystore [0] for the password database, the cookie jar, and client certificates makes sense: utilize the mechanisms provided by the platform to protect Firefox's secrets, as the platform has more tools in its arsenal -- like secure elements and the user's preferred authentication regimen.

This is a meta bug intended to track the sub-bugs necessary to make this happen.

The big work is UX around handling password export/import, and figuring out the corner cases one way or another (through UX & keysplits [1], or via opt-out prefs, or something) for profiles shared on, say, network drives. The actual switchover is easy (modulo that we haven't implemented OSKeystore on Android), but making it not cause undue grief for all the corner cases is the hard part. [1]

• [0] https://searchfox.org/mozilla-central/source/security/manager/ssl/nsIOSKeyStore.idl
• [1] A ... general ... example of UX/keysplits if a user after-the-fact needs to set a recovery passphrase ... which seems not great, but to serve as a basis for what could happen, assuming no Sync:

::opens profile on a new machine, either via copying, restoration of a backup, or via network share::

"Can't open your stored passwords because they are protected on your other comptuer. 
  Please go to the original computer for this profile, go to security->prefs, and set a recovery passphrase."

::User changes to the prior computer::

::User sets a recovery passphrase and re-copies the profile or saves it to the network drive or whatever::

"Enter your recovery passphrase to enable password access on this computer"

The procedures to handle multiple profile access should be debated in their own bug, bug 1562325, depending on this meta bug.

Note that client certs' access would be best handled by delegating operations to the platform secret store, which we have separately specified. We would not likely find much marginal utility improvement for Firefox/NSS to do the re-plumbing to cover them in the NSS DB versus doing the heavier lifting that gets us much better enterprise compatibility. But we should open a specific bug for client certs for further discussions there.

Have you considered portable use of the browser at all? Using the system keystore pretty much destroys that option.

(In reply to Mark Straver from comment #2)

Have you considered portable use of the browser at all? Using the system keystore pretty much destroys that option.

That's bug 1562325. It's doable with the perhaps-needs-a-different-name "recovery password" idea of having a strong key-split that the user can know, too. But please take discussion to that bug.