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

[Jonas Sicking]

On Wed, Dec 7, 2011 at 11:27 AM, Adam van den Hoven <adam at littlefyr.com> wrote:
> 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?

Yeah. This would be very cool. Proposals more than welcome, though I
would suggest not tying it to XHR but rather have a dedicated "load
and execute this url in this sandbox" API.

Designing a sandbox API is likely a fairly large task. I believe that
ES.next might have something to that extent but I'm not fully sure.

A dedicated JSONP API is likely a lot simpler to design and could be
specced and rolled out quicker. But of course has a smaller feature
set.

/ Jonas

/ Jonas