[linux-elitists] Firefox Profiles are a Good Idea
Tue Dec 25 04:41:55 PST 2007
Hi, sorry for the late response.
On Monday 26 November 2007, Karsten M. Self wrote:
> on Thu, Nov 22, 2007 at 10:57:09PM +0200, Shlomi Fish (firstname.lastname@example.org)
> > This post to this list by Karsten M. Self caught my memory:
> > http://allium.zgp.org/pipermail/linux-elitists/2004-November/010576.html
> > In it, he ranted against several Mozilla and Firefox concepts that he
> > considered bad. One of them was the Firefox profiles. However, as it
> > turned out to me, I found them to be very useful.
> > First of all let me know, that my family have been using two Firefox
> > profiles on a single Windows' machine account, so that only one will
> > log in to the university's network, for some time now. A similar setup
> > could prove useful for someone who only has an under-privileged
> > account on a UNIX machine.
If I only have an under-privileged account (and not root privileges), then I
cannot create a new user just to have different Firefox configurations. In
this case, what I can do is create a new profile with a different
Perhaps you're assuming that everyone who work on Unix-like OSes have root
privileges to their machines. But a situation where you don't have root
privileges is very common, for example in shared networks of universities. In
this case, you simply cannot create a new user just to have a different
Firefox config, because only root can. So a Firefox profile is convenient.
Using Firefox profiles instead of different users have other advantages - see
> > Furthermore, each profile has its own list of installed and enabled
> > plugins. So if some plugins misbehave under certain conditions, one
> > can use a profile that doesn't have them installed. Recently, I tried
> > to post to LiveJournal using my default and overloaded Firefox
> > profile, and it got stuck after previewing the post. So today I set up
> > another profile which I called "Bare Essentials" with no plugins
> > defined, and used it to post to LiveJournal. It worked beautifully on
> > both times without a hick-up.
> That is actually a useful feature of many programs, and not one which
> needs to be conflated with Firefox's existing "profiles" configuration.
Yes, but this indicates that it makes Profiles useful in Firefox. For example,
Konqueror does not have such profiles (the best it has are the
so-called "View Profiles" which only affect the tabs and other window
arrangement), and so if a plugin misbehaves, I cannot cancel it.
> > Karsten's comment about the fact that a user is prompted to create a
> > profile, has since been resolved. Now Firefox automatically creates a
> > default profile, and most users will never see the profiles' choice
> > dialog. One can configure Firefox to show it at startup in order to
> > choose a profile, but it's otherwise kept out of the concern of most
> > mundane users.
> Unless this has been markedly cleaned up, there's still the problem of
> generating additional profiles when not needed.
Which problem are you talking about?
> I'll have to look into
> that. Admittedly this is actually more a problem in Windows with
> roaming profiles where extensive browser caches can greatly slow user
> login and logout times, as the data needs to be synched with the domain
> > So I think the Firefox profiles, as currently implemented are a good
> > idea, and a useful feature of the browser.
> The problem, then and now, is this: there are certain system operations
> and features which are best accomplished at the lowest possible level,
> and for which developing workarounds, however attractive they may seem
> at the time, is at best a temporary fix, to be heaved with great
> prejudice and violence at the earliest possible moment.
> User accounts are an operating system feature.
> Application-specific "profiles" or "personalities" are a pale imitation
> of this, and in the current (and past several) generations of all
> mainstream desktop platforms (Linux and BSD, Mac OS X, Windows 2k+), are
> more than adequately provided for at the OS level. With various levels
> of simultaneous multi-user logins available ("fast user switching",
> etc.), including simultaneous use under Linux via XDMCP, remote X11,
> VNC, NX, or similar, there's no reason to accomodate multiple user
> personalities within a single application.
Here's where you are wrong. Not everyone are able to create new user accounts
on the workstations they are working on. Not everyone has this technical
know-how. And different user accounts suffer from different access
permissions (read/write/execute/etc.) that Application-specific profiles are
not subject to.
If, in order to use a browser with a different proxy configuration, or without
a problematic add-on, I need to switch to a different user, then somehow
transfer or access all the relevant files in my account, and then use the
browser, and then transfer all the resultant files, then it will be a major
inconvenience. (If it's actually possible).
On the other simply starting the browser using a different profile (possibly
in parallel to the current session -
and doing what you need to do as the same OS-level user account.
> The problems resulting aside from those previously described is that
> fundamentally a given application has no idea what another application's
> concept of user seperation will be.
Care to explain a bit?
> For those who have some recollection of the bad old days of DOS (and the
> current incarnations of the default shells under Windows are), a
> comperable situation is filename globbing.
> Under any reasonable 'Nix shell, globbing is a shell function. That is:
> a wildcard character or sequence (e.g.: foo*, foo.*, 100[a-z].dat,
> gl?b.txt) will result in a substitution _in_ _the_ _shell_. The invoked
> command doesn't see the glob, but the expansion of same (unexpanded
> globs are passed on to the command, however).
> The result is this: all applications respond consistently to the same
> glob pattern, in the same context.
Except applications like "find" that do their own globbing.
> Similar fundamental shell constructs such as stdin, stdout, stderr, and
> input/output redirection are also defined at the shell.
> In the Windows world, the behavior is different, in that applications
> expand globs, not the shell. What's the result?
> - Different applications glob differently.
> - Globbing code varies among applications. Bugs and inconsistencies
> may result inadvertently even when following the same spec.
> - Scripting becomes much more difficult through the lack of consistent
> behavior and features.
> See: http://www.byteclub.net/wiki/DOS_filename_globs
I know. However, I don't see how this discussion is relevant to profiles,
which may prove useful even in a multi-user operating system, as I
> Getting back to the idea of profiles, in a world in which applications
> provide their own "user seperation semantics":
> - The user-seperation is illusory. Within a single application you've
> got different personalities and capabilities, but none of the
> security-related (access, permissions) features of true user
Like I said, application profiles have uses beyond user-separation. In a sense
they are meant to allow several different themes of customisations, that can
be chosen by the same user and used for different contexts. They are
orthogonal to the OS being a multi-user one.
> - Actions occuring outside the context of the application (file
> downloads, invocations of external applications, etc.) lose the user
> seperation. There's no common interface or construct for dealing
> with personalities between applications. Using proper OS user
> seperation features supplies this automatically.
> - The entire featureset is papering over a missing feature of the OS,
> or today, a misuse of an OS which has the proper features but is
> not being properly used. Sadly, resistance of people to creating
> and using separate accounts is all too common, usually for mistaken
> reasons. I'm glad that I've got my parents to use their own
> separate accounts on their new Mac. Progress.
Read what I said above.
> - The "feature" gets in the way when it's forced upon users of true
> multi-user operating systems.
Not always like I demonstrated.
> I still say lose it.
> Now, as to the idea of setting up different personalities of an
> application to behave in specific ways under specific invocations: that
> is an old, honored, and revered 'Nix tradition. It's typically achieved
> by using different .*rc files (or other application startup / config
> files), often with a bit of alias, shell function, or shell-script glue.
> Some applications (usually editors) will default to various roles when
> invoked on specific types of files (e.g.: different programming
> languages). The difference here is to change _behavior_ of the
> application _within_ _the_ _context_ of a _single_ account. Nothing
> wrong with that.
And that's what Firefox profiles do.
> Sparing yourself the idiocy of not being able to be invoked the same way
> twice without spawning an unnecessary new "profile" is a major win.
> Note that many applications (vim, mutt, w3m, screen) will keep a
> specific instance state (usually a /tmp file) independent of the
> applications startup configuration. Firefox fails in this regard to the
> best of my (weak) knowledge.
It is possible you can only use only one firefox instance with a certain
profile. Trying to achieve a multi-instance-per-profile ability to Firefox
seem to me to be very hard (and not really worth it) given the Firefox
> The one feature which _would_ be damned useful in a browser, first
> voiced to my knowledge by Don Marti, would be an option to run an
> underprivileged, chrooted, and otherwise sandboxed instance in such a
> way that malicious external code and data would have a minimal
> opportunity to cause havoc on my own systems.
It may be useful. But then one would need to resolve the problem of
saving/downloading and uploading files from the rest of the home directory.
All that put aside, I should note that I found another use for profiles
recently. I wrote a content-rewriting proxy to fix a site that does not work
And I used a new Firefox profile, that will make use of this proxy, which I
can then run only when I need to and against the corresponding profile. So I
don't have to run this proxy all the time (or risk potential problems it
causes), because I can run it only when running Firefox under the new
The more I use profiles, the more I find them useful.
Shlomi Fish email@example.com
I'm not an actor - I just play one on T.V.
More information about the linux-elitists