W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] Uploading directories of files

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 11 Dec 2009 15:11:45 -0800
Message-ID: <63df84f0912111511w42bdbfaas32343ecbfef74df6@mail.gmail.com>
2009/12/11 ddailey <ddailey at zoominternet.net>:
> Circa 1999 I built a little thingy: a client-side animation studio. It
> allowed users to point to an image file in local file space. Then I would
> preload the file, parse the path name and go looking for images with
> consecutively numbered filenames in the same directory by attempting a
> preload and checking the status of that -- hence allowing me to "upload" to
> the local machine a series. Once the sequences had been identified and
> loaded into the client-side app, the user then rearranged the sequence via
> GUI to create the perfect animation which was then bundled as the source of
> a new web page, complete with javascript and timing variables. It allowed
> the GUI calibration of all such parameters. It was pretty cool (and
> intensely useful for my students), but I realized as I was building it that
> being able to troll through a user's filenames was a bit of a security risk,
> since I could have shipped the files somewhere without the user's
> permission. I even recall asking some browser gurus about it, but they
> seemed largely unconcerned at the time. The miniapp worked in Netscape and
> IE (with a little tweaking).

I'm fairly certain that any of the major browser vendors would be
quite horrified if this worked today. I.e. if the page could just grab
arbitrary files from the users file system. Occasionally people store
private data there ;)

However I don't think it's ever been the case that you could actually
grab image data and send it the way you're describing. While it might
have been that you could *display* images from arbitrary locations on
the users file system, I'd imagine you couldn't actually grab the
image data.

> Some years later it stopped working everywhere, and I discovered to my
> horror that the nasty "standards" folks had disabled client-side image
> processing altogether, requiring instead that users send all their images to
> my server for them to be able to even see their own files in the browser --
> ?ahh progress! And all in the name of privacy! How charming.
>
> I really do think that client-side image processing is a useful thing: hence
> folks development of VML, SVG, Silverlight and Canvas. Allowing us to access
> our pictures in a browser app does make sense if there is some way to enable
> it.

The good news is that this is working again! You should be able to
write the same application using modern standards. The only difference
is that users will have to attach all the relevant files, rather than
just the first one (this works around the security problem you mention
above). However if the files live in the same directory, this can be
accomplished with just opening the filepicker once.

Here's a couple of demos:
http://hacks.mozilla.org/2009/12/firefox-36-fileapi-demo-reading-exif-data-from-a-local-jpeg-file/
http://hacks.mozilla.org/2009/12/multiple-file-input-in-firefox-3-6/

/ Jonas
Received on Friday, 11 December 2009 15:11:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:54 UTC