- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 27 Mar 2009 17:22:42 -0700
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
Received on Friday, 27 March 2009 17:22:42 UTC