W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 27 Jan 2010 18:32:40 -0800
Message-ID: <63df84f1001271832g4c75edbdi15cab6d26b54985d@mail.gmail.com>
To: robert@ocallahan.org
Cc: Maciej Stachowiak <mjs@apple.com>, 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 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.

/ Jonas
Received on Thursday, 28 January 2010 02:33:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT