W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] Canvas - toTempURL - A dangerous proposal

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 27 Mar 2009 16:38:42 -0700
Message-ID: <49CD6382.8030202@jumis.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT