- From: Daniel Cheng <dcheng@chromium.org>
- Date: Wed, 20 Oct 2010 17:20:57 -0700
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