Tuesday, July 17, 2007

JSONRequest.js -- from the genius of Doug Crockford

I wish there was more chatter lately about JSONRequest, and similar secure XSS proposals.


We can all think of legitimate reasons why as a developer we'd very much like to be able to request and return data from remote sites, and am EAGERLY awaiting the dust to settle on this issue. Because of the security model of XMLHttpRequest, this sort of data exchange is not possible due to the 'same origin policy', whereby the browser restricts a web page from communicating with a server of a different domain via an XMLHttpRequest (i.e. Ajax) call:

"XMLHttpRequest has a security model which is inadequate for supporting the next generation of web applications. JSONRequest is proposed as a new browser service that allows for two-way data exchange with any JSON data server without exposing users or organization to harm. It exchanges data between scripts on pages with JSON servers in the web. It is hoped that browser makers will build this feature into their products in order to enable the next advance in web application development."
IBM has a well written article discussing the issues, challenges, and proposals on the table with regard to secure cross-site scripting, and provides some insights to what we can currently implement, and what is on the horizon, including Doug Crockford's JSONRequest.js proposal:

"Here and now

A more recently developed content-retrieval technique employs communication between a page's script and a hidden iframe through its src URL's fragment identifier (the part of the URL that comes after the # sign). Scripts in the parent page and embedded iframe can set each other's fragment identifiers despite coming from different origins. An agreed-upon communication protocol is maintained between the scripts, driven by JavaScript timers that periodically fire routines to check for changes in the fragment identifier.

Because the scripts must know each other's addresses and they must collaborate between themselves to agree on a protocol, trust is ensured. Because any server interaction is local to each component and separate from the inter-script communication, cookies are not exposed.

While still imperfect (for example, it relies on an anomaly that is not a designed behavior, and polling for changes is inferior to having an event fire in response to a change), this solution comes closer to providing browser-native, secure, in-page, cross-domain communication than any other.

Note: James Burke, a developer at AOL Developer Network, pioneered the fragment identifier technique and has built it into the latest releases of the Dojo Toolkit JavaScript library."

When will any of these get implemented? I can hardly wait.

Doug Crockford proposals:http://www.json.org/JSONRequest.html
http://json.org/module

JSONRequest files:
http://www.devpro.it/JSON/files/JSONRequest-js.html

Dojo notes related to JSONRequestResponse:
http://dojo.jot.com/WikiHome/JSONRequestResponse

conversation by some of the 'Titans'...
http://www.eweek.com/article2/0,1895,1960822,00.asp



1 comment:

SEO Services Consultants said...

Nice information, many thanks to the author. It is incomprehensible to me now, but in general, the usefulness and significance is overwhelming. Thanks again and good luck! Web Design Company