Firefox/Feature Brainstorming:Profiles

« Firefox/Feature Brainstorming

Profile creation/switching

• Improve profile/user management and switching
  • Make the profile manager accessible through the menu

Profile privacy

• Password-protected user profiles
• Encryption of all stored data and profiles

References

• bug 16489
• bug 19184

Profile data

• Profile export/import
• Accept only relative paths in the various files to allow users to easily transfer their profiles from/to any computer with a simple copy of the profile directory
• Remote profiles hosted on a server and available to multiple installations.
• Remote profiles able to save sessions
• Remote profiles should perhaps be versionable
• Remote profiles should support a plug-able backend, LDAP, WebDav, FTP, etc..
• Full profile sync, including bookmarks, history, passwords, cookies, add-ons, preferences, etc.
• Provide a more advanced export so bookmarks and bookmark settings as well as Toolbar settings are saved.
• Automatic Sync/backup of profile data using same plug-able backends as remote profiles.
• Built-in AutoFill, which allows users to save their web passwords with Fiefox (like Avant Browser)
• Encrypted during sync/transmission
• Preference for where profile data is saved including settings, bookmarks, add-ons, passwords, etc.
• Platform-independence of remote profiles, share the same profile between installations on different operating systems

References

• RFC 2244 - Application Configuration Access Protocol
• bug 31732
• bug 147344

EULA display on first run of new profile

• Display EULA (required for distribution opportunities)
  • This is probably not required for distribution opportunities, and is indeed probably a bad idea (reduces usability, no benefit). This is only required for programs having license clauses stronger than copyright law (e.g. no reverse engineering), and not for GPL/MPL/NPL-style licenses.
  • Firefox binaries are not under the GPL/MPL or NPL, they are under the (linked) EULA, which has clauses unrelated to copyright law (e.g. trademarks).
    • Such things need no EULA. Trademarks, patents, and trade secrets are protected be default. No EULA is required to protect them. (What, you think GPL/MPL/NPL suddenly gives up your trademark rights??? Where is that?) It's like the lame statements that I can't export to North Korea: your EULA makes no difference, because I can't do that anyway.
    • According to [1] Firefox binaries _are_ under the MPL. In my opinion we gain nothing by showing an EULA, that only annoys users.

References

• End-User License Agreement (EULA) Requirements for Firefox 2

Profile content access management

• Basic concepts: User - Profile - Environment - Page - Page View.
• User can open different profiles in multiple FF instances.
• Environment is the scope available to a page and its scripts: cookies, passwords, other open pages, history, and other privacy and security settings. Similar to IE security zones but more customizable (including sets of ad, popup and content blocking rules), and not limited in number.
• Ability to use several environments in one profile and/or share them between profiles.
• Ability to set rules to determine environment by site.
• Ability to switch environment for a page or for all pages from a certain site.
• Ability to clean up environments of private data, not touching this data in other environments.
• Page views are described in Developer-facing Features

Enterprise support

• Be able to force a profile to be stored in some location like \\server\user_home\firefox (for windows) and /mnt/nfs/users/firefox (linux)
• Existing profile storage is not useful for making defaults settings for whole groups of users - so it is impossible to switch large groups of users to Firefox with shared policies and settings
• Make ability to make sets for multiple users at one editing of profile - changing their profiles
• Ability to make MAIN profile.
  • If firefox configured to use MAIN profile, then it gets policy sets from this profile (so, user can't make "not allowed" changes, until he switch off using of MAIN profile in browser (so, needs ability for administrators to block switch off MAIN profile)) Example: all default sets getting from MAIN profile and then firefox apply user settings, if this allowed by the MAIN profile for this group of sets)

Make it harder for users to accidentally switch to a new profile

Users (especially on Mac) are likely to see the profile manager for the first time when they run into a locked profile (either due to a stuck lock, or, on Mac, multiple copies of Firefox). They may tend to work around this problem by creating a new profile (not knowing what creating a new profile actually does). Then when they start Firefox with their new profile, they've lost their bookmarks, history, preferences, etc., and nothing ever shows them the Profile Manager dialog again once the lock condition goes away.

There are a number of ways to solve this:

* don't show the profile manager in response to a profile being locked if there's only one profile
* by default, show the profile manager if there are multiple profiles
* remove the entire concept of multiple profiles (since the OS should have a concept of users).  This may be the best, since the testing need for multiple profiles has been relieved by "-profile".  -David Baron 23:54, 26 October 2006 (PDT)