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

On Wed, Dec 7, 2011 at 3:55 PM, Yehuda Katz <wycats at gmail.com> wrote:
>
> 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.

Ideally we wouldn't execute anything. We'd just parse the JSON literal
and hand that back. That is what'll give us safety.

To make a concrete, but hideous, example:

We could add xhr.responseType = "jsonp".

When this is set, the XHR object will look for contents on the following form:

<js identifier> '(' <js-literal> ')'

followed by an optional ';'

When the contents follows that syntax, the XHR object parses the
js-literal and sets it's .response property to the result.

Other than that the XHR object works just as it currently does. I.e.
it fires progress events, load events and readystatechange events as
normal.

This way no JS execution happens, and no global names need to be set
up. The <js identifier> part is simply ignored other than to check
that it's a valid js identifier.

I believe we can come up with something better than this, but it's a
demonstration of what's technically feasible.

/ Jonas

Received on Wednesday, 7 December 2011 17:20:15 UTC