[whatwg] Behavior when <script> is removed from DOM
Yehuda Katz
wycats at gmail.com
Wed Dec 7 15:55:35 PST 2011
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
>
More information about the whatwg
mailing list