- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 27 Jan 2010 11:58:17 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Pierre-Antoine LaFayette <pierre.lafayette@gmail.com>, Adam Barth <w3c@adambarth.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapps <public-webapps@w3.org>
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