Mozilla/Firefox issues rant (was Re: [linux-elitists] Browser plugins and write permissions)

Karsten M. Self kmself@ix.netcom.com
Sat Nov 20 04:46:12 PST 2004


on Fri, Nov 19, 2004 at 07:21:59PM -0800, Rick Moen (rick@linuxmafia.com) wrote:
> I'm wondering if anyone has a better solution to this problem, and am
> betting someone already does:
> 
> You find yourself wanting to install some plug-in for your Web browser.
> In olden days, it would be a tarball that you'd extract, give the hairy
> eyeball for a while, then chown some appropriate directory long enough
> to give your regular login the right to install the necessary pieces,
> then put them in place using your regular user privilege, then chown the
> directory back.  

If you're *really* lucky, the Debian team's packaged the plug-ins (or
are you referencing extensions) you want, and you apt-get install them
(or lean on your friendly neighborhood/household sysadmin to do same).
 
> Some variant on this regimen generally worked on even rather twisted
> installers -- but now we have things like XUL .xpi files, which might be
> installable outside the browser, but I'm not immediately sure how.
> Everyone seems to expect that you'll just start up the browser with root
> authority and clickity-click the thing in.
>
> Me, I'd walk a long ways around before running a Web browser, especially
> something the size and complexity of Mozilla code, under UID zero.  So,
> my half-assed spur-of-the-moment solution was to recursively chown both
> /var/lib/mozilla-firefox and /usr/lib/mozilla-firefox to rick:rick, do
> the clickity-click thing as user rick, and then chown the directories
> back.

Rick's comments are minding me that there's a healthy-sized unwritten
rant I've been chewing on regards Mozilla, Firefox, and What Ain't There
Yet[1].  A lot of this is based on observation and mulling, but pretty
much zero contact with the Mozilla / Firefox development team, so
there's probably a fair bit of just plain wrong thought in here.  But
it's _honest_ wrong thought, so bear with.

