Ten Mysteries of about:config

For a long time, Firefox, Mozilla and, before that, Netscape 4.x, supported this hidden Boolean preference:

signed.applets.codebase_principle_support

Normally, it's set to false—if you want you can set it to true. It's a poorly understood preference, so here's an explanation. First of all, the name is about as relevant as UNIX's /etc—it's so steeped in history that it's basically wrong. There's no applets at work; there's no Java at work. Mozilla has an amicable separation from Java, where Netscape 4.x was deeply wedded to that technology. Mozilla now handles its own security natively, in C/C++ code. It should be called signed.content.codebase_principle_support—one day, maybe.

This preference is used to assist developers who work with digitally signed content. It has no relation to SSL or to PGP/GPG. An example of signed content is a Web site or Web application bundled up into JAR format and digitally signed in that form.

Roughly speaking, two checks are done if digitally signed content arrives in Firefox. First, the digital certificate accompanying the content is checked against Firefox's list of known certificate authorities (CAs). If that much is fine, the maker of that content is considered authentic. Firefox then lets the content request extra privileges, ones that overcome normal browser restrictions, like access to the local disk. Usually that's done through JavaScript.

When those requests are made, Firefox throws up dialogs to the user. This is when the second check is done—it is done manually by the user. If the user agrees, the content can run with security restrictions dropped and your computer is exposed, or at least the currently logged-in Linux account is exposed.

For a developer, these checks are a nuisance. It's extra effort to buy (with real dollars) a suitable certificate for signing the content and set up the infrastructure. That should be necessary only when the site goes live.

Instead of using a real digital certificate to sign the content under development, suppose you use a dummy certificate—one that's not authentic. You can make a dummy certificate with the SignTool tool, available at ftp.mozilla.org/pub/mozilla.org/security/nss/releases. Next, you tell the browser that it's okay to accept such a dummy certificate. That's what the above preference does.

Setting this preference weakens only the first security check. You always have to perform the user-based check—at least Firefox offers to remember what you said after the first time. Setting this preference means that Firefox accepts a dummy certificate from any Web site, so use this only on isolated test equipment.

Finally, here's a simple way to set up Thunderbird access from Firefox. Set this Boolean preference to true to enable the mailto: URL scheme—the one that appears in Web page “Contact Me” links:

network.protocol-handler.external.mailto

An example of a mailto: URL is mailto:nrm@kingtide.com.au. Secondly, set this string preference to the path of the Thunderbird executable or to the path of any suitable executable or shell script:

network.protocol-handler.app.mailto

Digging out hidden preferences is a bit of treasure hunt. Many are documented on Firefox-friendly Web pages, but the ultimate authority is the source code. Preference names are simple strings, and it's possible to create your own. Many of the extensions that can be added to Firefox dump extra preferences into the preference system. As long as the extension remembers to check and maintain those preferences, they have the same first-class status as the ones that have meaning for the standard Firefox install.

Remember, you always can save a copy of your prefs.js file before an experimental session with about:config and restore the saved copy if things get too weird. Happy config hacking!

Resources for this article: /article/8139.