- From: Yehuda Katz <wycats@gmail.com>
- Date: Wed, 7 Dec 2011 11:47:20 -0800
Yehuda Katz (ph) 718.877.1325 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? > This would be amazing and make it easier to write JSONP code as well. > > Adam >
Received on Wednesday, 7 December 2011 11:47:20 UTC