- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 27 Mar 2009 16:38:42 -0700
toTempURL( format ) returns <string> temporary file path. I'd like to solicit feedback from the community about a work-around we're [likely] including in one of our Internet Explorer Canvas implementations. Legacy clients may have terrible support for extensibility. I think we know which clients I'm referring to. toDataURL is a wonderful, powerful tool and we love it. However, with some HTML consumers, base 64 encoded images are not usable in the global scope. To get around this, we are using toTempURL(), to save an image to the local Temporary Internet files directory. Then, we can do <img src="">, or set CSS background: url's, and do other such wonderful things. In browsers that support base64 encoding, we simply have toTempURL aliased to toDataURL(); The draw back of this scheme is that Canvas can now write to a users hard drive. A Denial of Service exploit could run toTempURL in an infinite loop, filling up the users temporary files directory until the browser puts a stop to the sillyness. The temporary files directory is intended to be used, to store temporary internet files. But its use (as far as I know) is limited by the client's available bandwidth. With toTempURL, its use (in Megs/Second) would only be limited by the client's computing speed (and hopefully, the browser). I'd like some feedback. I'd like a decent method of limiting a DOS exploit of toTempURL() while proposing it as a possible extension to the standard. -Charles
Received on Friday, 27 March 2009 16:38:42 UTC