Desktop-wide HTTP infrastructure

There's been some discussion, particularly in the context of OnlineDesktop, of having a single desktop-wide HTTP infrastructure so that your cookies, passwords, cache, etc could be shared between the browser and various apps that might want to use them. These are some in-progress notes on that.

Notes on Mozilla Profiles

Most data in Firefox is stored per-profile, and none of the data in the profile can be accessed by multiple processes at once. At one point, there was discussion about profile sharing, including mozilla bug 178806, "provide IPC mechanism for profile sharing, etc.". This seems to have mostly stalled and been forgotten about. (It seems that a lot of the discussion was based on the idea that the world would end if Thunderbird and Firefox couldn't share a profile, and when that turned out to not be true, people lost interest.)

As it turns out, Epiphany uses the same stock mozilla mechanisms that Firefox does for most of the things discussed below, so everything that is said about Firefox applies to Epiphany too. In some cases, changing Epiphany to do something else would be easier than changing Firefox, but this doesn't really help us, because we have to solve the problem for Firefox anyway.

Passwords

Firefox stores passwords in a plain text file (signons2.txt) in the profile dir, which is read in once (at startup) and written back out in full after any password is added or changed. We want it to use GnomeKeyring instead.

Work on making Firefox use GnomeKeyring has been started upstream (mozilla bug 309807: Integrate Password Manager with Gnome Keyring Manager) but is currently stalled.

Cookies

Firefox stores cookies in a plain text file (cookies.txt) in the profile dir, which is read in once (at startup) and written back out in full shortly after any cookie is changed. This means other apps could read the nearly-current state of a cookie, but can't write changed cookies back (unless the browser isn't running).

I don't think we care where the cookies are stored, as long as they're shareable.

Possibilities for sharing:

• We might be able to write a Firefox extension to make it keep its cookies somewhere else, in a shareable format. (I don't know enough about Firefox to know if this is possible.)
• Alternatively, we might be able to write a Firefox extension to let other apps ask Firefox to modify the cookie db for them (or even do this directly via XPCOM or something). This would require separate codepaths depending on whether or not Firefox was running...

SSL Certificates

Firefox uses NSS, mozilla's crypto library (which is also used by evolution, and may eventually be used by other apps as a result of the Fedora Crypto Consolidation project). Currently the NSS databases are non-shareable, but this is being changed (qv mozilla bug 217538). I think Firefox 3 will ship with this code. I don't know yet if the plan is to also move to a single non-profile-specific cert db or not. (If not, that makes things slightly more annoying for us.)

There are three things in the NSS db that we want to be shared across all apps:

• Client-side certificates for authenticating to websites/VPNs/etc
• The list of trusted CAs
• The list of "invalid" (unsigned, expired, mismatched, etc) server certificates that the user has accepted and doesn't want to be prompted about again.

GnomeKeyring is in the process of adding SSL certificate support via PKCS#11 (GnomeKeyring/Cryptoki), which will support all three of the things listed above. So there are two ways this could end up fitting together:

• GnomeKeyring becomes the owner of the certificate database. Firefox (and everyone else) uses PKCS#11 to talk to it.

• Firefox keeps using its own (now-shareable) cert db, GnomeKeyring and other NSS-using apps share it, and non-NSS-using apps use PKCS#11 to talk to GnomeKeyring.

Another issue: who is responsible for creating confusing SSL-related dialogs ("this cert has expired", "this cert doesn't verify", etc)?

Cache

As with passwords and cookies, Firefox stores its cache non-shareably in the profile dir. Mozilla bug 135061 covers making the cache shareable, but no code has been written.

Sharing the cache is less critical than sharing the other components; everything will still work without shared cache, it just may be slower.

The possible solutions here are similar to the cookie ideas.

Proxy settings

Firefox's proxy settings are part of its general user preferences, stored non-shareably in the profile dir. (In constrast to the other bits of data above, Epiphany actually uses the GNOME proxy settings from GConf rather than doing the same thing as Firefox. openSUSE has a patch to make Firefox use GConf as well.)

GNOME doesn't currently support proxy auto-detection at all, and it allows you to configure proxy auto-config but does not provide an implementation of it. Proxy auto-config requires javascript and is therefore "tricky". People have proposed having out-of-process daemons like gnome-proxy that do the javascript bits, but this isn't fabulous because proxy-auto-config answers are completely uncacheable, so you'd have to call out of process for every single HTTP request. (Then again, the out-of-process call will presumably be much faster than the HTTP call, so maybe it doesn't matter.) Another possibility would be to dynamically load in a javascript interpreter if proxy auto-config is configured. libproxy comes to mind here also.

Other?

Is there anything else that needs to be shared?