- From: Yehuda Katz <wycats@gmail.com>
- Date: Wed, 7 Dec 2011 15:55:35 -0800
Yehuda Katz (ph) 718.877.1325 On Wed, Dec 7, 2011 at 3:43 PM, Jonas Sicking <jonas at sicking.cc> wrote: > On Wed, Dec 7, 2011 at 12:39 PM, Yehuda Katz <wycats at gmail.com> wrote: > > Yehuda Katz > > (ph) 718.877.1325 > > > > > > On Wed, Dec 7, 2011 at 12:29 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > > > >> On 12/7/11 3:22 PM, Joshua Bell wrote: > >> > >>> This can't be implemented in JS today (e.g. as a shim) since that > >>> "evaluate > >>> this script text in this new global sandbox" bit isn't present. > >>> > >> > >> It can sort of be done via opening a new window and setting its opener > to > >> null before injecting some <script> tags into it. Modulo popup blockers > >> and crappy user experience, of course.... > > > > > > Or evaluating the script inside a worker, perhaps? > > Workers aren't great sandboxes. They already have access to shared > workers and XHR. Soon they will get access to IndexedDB too. So > there's lots of damage they can cause. > > If we want to run untrusted code then I think we need to have an API > specifically designed for that. > > If we want an API for loading JSONP data apart from the sandbox (which > I think is needed), then we should have an API specifically designed > for that. It's possible that we can reuse XHR here and just adjust the > security model when the returned data is JSONP. > You would at least want to execute them in a lexical scope containing the callback, so that the callback did not need to be installed on the global scope. > > / Jonas >
Received on Wednesday, 7 December 2011 15:55:35 UTC