PSM:UIforSharedDB

User Interface for Shared Database

This is related to the NSS feature for sharing a single certificate+keys+trust-settings database between multiple applications, e.g. Firefox and Thunderbird. You can read about the NSS level details at NSS_Shared_DB

While the feature works very well at the NSS level already, we have an important, yet unresolved issue: We need application level support for merging existing databases from existing user profiles, making sure that users won't loose their items stored in the separate database when we migrate them to the new shared database.

This page contains ideas about how to implement the application level support, that should be done in the core of the Mozilla platform, so any application can make use of the feature (Firefox, Thunderbird, SeaMonkey, etc.)

Bob Relyea said "Most merges will happen automatically when we call updatemerge()." Most, but not all.

A problem comes up when a user has different master passwords set on the individual old profiles.

Proposal:

• Enhance the existing security preferences in the application, the pref pane that can be reached (in firefox) using advanced/encryption.
• Introduce a new configuration option to enable the shared DB feature, next to our existing options (like SSL3/TLS1/client auth/cert manager/etc.).
• The option could be a radio button giving the following choices:
  • My certificates, certificate trust, private keys and settings for security devices are:
    • x used only by Firefox and stored in the profile folder
    • o stored in a folder that is shared between Firefox and other Mozilla/NSS applications
• The path of the "shared folder" will be recorded in the profile. By default, it will be the user's default folder for shared database (platform dependent). It will be a hidden pref that power users can change.)

• if a user clicks a radio button to change the setting, we bring up a prompt that gives more explanations.

• • warn the user that different encryption keys are being used and a migration of any saved passwords is necessary, and may require the master password for both the old location and the new location
  • warn the user that there may be problems with shared db if the user's home directory is on a network drive, recommend to use profile specific db in such environments...? (locking problems with NFS...)
  • uses a wizard-like series of dialogs, that will analyze both locations, gives progress information, asks for passwords, etc.
  • the wizard should automatically detect scenarios, where a user has manually set up shared db, by using symbolic links (does not apply to MS Windows). We should offer the user to clean this up by removing the symbolic links and store the destination NSS path as a PSM config option.
  • changing the setting will require to restart Firefox (we can offer to do so, like after changes to add-on installations)

• Here are additional ideas on top of the above, from Bob:
  • 1) if the NSS environment variable (the one that enables shared db) is set, you can assume the user wants to use shared DB. It might be nice to deal with things like the symbolic links there. If there are no symbolic links, we could prompt the user for the radio choice above. This check could happen when PSM initializes NSS.
  • 2) In the password prompt area, my sample kind of hand waves at failure modes (the user doesn't remember his master passwords). One possible recovery mechanism is to give the user the option of resetting the master password on the databases for which the user can't recall the password. Another (brainstorm) idea would be to remember the all the failed passwords the user gives us and try them against the new database (NSS automatically tries the old database's password on the new database for you).
  • 3) we have to be careful with the entry. I think we actually have to shut NSS down to change over. Remembering that Javascript hangs on to handles for us until the gc runs, we may have problems getting everything freed so we can change over. We can do the merge and update without shutting down NSS using a different slot, but there's a risk of corrupting the old database, and in the end we would need a restart. This will be the hardest thing to work around.
• While we develop the feature and work on any usability issues, the preference should initially be set to the "classic" setting (profile specific databases).
• At some point in the future, when we're confident it all works fine, we could automatically detect profiles that have never been migrated to shared (and where we never have offered the user to migrate). If we detect such a profile, we could offer the user to migrate, and use the same wizard like above.