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

[Mark S. Miller]

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?


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