Firefox and the `you have chosen to open ...' dialogue

[Ian Jackson]

As part of the DefaultApplicationsFirefox goal for Dapper, I have
suppressed (in the usual case) the dialogue box you get when (for
example) clicking on a PDF in firefox.  There has been some queries
about this and I'd like to deal with them here.

Firstly, it is obviously still necessary for users to be able to
choose to download content rather than immediately opening it.  I
think that this should still work via the Save As option from the
context menu, although there are situations (eg, redirects) where this
isn't so easily available.  So if you regularly answer `download' to
that dialogue, and can't say `Save As' instead, please let me know
quoting the URLs involved so that I can see the situation for myself.


Secondly, and this will form the bulk of the issues dealt with in this
mail, it has been suggested that there are security problems with
removing this dialogue.

So, first, some background:

There are certain content types that Firefox can handle itself, via
the builtin Gecko rendering engine (for example, HTML of course, and
many kinds of images).  These are always fetched by Firefox and
rendered internally; if you want a copy, you have to `save as' from a
context menu after it has loaded.

The change only concerns other content types.  This includes PDFs,
OpenOffice (and Word) documents, Zip files, etc. - any kind of file
that Gecko doesn't have the code to render.  The old behaviour gave
the user the three options:
 * `open' the file - ie, to save it in a temporary file and
    execute the corresponding program from the Gnome mime database
 * `download' the file - save it to the Desktop directory where
   it can be `opened' (as above) by double-clicking, saved for
   posterity, etc.
 * cancel - stop fetching (or not fetch) the file.

Some people have said that this prompt serves a useful security
purpose, because it allows the user to decline to feed a file to an
unsafe application.

In my opinion, if there are any entries in the Gnome mime database
that are dangerous when run on untrusted content, they are security
problems.  This is because there are numerous ways to get a file onto
the user's desktop and users cannot be expected to know exactly what
is and is not safe to double-click on.  They should be entitled to ask
to see a file (which is what double-clicking means) without
endangering their computer.

For example, if the PDF viewer contains a bug which allows a PDF to
execute commands then this is a security vulnerability which we would
fix.  Likewise, any features in (for example) OpenOffice.org which
allow a document to specify commands to be run on the local system
must be disabled; with these features enabled, the user cannot safely
share documents.; Being able to share documents is much more important
than being able to make the documents run shell commands.

Neither is it reasonable ever to ask a user this question:
  [Continue]  Maybe (but probably not) damage my computer
  [Cancel]    Don't get my work done
Users cannot be expected to know when the operation is actually
dangerous; instead the system must know the answer and not do the
operation if it is dangerous.  If the user can't get their work done
without compromising their system security then that is a deficiency
in the system.

However, people have said to me that the Gnome mime database contains
many unsafe programs.  Is this true ?  If it is then we must take
further steps to improve the situation.

As a sketch of an approach:
 * Add a new boolean field to the mime database,
   `safe-for-untrusted-content', which defaults to False when not
   specified.
 * Modify the Gnome MIME database lookup library functions to allow a
   caller to specify whether the file is trusted; the existing API
   would be preserved of course but the library would assume that old
   callers were dealing with untrusted content.
 * If neither (i) the database says that the handler application is
   safe, nor (ii) the caller says that the content is trusted, the
   Gnome lookup functions would arrange for the caller not to run the
   program; instead, the file would be unopenable or would be opened
   only with some safe fallback application.
 * Probably, the +x chmod bit should be used to indicate that a file
   is trusted.  This means that all archiving programs which unpack
   the +x bit by default need to be either (a) nobbled so as to clear
   it when invoked in the most normal way or (b) don't get to have the
   `safe for untrusted content' flag (which would be unhelpful).  In
   this world view any program which sets the +x bit on a file based
   on its input is not safe for untrusted input.

Alternatively, we could adopt a policy that we will review all the
mime database entries and simply not allow unsafe handler
applications.  I suspect that this would be unpopular, but it has the
virtue of being technically simple.

Ian.