Having thought a little more about it (thank you for the feedback),
returning a reference to a custom URL handler (up to the implementation)
would resolve the security issues.
toTempURL returning... customHandler://randomData.png [any kind of
reference],
would work in the legacy platforms we're targeting, while allowing us
the flexibility
of deciding just how to store the data (be it in RAM, or in an unknown
temporary file).
Amending my proposal:
* toTempURL shall not return a direct reference to the user's hard drive
(nor temporary files).
The entire implementation of the URL string shall be up to the platform
designer,
taking necessary security precautions. The output of toTempURL would not
not be guaranteed to be persistent for any length of time, nor have other
access guarantees.
Boris Zbarsky wrote:
Charles Pritchard wrote:
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.
Even worse, doesn't this allow placement of known bytes in a known
location on the user's hard drive without the user's knowledge?
That's an excellent first step in an exploit; I would be loath to
implement something like that in a browser...
-Boris
