- From: ddailey <ddailey@zoominternet.net>
- Date: Mon, 22 Dec 2008 15:53:05 -0500
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@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 > >
Received on Monday, 22 December 2008 12:53:05 UTC