Kris Zyp's Questionable Assumptions

This weekend I released CrossSafe. Briefly, CrossSafe provides secure cross domain JSON requests and partially implements the JSONRequest specification (the get and cancel methods). Ajaxian covered the release and you can also read more about at the project page, see a demo, or download it. Rather than repeat the project description here, I thought it would be more interesting to describe the approach and elicit feedback on the future of secure cross site request.

CrossSafe uses nested iframes with a different domain than the parent window to setup a secure channel of communication with cross site servers. This works by passing a JavaScript object to a child frame and then using an alternate host name (like webservice.json.com) to prevent cookie access and changing the document.domain to prevent window, DOM and other JS environment access. By bringing this together, the dynamic script tag/cross site scripting approach can be used to retrieve cross site JSON data, and the scripts that are loaded from the other site are sandboxed. The parent window can retrieve data from these scripts, but the scripts can not access the parent window. This approach is also described here, but as far as I know, this is the first implementation. This implementation also follows the JSONRequest API specification, which allows you to use a standard API, and the library defers to a native implementation when it becomes available.

There is another approach for accessing cross site data securely that uses iframe proxies called fragment identifier messaging (FIM). Dojo has a good implementation of this approach. However, I believe this approach suffers from a couple of problems. First, it requires a level of server cooperation that has not been widely implemented yet. Servers must have Dojo’s iframe proxy script available on their site. On the otherhand, CrossSafe requires that server implement callback parameters which is already available with web services from Yahoo, Flickr, Codinginparadise.org’s transclusions, and JSPON. FIM also relies on polling to transfer data. Second, I have not done any tests to verify this, but I would be inclined to believe this is a slower approach as well. However, that said, I am interested in possibly implementing the JSONRequest.post method using this approach. The JSONP/XSS technique is only capable of making GET requests. The FIM approach on the otherhand does support POST. If I integrated Dojo’s FIM implementation in CrossSafe, all three JSONRequest methods could be available, and it could just be recommended to use the get method whenever possible because of the performance and interopability advantages.

Another issue with these approaches is that there are no real standards about how to do these requests since they require server cooperation. With the JSONP/XSS callback approach has seen various callback parameter names used including jsonp, callback, and jsoncallback. CrossSafe supports changing the parameter name, but it would be great if we could standardize this. Despite the fact that the original JSONP article proposed jsonp, I propose that we use the parameter name of callback. This is very succint and clear, and let’s face it, Yahoo is the most significant provider for JSON out there, and this is the parameter name they use.

The FIM approach could also use standardization. Dojo has the best implementation that I know of, but I believe OpenAjax.org is currently working on standardizing this as we speak. At least I hope…

Let me know if you have any thoughts.