Among them.



    Profiles.  What.  The.  Fsck.
    -----------------------------

    Best I can make out, Mozilla provided "user profiles" for when the
    bulk of users were under DOS-based legacy MS Windows derivative
    environments, lacking true user seperation.  And what didn't exist
    in the OS was provided for at the application level.  I'm finding
    profiles are a PITA on both 'Doze and 'Nix, least of all because the
    first thing a user is prompted for is to create a profile.  *Very*
    oddly, there's a default one which exists in legacy MS Windows
    that's not used, on the systems I admin at work.  Under 'Nix, the
    concept makes little if any sense.  Possible negative sense.  And on
    'Doze, I find that if I've got simultaneous logins, my one profile
    suddenly morphs into a half-score, each with its own cache, cookies,
    and other settings.  Why is this?

    I suspect there's an explanation for the whole profile system, but
    I'd rather see it scrapped than anyone even waste the time trying to
    justify it.  It's borken.




    Plugin / extension management.  
    --------------------------------
  
    As Rick's pointed out, there are some pretty pointed problems under
    'Nix environments.  The best solution from a management perspective
    seems to be managing plugins through your system's package
    management tools and archive.  Otherwise, you're stuck with some
    real headaches and/or security compromises.  Hrm:  Maybe if you
    *must* run as root (or incur relatively few headaches doing so), a
    chroot-install-plugins environment makes sense...  God, that sounds
    like a hack in search of a problem.

    It gets worse though.  

    Extensions are a great idea.  And they're possibly even a good idea.
    You're liberated from developers' tyranny in terms of what features
    find their way into browsers.  But you're stuck with a large mess of
    tools, many unnecessary, many poorly designed, many duplicative, and
    some damned useful and well built, to sort through.  Ideally, a
    browser would have all the things in it you wanted (and did once, it
    was called Galeon 1.2.x).  But the golden age has passed, and we've
    got what we've got.  Extensions can be damned useful and powerful.
    The classic example is Emacs, which will write code, debug it, tell
    you jokes, psychoanalyze you, do the laundry, and scratch your back.
    But, well, the downside is you end up with an interface which as
    intuitive as, well, Emacs.

    The Firefox team appears to be largely punting on the whole concept
    of managing, owning, or incorporating extensions.  This is a real
    pity, and has the possibility of becoming a major problem.  At some
    point, they're going to have to bite the bullet and either
    incorporate major or highly popular extensions into the browser,
    and/or distribute them as a core extension set.  I'd be happy either
    way.  What I don't want to do is to have to go through the
    equivalent of Freshmeat for Firefox every time I install or update
    the browser.  Yes, Freshmeat's a fine resource, and it's a good
    thing to have.  But my first pick for software is my distro's own
    archives.


    Then there's updating.

    As Firefox just hit 1.0, it's understandable that the extension
    infrastructure's been in flux.  However, if it stays that way,
    there's something pretty wrong.  As it is, I've walked a set of
    boxes from Phoenix through 1.0, with stops at 0.8, 0,9, and 1.0PR.
    Each time, many, most, or all extensions have been obsoleted.
    That's something of a pain.


    And then there's just installing.

    I manage a *small* (10 systems) Windows network.  Best I can tell,
    there is *no* way of centrally managing extensions for the systmes
    in one place.  Rather, each extension must be manually added
    (through the GUI no less) to each of the systems.  Pity the foo'
    with a campus of several hundreds or thousands of systems.  There's
    gotta be a better way, right?  It's also not clear if the plugins
    are installed systemwide, or must be added individually for each
    user.  The 'Nix situation isn't much better, so don't get too mighty
    yet.

    One particularly distasteful experience was at ~ 0.80 or 0.90, at
    which point the GUI required about 4-6 actions, per plugin, to
    install, many of which either repeated or appeared to fail, or both.
    With what can only be described as dialog designed in the best
    Orwellian doublespeak tradition.  I couldn't tell you what the
    sequence was for doing a "global" (all users) install, but if that's
    intuitive, I'm filing a federal case for language abuse.  I did the
    math for installing six plugins, in the case where I would have to
    do this for each user on each system:  18,000 installs.
    
    The process has improved somewhat since then, to the project's
    credit, but that's still not saying much.

    There's the futher issue of balancing user desires to customize
    systems to their needs, and administrators' needs to control system
    configuration.  It should be possible to specify allowing or denying
    user plugins at some level, if only on legacy MS Windows systems
    (though likely 'Nix as well) through some sort of system policy
    configuration.



    Summarizing all of these issues, if Firefox is going to make
    extensive use of extensions:

      - There should be a set of readily available, "top tier"
        extensions either bundled with FFX or *very* readily available.

      - Installation still needs to be greatly simplified.  If possible,
        an automated system for deploying plugins to systems and/or
        users should be provided.  Installations should be specifiable
        as single-user or systemwide.  For 'Nix systems, user-specific
        installations should (and possibly already do) make user of a
        local user tree.  Group or other user-aggregation level
        configurations would also be handy.

      - Browser updates shouldn't break plugins.  Plugins which *are*
        broken by updates should fix themselves, if at all possible.

      - Plugin development guidelines specifying how and where interface
        elments are placed, designed, specified, etc., would be useful.
        Flexibility here would be good to keep in mind (GNOME is the
        case in point for We Know Better UI maldesign), but current
        plugins (particularly tab controls) tend toward a proliferation
        of not particularly well-conceived controls.  A major benefit of
        Galeon was that its centralized design placed most of the really
        important controls near the user.  While extensions allow for
        flexibility, usability seems to suffer.



    User configuration
    ------------------

    While I dispise MSIE, it has one feature that's immensely useful
    (largely because I can use it to turn itself of).  Its
    Registry-based onfiguration means that I can configure browser
    settings via logon scripts:  my users' LOGON.BAT file includes
    Cygwin's 'regtool.exe' pointing MSIE at a blockpage proxy (serves up
    a blockpage for all requests).  Earlier, I'd used similar tricks to
    set homepage and other values.

    Mozilla's file-based configuration makes such manipulations slightly
    less convenient.  The use of distinctly-named configuration
    directories (there's an arbitrary character string in the directory
    path name) makes even automated querying and changing of values
    slightly more complicated.  This is becoming an issue presently as
    I've got a configuration issue in which one group of kids' browsers
    can use a set of courseware I've deployed on an internal webserver,
    another set cannot.  Identifying (and fixing) the configuration
    settings responsible is a bit of a chore.

    Again, the enterprise / institutional organization either looking
    for uniform deployment or group-specific configurations would find
    such tools very useful.  Hell, I would.

    This issue arises on both 'Doze and 'Nix.  I manage my users'
    accounts across both platforms, and in this respect, both have
    largely equivalent issues.



As I said at the top of this rant:  these are issues I've encountered.
I haven't researched all of them extensively, though I've looked into
most of them at least a couple of times.  Firefox is a moving target,
and some of the issues may be historical (though the extensions ones
*really* left a bad taste in my mouth).  If Firefox is looking at moving
beyond the individual power-user segment, most of these will have to be
addressed.


    
> Is there a better way, (moreover) one more clueful about this being a
> multi-user environment?   Would it make sense to have a firefox-plugins
> group, to which users trusted with that some bundle of write privileges
> could belong?  Or some better solution that just isn't occuring to me?

Well, I don't know if the company's good, but it's plural.
 
> And why do (to my knowledge) no Linux distributions have any mechanism
> to deal with this problem, short of expecting people to run large Web
> browsers with root authority?

Again:  check your Debian archives.  A few of the more popular
extensions are already packaged.


Peace.

--------------------
Notes:

1.  Before you accuse me of picking on FFX:  I'm plugging on my own
    webpage, prominantly, use it daily on two platforms (GNU/Linux and
    'Doze),  and support it for 16 score kids.   It's not all I'd like
    it to be, but since the Galeon team utterly effed up with the 1.3.x
    release, it looks like a leading browser choice.

 

-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety.
    - Benjamin Franklin, 1755
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20041120/98f094a6/attachment.pgp 


More information about the linux-elitists mailing list