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

2010/1/27 Maciej Stachowiak <mjs@apple.com>

>
> 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.
>
>
Yes, I was thinking that the "stock image" seems like something that should
not be standardized for that reason. Mozilla supposedly has things like: *
moz-icon://stock*/tab-new?size=menu. For example.


> 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.
>

I've been looking into this. A web application should never be able to
download the contents of an icon URI. The main thing to prevent is the
canvas 2D context using getPixelData or toDataURL to retrieve the data of an
image with an icon URI that has been painted onto the canvas. This one is
known (
http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html
).

Another more subtle exploit was described to me by Chromium's Glen Murphy:

The only other attack I can think of off the top of my head (which
also exists for cross domain images) is super contrived as it exploits
vision and relies on user interaction:

1. Assume that the 'no app' icon has a pixel at 8,8 that is color A
(e.g the middle of a blank page icon).
2. Assume that the app you want to detect has an icon with a color B
pixel at 8,8.
3. Set it up so that there are two links of color A and B, each with
the 8,8 pixel of the icon stretched as a background.
4. This makes only one of the links visible, those links can then
entice the user to click.

<div style="-webkit-border-image: url(icon://file.type) 7 7 8 8 repeat
repeat; width:200px; height:20px; border:1px;">
 <a style="color:B;" href="#" onclick="alert('you do not have X
installed'); return false;" />free pony!</a>
</div>
<div style="-webkit-border-image: url(icon://file.type) 7 7 8 8 repeat
repeat; width:200px; height:20px; border:1px;">
 <a style="color:A;" href="#" onclick="alert('AHAR! You have App XXX
installed! How embarassing for you!'); return false;" />free pony!</a>
</div>

However this is a bit of a stretch. You could just as easily trick people
into telling you what applications they have installed through some sort of
interactive content, or simply by asking.


> 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.
>
>
I'm not sure why you believe that the icons must be the same size. 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.

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.


> 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.


>
> Regards,
> Maciej
>
>
Thanks!

-- 
Pierre.