W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2010

[whatwg] Exposing filenames in DataTransfer

From: Daniel Cheng <dcheng@chromium.org>
Date: Wed, 20 Oct 2010 17:20:57 -0700
Message-ID: <AANLkTik0xmqRjktCy7Fp5Acf-67pFFdZaym7WfUr1dDP@mail.gmail.com>
To clarify, I wasn't proposing that pages need to know details of a
particular OS. Things like "text/plain", "text/uri-list", "text/html", etc.
are automatically mapped by the UA to whatever the appropriate platform
idiom is.

I just thought it would be useful to also expose things that the UA itself
doesn't natively understand--it just gets passed through to the web content.
However, this led to the above problem with filenames being exposed. This
can, to some extent, be mitigated by blacklisting certain types; I'm just
wondering if people feel that the additional utility is worth the risk of
potentially exposing file paths because of a chatty file manager, or if
anyone has any ideas on how to mitigate this risk.

Daniel

On Tue, Oct 19, 2010 at 02:29, Anne van Kesteren <annevk at opera.com> wrote:

> On Tue, 19 Oct 2010 00:15:27 +0200, Daniel Cheng <dcheng at chromium.org>
> wrote:
>
>> Sorry, I'm using "properties" as a generic term for different types of
>> data that might be set in a drag. A lot of file managers try to be helpful
>> and
>> populate alternative metadata for a file. Some of this metadata contains
>> file system paths. If the web dragging clipboard mirrors the native
>> dragging clipboard, then the metadata will be visible to web apps. In this
>> example, if you were on Linux with my patch, you could call
>> event.dataTransfer.getData("x-special/gnome-icon-list") while handling a
>> drop and the returned string would contain the file system path.
>>
>
> It seems wrong to expose it in a way native to a particular operating
> system so it seems better to filter it out for now even if that is more
> work. We should keep web platform APIs OS-independent.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101020/69f979f0/attachment.htm>
Received on Wednesday, 20 October 2010 17:20:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:01 UTC