W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2011

[whatwg] Behavior when <script> is removed from DOM

From: Yehuda Katz <wycats@gmail.com>
Date: Wed, 7 Dec 2011 15:55:35 -0800
Message-ID: <CAMFeDTWCaR1TSShkx8d-EkBEPTvzoMU31fCLn4qvufXAxkO0OQ@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:38 UTC