W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: Possible addition to file API

From: Eric Uhrhane <ericu@google.com>
Date: Mon, 23 Aug 2010 08:24:49 -0700
Message-ID: <AANLkTinFJmM+UznQgbUfTEt6QqY1GuhpCRO6ngVSdQoE@mail.gmail.com>
To: J David Eisenberg <jdavid.eisenberg@gmail.com>
Cc: public-webapps@w3.org
Take a look at this discussion of XHR.responseBlob:


On Sat, Aug 21, 2010 at 12:39 PM, J David Eisenberg
<jdavid.eisenberg@gmail.com> wrote:
> At present, the only way a web page can read a file's binary data via
> the File API (http://dev.w3.org/2006/webapi/FileAPI) is if the person
> reading the page enters the file name in an <input type="file"/>. The
> API applies to only local files, if I read it correctly. Is it
> possible to extend the spec to allow a script to read any file that
> can been loaded as part of the HTML page, such as an <img/>? This
> extension would let web pages read the EXIF data of an image that is
> part of an <img> element; a very useful capability for web apps.
> Similarly, you could access metadata from a file destined for an
> <audio> or <video> element. The spec seems to suggest that this is
> possible: http://dev.w3.org/2006/webapi/FileAPI/#url , but is it
> implemented in any browsers?
> I understand there are good security reasons for restricting file
> reads; you don't want someone else's web page to be able to go
> willy-nilly through your local hard disk and send all the information
> back to the Bad Guys. But this scenario is different; if you have
> loaded an <img/>, you must already have read permission for it, and
> its data is there in the browser. I'm just asking to be able to access
> its bits.
> Precedent: think of <link rel="stylesheet" href="blah.css"/>; you have
> access to all the elements in that file via the DOM, and there's no
> security issue involved, even if it's a cross-domain href. That's
> because it is *not* an arbitrary file on the user's local file system;
> it's one that the author has explicitly specified and is allowed to
> read.
> I think my suggestion here meets the same criteria. Am I missing
> something obvious on the security front?
> The back story for this idea (you may safely skip this portion if you
> are not interested): My brother and I have just spent the past few
> days looking over several large boxes of photos that my mom had stored
> away. Most of them had nothing written on the back, so we had no idea
> of where or when the pictures were taken, nor who the people in them
> were, nor what the picture meant to Mom. Obviously, "metadata
> matters." This told me that I need to start using the "comments"
> feature in GIMP to add descriptions to my photos.
> A few days ago, some of our family got together and I told my cousin
> George that I'm going to start doing this. He said that was nice, but
> the only way to get the data out is to use a program similar to the
> one that you used when editing the image, and most people won't have
> that. So I thought, "You know, it would be great if you could get
> access to an <img/>'s EXIF data from the browser."
Received on Monday, 23 August 2010 15:25:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC