- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 28 Jan 2010 00:07:37 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: robert@ocallahan.org, Maciej Stachowiak <mjs@apple.com>, Pierre-Antoine LaFayette <pierre.lafayette@gmail.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapps <public-webapps@w3.org>
On Wed, Jan 27, 2010 at 6:32 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Jan 27, 2010 at 6:26 PM, Robert O'Callahan <robert@ocallahan.org> wrote: >> On Thu, Jan 28, 2010 at 8:58 AM, Jonas Sicking <jonas@sicking.cc> wrote: >>> >>> 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. >> >> It can still expose which application the user has handling that file type, >> if the icon data is somehow exposed via canvas.drawImage or whatever. > > Indeed. I think we should make these urls never be considered > same-origin as any other origin. Thus a canvas would always get its > taint bit set if an icon is drawn. > > We should also return some default-sized icon for unknown types, to > make it somewhat harder to detect when no application is installed to > handle a particular file type. > > That, in combination with the fact that pages only get access to icons > for files where the user has exposed the full file contents to the > page (through drag'n'drop or <input type=file>), makes me much less > worried about privacy leaks. > > There's still some risk of privacy leak though, so i'm all ears if > others have further ideas or in general don't think this is safe > enough. Hasn't Mozilla been shipping this feature for years? Adam
Received on Thursday, 28 January 2010 08:08:34 UTC