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

[Adam van den Hoven]

On Sat, Dec 3, 2011 at 9:17 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Sat, Dec 3, 2011 at 7:38 PM, Yehuda Katz <wycats at gmail.com> wrote:
> >
> > Yehuda Katz
> > (ph) 718.877.1325
> >
> >
> > On Sat, Dec 3, 2011 at 6:37 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> >>
> >> On Sat, Dec 3, 2011 at 6:24 PM, Yehuda Katz <wycats at gmail.com> wrote:
> >> >
> >> > Yehuda Katz
> >> > (ph) 718.877.1325
> >> >
> >> >
> >> > On Fri, Dec 2, 2011 at 11:30 AM, Tab Atkins Jr. <jackalmage at gmail.com
> >
> >> > wrote:
> >> >>
> >> >> On Fri, Dec 2, 2011 at 11:27 AM, Jonas Sicking <jonas at sicking.cc>
> >> >> wrote:
> >> >> > The main use case for wanting to support scripts getting appears to
> >> >> > be
> >> >> > wanting to abort JSONP loads. Potentially to issue it with new
> >> >> > parameters. This is a decent use case, but given the racyness
> >> >> > described above in webkit, it doesn't seem like a reliable
> technique
> >> >> > in existing browsers.
> >> >>
> >> >> If it's unreliable *and* no sites appear to break with the proper
> >> >> behavior, we shouldn't care about this use-case, since cross-domain
> >> >> XHR solves it properly.
> >> >
> >> >
> >> > Cross-domain XHR *can* solve this use case, but the fact is that CORS
> is
> >> > harder to implement JSONP, and so we continue to have a large number
> of
> >> > web
> >> > APIs that support JSONP but not CORS. Unfortunately, I do not forsee
> >> > this
> >> > changing in the near future.
> >>
> >> I think we can solve this in 3 ways:
> >>
> >> 1. Keep spec as it is. Pages can simply ignore the JSONP callback when
> >> it happens.
> >> Disadvantages:
> >> Additional bandwidth.
> >> More complexity for the web page.
> >>
> >> 2. Make removing scripts cancel any execution
> >> Disadvantages:
> >> Pages will have to deal with the fact that removing scripts can still
> >> cause the callback to happen if the load just finished. So the same
> >> amount of complexity for page authors that don't want buggy pages as
> >> alternative 1.
> >> Since many pages likely won't properly handle the callback happening
> >> anyway will likely cause pages to be buggy in contemporary browsers.
> >>
> >> 3. Add a new API to reliably cancel a script load
> >> Disadvantages:
> >> New API for pages to learn.
> >
> >
> > 4. Add a new API (or customize XHR) to explicitly support JSONP requests,
> > and allow those requests to be cancelled.
>
> Yes, that's definitely an option.
>
> It will be sort of a weird API since the security model will be sort
> of strange. Traditionally we say that you can't load data cross site,
> but that you can execute scripts cross site. Here we want something
> sort of in between.
>
> It could have significant advantages if it makes it easier for sites
> to do cross-site loading of data without exposing themselves to XSS
> risks.
>
> / Jonas
>

If we went for a hybrid approach, namely that XHR has a cancellable way to
call and execute some arbitrary JavaScript and sandbox the execution so
that "this" is something explicitly provided to the XHR, would we not
suddenly have a rather secure way to load any javascript in general (and
probably make things like lab.js and yepnope easier to write)? Now I can
load some javascript (say from some ad server) without giving it access to
the window object and the global scope, if I don't want to. Wouldn't this
address some of the security issues that Doug Crockford has brought up in
the past?

Adam