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

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller <erights at google.com> wrote:

> Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
> header, the API you suggest below can be fully implemented as a library.
>
> Since any response that parses as JavaScript has no same origin protection
> anyway, rather than carve out a special case for JSONP, should we waive
> the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse as
> JavaScript for XHR requests in general? If not, what justifies carving out
> a special case for JSONP?
>

In the general case, executed JavaScript does not expose the content.
Existing JSONP implementations obviously work as libraries, but
implementing them robustly is non-trivial. Given that we know that this
subset is already secure (or at least, doesn't add any new security
issues), creating an explicit API that eliminated the library fiddliness
(and need for registering a global function) would be great.


>
>
> On Wed, Dec 7, 2011 at 5:20 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>
>> 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
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>