[whatwg] Canvas - toTempURL - A dangerous proposal - Summary

[Charles Pritchard]

Summarizing my proposal and responses:

A new function - toTempURL:

Legacy clients may have terrible support for extensibility. With some 
HTML consumers,
base 64 encoded images are not usable in the global scope. To get around 
this, we proposed
using toTempURL(), to save an image to the local temporary files 
directory, and return a reference
which the legacy client could support.

The draw back of this scheme is that Canvas would write to a users hard 
drive, known bytes, in a known location, (Boris Zbarsky)
and could also write an unrestricted amount of data.

On the latter point, Kristof Zelechovski writes:

"IFRAME where SRC='javascript:...' has the same disk full problem as
Canvas.toTempURL, and a DOS attack can also be launched simply by creating a
large array that will fill the hard drive with virtual memory. In general,
handling OOM conditions is not covered by the specification."

As for Boris' point, I found more agreement from Henk de Koning:

"I think it’s act of storing on the local hard drive that’s 80% of the 
risk. If you return a
URL that points to the exact location on the local drive, that adds to 
the risk,
but no more than any other scheme that allows script to touch the local 
drive."

I suggested to Boris, that perhaps I could tie into a custom protocol 
handler,
to hide the location of the file on the user hard drive. Obviously, this 
was not
a well thought-out response. Boris replied:

"I guess I'm not clear on one thing: you can add support for 
customHandler:// to this platform but not support for data: ? "

At this point, I conceded that perhaps trying to support "data:" was a 
better goal than trying to advocate toTempURL.
We're trying now to implement data:image/png support for Internet 
Explorer 6.0+.

There are, as we all know, some limitations to the length of a URL that 
a browser may accept.
Internet Explorer has great support (though not thorough) for plugging 
in custom URL handlers,
and we expect that we'll succeed, despite the long byte-length of a 
typical data:base64 uri.

For platforms that can not handle a base64 uri, and for whatever reason 
can not be made to do so
by throwing code at it, Ian Hickson writes:

"If it is just working around limitations .... then it seems better for 
you to define this
as an implementation- and platform-specific non-conforming extension"


A new "problem": Short data URLs.

There is likely a cost, though it could be addressed in implementation, 
in passing around toDataURL strings.
Compressing a bitmap to a png, base64 encoding it, copying the string, 
twice, and decoding it, can be expensive,
and for some implementations and use-cases, completely unnecessary.

If we could reference a short string, of a hundred or so bytes, instead 
of a very large base64 string, it may help with
memory management (and related efficiencies).

Ian Hickson writes:

"On the long term I expect once we have a File/Blob API, we'll use that to
expose the canvas data as a file."

My response, while we await such an API, is to perhaps introduce a new 
mime output for toDataURL,
one which for now will be implementation dependent, but may hopefully 
grow to see more use.
Based on the most excellent usage of css url() syntax in WebKit and Firefox:

<canvas id="myImage">.getContext('2d').toDataURL('text/css') would 
return the string:
data:text/css;url(#myImage)

Possibly in a serialized form (accepting base64 encoding, and other 
typical encoding methods).

We've instructed our data: handler to process the text/css mime-type, 
with url(#) attached,
as a reference to a canvas element available in the scope of the document.

New browser releases are using css in a similar fashion: div { 
background: url(#CanvasElement); }
By using a data: url, we can add to our data protocol handler, to 
support <img src="data:text/css;url(#)">
as well as div { background: url(data:...); }


I'll report to the group when we have a working implementation.


-Charles