[whatwg] access to local path in input type="file"

[ddailey]

timeless replied to my concern:

me>> In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the 
user
>> to change the src attribute of an image based on her perusal of local 
>> file
>> space. Opera 9.5 doesn't seem to allow access to the path data necessary 
>> for
>> accomplishing this rollover effect, and I suspect that may be how it is
>> supposed to be according to emerging standards. That is the situation 
>> when
>> 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 
local
>>  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 
>> to
>>  change the source of an image on a web page to one that is locally 
>> stored?
>

>
timeless> in the modern world, you shouldn't be able to embed local images 
from
> 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 
make visible.

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 
capability?


>
> 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.

regards,
David