Smarter than the average Pierre: The Life and Times of an Icon URI Scheme

It all began with a bug report complaining about the then dry and unvarnished FTP and file directory listing pages in Chrome [1]. The bug compared Chromium's vanilla listing pages to Firefox's respective pages; clearly Mozilla had put more effort into prettying up these pages.

Figure 1: Firefox 3.5.3 file directory listing page

Figure 2: Chrome 4.0.221.6 file directory listing page

One of the most significant shortcomings of this page was the lack of icons for files and folders. In fact, folders in Chromium's listing pages were only distinguishable from files by their trailing slash.

I decided to tackle this bug as I really like Firefox's presentation of these pages. Out of curiosity I took a look at the source code for Firefox's listing page and found out that they are using a custom URI scheme moz-icon to specify the icon images in the listing page HTML.

/**
* nsIIconURI
*
* This interface derives from nsIURI, to provide additional information
* about moz-icon URIs.
*
* What *is* a moz-icon URI you ask?  Well, it has the following syntax:
*
* moz-icon://[ |  | ]? ['?'[]]
*
*  is a legal file: URI spec.  You only need to specify a file: URI inside the icon
* if the file you want the icon for actually exists.
*
*  is any filename with an extension, e.g. "dummy.html".
* If the file you want an icon for isn't known to exist, you can omit the file URI, and just
* place a dummy file name with the extension or content type you want: moz-icon://dummy.html.
*
*  is of the format:   stock/
*
*  is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'.
* XXXcaa Should these considered platform dependent or can we share and document them?
*
* Legal parameter value pairs are listed below:
*
*   Parameter:   size
*   Values:      [ | button | toolbar | toolbarsmall | menu | dialog]
*   Description: If integer, this is the desired size in square pixels of the icon
*                Else, use the OS default for the specified keyword context.
*
*   Parameter:   state
*   Values:      [normal | disabled]
*   Description: The state of the icon.
*
*   Parameter:   contentType
*   Values:      
*   Description: The mime type we want an icon for. This is ignored by stock images.
*/

Interestingly enough, this scheme is web accessible --meaning that any web developer can use this scheme as the src for their Image objects in their HTML and JavaScript code. What's great about this scheme is that it allows developers to present platform specific icons to users. For example, <img src="moz-icon://.zip?size=16" /> would resolve the icon used by the operating system for the zip filetype.

Chromium also has a similar URI scheme for retrieving platform icons. If you look at the downloads DOM UI page, Chromium uses chrome://fileicon with a file path query to retrieve the icons for respective downloaded items. This scheme is not web accessible. The chrome:// URLs have special security privileges in Chromium that would prevent us from exposing the chrome://fileicon scheme in the manner of moz-icon. We could, of course, create a new similar scheme that would be web accessible for the use of developers and file listing pages alike.

Discussions in the Chromium-dev mailing list led to a suggestion that this "icon" URI scheme should become an open standard that every browser could implement. So I decided I would give this standardization business a shot.

The process for registering a URI scheme works as such:

Propose the scheme to the Public Webapps W3 mailing list [2] for feedback
Write a URI scheme registration template (usually contained in an Internet Draft) describing how the new scheme works. Internet Drafts must conform to the Guidelines for the Authors of Internet Drafts [3]. The registration template must conform to the Guidelines and Registration Procedures for New URI Schemes [4]
Send a copy of the template (or containing document) to the URI review mailing list [5] as well as any other relevant mailing list requesting a review
Once any review issues have been addressed, submit the document to IANA [6] specifying whether provisional or permanent registration is required.
If all goes well the URI will get registered and appear on the IANA registered URI schemes page [7]
Profit!

The entire process is structured and very iterative. Peer reviews are required to assure that the new scheme will be useful, that it is well specified and that all security risks are considered.

After this long and arduous process, I managed to get provisional registration for the Icon URI scheme [8]. W00t! You'll find it listed on the IANA URI Scheme page at least until December when it expires.

Well it's nice to have an Internet Draft for the Icon URI scheme but it would be nicer if we had an implementation of the scheme running in a modern browser.

So I wrote a prototype implementation [9] in Chromium to help move the scheme forward. Unfortunately, there were concerns that added potential security risks of this scheme outweigh the benefits. Security concerns were addressed in the draft, however it would be tricky to assure that this scheme could not be used to determine what applications a user has installed by some sort of user interaction attack. With Chromium being a security first type of browser, it would seem that the shiny new web accessible Icon URI scheme may not be the best fit. Sigh.

Well that was a whole lot of yak shaving! Didn't this start with a simple bug request for icons in file listing pages?

I plan to let the Icon URI scheme expire at the end of the year in light of Chromium not using it. It would have been a nice feature, but it was hardly a necessity. The original use case bug for this scheme can be resolved in other ways. I wrote a patch that adds icons to the Chromium file and FTP directory listing pages. There are 3 types of icons: file, folder and parent folder. The icons are hard coded as data URI into the HTML.