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: Adam Barth <w3c@adambarth.com>
Date: Thu, 28 Jan 2010 00:07:37 -0800
Message-ID: <7789133a1001280007p7cb126a5pe08d4ac011f6053b@mail.gmail.com>
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?

Received on Thursday, 28 January 2010 08:08:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:22 UTC