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

On Jan 27, 2010, at 6:00 AM, Pierre-Antoine LaFayette wrote:

> 
> I'm not sure why you believe that the icons must be the same size.

Because you can get the width and height of an <img> element without any security checks. Even if the width and height properties of HTMLIamgeElement did not expose this (and they do), examining the layout would expose it.

> The web application should not know anything about the icon displayed to the user other than the URI it used to display it. If this is the case, then filesystem probing won't occur. Can you give me an example of how one would probe file existence of an icon URI? The only thing I can think of is if an application used an icon URI with an arbitrary file path that whose existence is probable and simply got the user to confirm that an icon (or a pixel/color) is shown somehow.
> 
> 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).
> 
> How would the syntax work for <img src="?" /> tags. Isn't the point that we don't want the web application to have access to the contents of the file? How does it obtain the File object? Wouldn't it have to probe for the File object it wants? I'm not very familiar with the File object so if you could elaborate it would be greatly appreciated. 

You get a File object through a file being explicitly selected by the user, via <input type="file">. There is no opportunity for any kind of probing attack. My suggestion is that you could get a magic restricted-use URL for that file's icon from the File object, the same as you can get a URL for the file's contents. Alternately, the File object could give you an icon: URL that specifically identifies that file's icon. This is safer than letting Web applications get the icon for any file they can guess the path to.

> 
> For the use of paths in icon URIs, I see it as not really useful for web applications but more for Browsers (FTP and file:// directory listings) and possibly user created local HTML pages. 

There's no need for interoperability in mechanisms that are only needed for features that are built-in to the browser. And I note that it's clearly not needed for FTP directory listings - you don't actually want such files to map to a real file path. 

>  
> 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.
> 
> True. That is why I imagine that web applications would be using the icon:<extension> syntax (and maybe a Browser specific stock image syntax) whereas Browsers and local HTML pages would benefit from the file path syntax. 

I don't think there is a need to standardize features solely for the benefit of browsers and local HTML pages, particularly if they may be a security risk when used in remote Web pages.

Regards,
Maciej