- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 7 Dec 2011 12:01:01 -0800
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
Received on Wednesday, 7 December 2011 12:01:01 UTC