[linux-elitists] Firefox Profiles are a Good Idea

Karsten M. Self karsten@linuxmafia.com
Mon Nov 26 12:36:14 PST 2007

on Thu, Nov 22, 2007 at 10:57:09PM +0200, Shlomi Fish (shlomif@iglu.org.il) wrote:

> 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.

> 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.
> 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.  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.

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.

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.

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

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

  - 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.

  - The "feature" gets in the way when it's forced upon users of true
    multi-user operating systems.

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.

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.

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.

The other gripe in my post referenced by Shlomi was centralized plugin
management.  I'm now running into this on the Mac platform as well as
Linux, and would be interested to know what if any solutions/workarounds
people have for globally installing useful plugins.  Defined as
(speaking for m'self):

  Adblock Plus, Addblock Filterset.G Updater, Firebug, Flashblock,
  Greasemonkey, Modify Headers, NoScript, Repagination, Tab Mix Plus,
  and User Agent Switcher


Karsten M. Self <karsten@linuxmafia.com>        http://linuxmafia.com/~karsten
    Ceterum censeo, Firefox profiles  delenda est.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20071126/8b096f41/attachment.pgp 

More information about the linux-elitists mailing list