[whatwg] Embedding images within editable content

[ddailey]

Observe the following:
http://granite.sru.edu/~ddailey/svg/clipembed.html

In IE 4 - 7 (with the Adobe SVG plugin enabled), the end user can select an 
image from her own hard drive using a file upload.
In IE 4, I had a similar thing (sans SVG) that worked also in Netscape. It 
doesn't work in the other (more standards compliant?) browsers though, and 
folks have cited the "obvious security reasons".

I had complained a year or two ago here that the spec no longer seemed to 
enable this.  I recall someone becoming quite indignant that an author would 
even WANT to allow users to have access to images. The reason for the 
security concern as well as the indignation eluded me, and the security 
seems not to be SO terrible, I thought, if old Netscape and comparatively 
new IE7 still allowed me to do it.

The ability of the browser to be able to support user-selected image content 
(without making a roundtrip to the server which to me seems like a bigger 
security risk than having local images displayed and manipulated ) seems to 
be at the core essence of what I would define as "web hypertext 
applications".

Hixie, responded to this thread a year or so ago, with supportive remarks 
(that I confess I didn't totally understand) saying that it looked as though 
there would be a way to do this through some mechanism that I gathered was 
outside the scope of WHATWG or HTML5.

While we're on the subject, I would really like to be able to read pixel 
values from local images by plugging them into (as through a input 
type=file) a <canvas>. Having access to pixel values, allows certain filter 
effects to be defined in JavaScript rather than relying on the preexisting 
filters build into canvas and SVG. Not only that but analysis of image data 
(as in scientific image processing) would be enabled.

Overall, while I respect the need for security, I think functionality is the 
primary objective and that security should be designed around functionality 
rather than the reverse. Let's make that a design principle!

cheers
David

----- Original Message ----- 
From: "Tab Atkins Jr." <jackalmage at gmail.com>
To: "Martin Atkins" <mart at degeneration.co.uk>
Cc: <whatwg at whatwg.org>
Sent: Monday, December 22, 2008 2:39 PM
Subject: Re: [whatwg] Embedding images within editable content


> On Mon, Dec 22, 2008 at 1:33 PM, Martin Atkins <mart at degeneration.co.uk> 
> wrote:
>> However, I'm not sure what the solution is here. If contentEditable was a
>> "real" form widget you could imagine it supporting a multipart/form-data
>> upload of all of its contained images, or something. However, as long as
>> client-side code is manually shifting the data to and from real widgets 
>> it's
>> not clear how to do this since you can't just create a file-upload 
>> control
>> with the filename pre-populated and submit it transparently.
>
> You can't create a file input with the filename pre-filled for obvious
> security reasons, but you *can* still do some clever stuff here.  In
> order to add a picture you'll probably need them to go through a file
> dialog anyway to select the picture, and you can make this *actually*
> be the file dialog of a hidden file input.  You can then move this
> input around in the DOM without clearing its value, and submit it
> transparently.
>
> It's a bit hacky, but hey, web security is Serious Business.
>
> ~TJ
>
>