[whatwg] access to local path in input type="file"
ddailey at zoominternet.net
Sat Mar 22 06:16:11 PDT 2008
timeless replied to my concern:
me>> In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the
>> to change the src attribute of an image based on her perusal of local
>> space. Opera 9.5 doesn't seem to allow access to the path data necessary
>> accomplishing this rollover effect, and I suspect that may be how it is
>> supposed to be according to emerging standards. That is the situation
>> the HTML file is stored on localhost.
timeless> The web changed, today firefox only provides the leafname, not the
> full path (this is a good thing for security/privacy reasons), and we
> don't allow remote access to local content (this is a good thing).
> Security Error: Content at
> http://granite.sru.edu/~ddailey/imageUpload.htm may not load or link
> to file://localhost/78255.png.
Actually, when I use Firefox 2.0012, the script contained in that file (
http://granite.sru.edu/~ddailey/imageUpload.htm) actually results in
displaying the local path name in the <input> on that page, as well as in
the alert. The data seems to be available, but merely useless for the
application at hand.
me>> While I understand the possible risk of exposing a path name of the
>> file system to script, the various use cases of allowing users to access
>> local images within HTML, the <canvas> tag and within <svg> all seem
>> self-evident to me. Is there some standard workaround to allow the user
>> change the source of an image on a web page to one that is locally
timeless> in the modern world, you shouldn't be able to embed local images
> remote content.
> if a user wants to see a preview an image they can use their os, file
> picker, favorite image viewer, etc.
Perhaps I should have spelled out the use cases a bit more: I am not
interested in previewing the thing, rather I'm interested in working with it
application style-- as in photo editing it (in a web-based application)
warping it (as with SVG clipPaths in another of the examples I illustrated)
in morphing two images together using triangulations, clipPaths, warping,
and opacity. I'm interested in doing image analysis, using the <canvas> tag
and producing chromatic histograms, in calcuating differences between two
images, in finding median images from a collection. Yes, I know one can buy
software (or even freeware) and install it, but I'm interested in among
other things in supporting scientists who wish to collaboratively edit one
another's images on the web, in allowing a person to create and preview
morph and animation sequences locally using remote script. The end user
maintains copyright on the images, the script writer retains copyright (and
closed source if desired) of the script itself. The app runs in the client
rather than on the server, hence allowing the server to play server games
rather than doing image processing.
The first application I developed (circa 1999) using this ability to access
pictures on localhost was an animation generator that allowed the user to
import a series of jpg files (as from a movie clip) and to create a small
video using setTimeout from which the source code (HTML and script) was
generated by the app so that the end user could create the video without
herself having to script. The thing worked in the two dominant browsers at
the time. Last I looked there was no consensus between browser companies on
formats for <video> in HTML so this still seems like the only way to proceed
for the task at hand short of paying bigbucks.
> you can silently auto submit the image and send them back a version.
The privacy (and copyright) exposure to the end user of having to submit the
image to a server, have that stored temporarily on the server and then make
a round trip back to the local machine seems far worse that the privacy risk
of having script read the path of a file the user has already consented to
Perhaps we need a new <img type="local-file"> to cover the use cases??? What
I'm ultimately interested in is not really the sort of thing one would
expect to use <form>s for -- neither is doing content analysis inside a
<textarea> however. Those just happen to be the tools that <html> provides.
I know that under discussion in HTML5 is some amount of ability to read and
write files locally. Would script access to local images be included in that
> modern browsers will not expose path, only leaf.
Well then I guess FF2.0012 and IE 7 are not considered modern. My FF3
installation seems flaky so I can't get it to launch. Opera 9. shows only
the leaf but FF2 shows the whole path.
More information about the whatwg