Re: Steps to creating a browser standard for the moz-icon:// scheme

On Jan 27, 2010, at 4:49 AM, Pierre-Antoine LaFayette wrote:

> 
> 
> 2010/1/26 Maciej Stachowiak <mjs@apple.com>
> 
> On Jan 26, 2010, at 7:08 AM, Pierre-Antoine LaFayette wrote:
> 
>> Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers.
> 
> To gain an interoperability benefit, we would presumably need to define the set of icons available, right?
> 
> 
> Why do you think that? Can you please elaborate? The icons should be the native icons for a particular file type. What possibly need to define is size, what to do if the filetype is unknown, whether we should include Browser specific "stock" image identifiers to allow the use of Browser themed icons, etc.  

For the stock images, how can you ever reasonably rely on them without knowing which ones are available? Getting a generic "unknown" image in those cases is not likely to be good fallback.

Side note on security: it has to be impossible to determine the contents of any image retrieved via such a URL, or even to detect if any two are different, or it becomes possible to probe the filesystem or probe the user's set of file type bindings (if it varies per OS), both of which would be privacy violations. This implies a constraint that all icons (including unknown and missing file) have to be the same size, which may not match the native look of all operating environments. Probing file existence may also be doable via a timing attack, but I am not sure that is solvable.

Perhaps icons for specific existing files (rather than a file type) should be retrieved using a File object rather than a path. If the Web app has a File object then it already has access to the contents of the file, so there is no probing risk. You could even give it access to the bitmap of the icon in such a case (for example by making it usable on the <canvas> without tainting).

The path thing is also a poor fit for operating systems that do not have a user-visible concept of file paths, such as iPhone OS. It could lead to writing inappropriately platform-dependent code given the path format differences and filesystem layout differences among operating systems.

Regards,
Maciej