Confirmed users
563
edits
Line 28: | Line 28: | ||
In this latter scenario it's necessary to prompt the user about the necessary merge operation and prompt for both the old and the new master passwords. | In this latter scenario it's necessary to prompt the user about the necessary merge operation and prompt for both the old and the new master passwords. | ||
==Discussion: Multi profile migration== | |||
The proposal is to use the user's default shared database whenever no special requests have been made by the user (no environment variable points to a secondary shared database). | |||
Question: Is this default behavior safe for all common scenarios? | |||
Let's consider a user account who owns multiple Firefox profiles. | |||
Let's consider a home computer where several family members share a computer, and for simplicity there is no user account separation. However, each family member uses their own separate Firefox profile. | |||
In this scenario the private keys, personal certificates and CA Certificate trust from all individual profiles would get migrated to the common shared database. | |||
Is this merge-all-profiles approach a good idea? | |||
Or does this scenario propose that we shall implement multiple separate shared databases, based on the application's profile name? For example, should Firefox profiles named "default" and a Thunderbird profile shared "default" both use the same database, but profiles named "father" and "mother" should use their own separate shared databases? | |||
=Implementation decisions to be made= | =Implementation decisions to be made= |