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

On Wed, Jan 27, 2010 at 11:44 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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.

I agree with Maciej. I have a hard time seeing a use case that doesn't
originate in File objects, so being able to get the icon directly
there seems like a safer way to go.

/ Jonas

Received on Wednesday, 27 January 2010 19:59:10 UTC