This Weekly Web Hack is the third in a four part series on cross-domain scripting. Moving even further away from the "traditional" solutions, this article discusses a few competing schemes to extend cross-domain data access and finally reveals a proof-of-concept Greasemonkey script for lifting all cross-domain restrictions.
I've already written a thorough introduction to cross-domain Ajax, and described how to do cross-domain Ajax via Flash using my SWFHttpRequest Flash/Ajax Utility. So I'll assume you have a pretty solid understanding of XMLHttpRequest, the same origin policy, Adobe's approach to cross-domain data access (called crossdomain.xml), and their collective effect on the cross-domain scripting landscape.
The policies controlling who can access what and from where have been in place for years now, but that's not to say that nothing has been done. Almost as long as Ajax has been a buzzword, various voices on the Internet have spoken out against the overly restrictive same-origin policy.
He goes on to say that:
More recently, the W3C has posted a working draft detailing Access Control for Cross-site Requests. Although it doesn't mention JSON, it does include a number of Douglas' recommendations regarding Cookies and HTTP headers.
Kris Zyp has a good writeup titled W3C - Enabling Read Access for Web Resources in which he explains the (minimal) impact this proposal has on XHR security and offers a side-by-side comparison of the JSONRequest and W3C proposals.
According to the comments Mozilla's bugzilla bug 389508, this has already been implemented in Mozilla's SVN trunk as of July 2007 following these design details. All signs indicate that cross-domain XMLHttpRequest calls will be available in Firefox 3 - which is in public beta at the time of this writing.
Given that the cross-domain policy file used by the Flash runtime already allows third-party access to web services, one has to wonder whether the W3C draft is too little too late. After all, using SWFHttpRequest, it's trivial to make cross-domain requests using flash as an intermediary.
The answer, as is too often the case, is yes and no. It's certainly nice that there is an attempt to finally broaden the scope of cross-domain accessibility. Here are a few pros of the W3C proposal:
However, it falls short in the following ways:
The biggest problem with both Adobe's scheme and the W3C's option is that they require third-party buy-in. The service provider has to explicitly agree to allow other sites to access their data. In nearly all discussions on XHR security, it's considered blasphemy to suggest that one site should be able to access and utilize another site's resources without the latter condoning the activity.
What the Internet needs is inversion of access control. Rather than the service providers publishing who can use what, it should be up to the end-user to decide whether the web-application they're using should be able to make those requests (provided the third-party hasn't already explicitly allowed it).
That is, rather than outright preventing somedomain.com from making requests to someotherdomain.com, maybe we should ask the user whether they'd like to allow it? Coming up with a UI to make this painless for all parties is the tough part. Nobody wants to see "This web application is trying to access someotherdomain.com, Cancel or Allow?"
Greasemonkey makes headway in this department, providing a function called GM_xmlhttprequest, which can be used to issue cross-domain requests to anywhere. Unfortunately, it doesn't follow the W3C's XMLHttpRequest specification, so it's a pain to use with Ajax libraries out-of-the-box.
Note: The Greasemonkey userscript only works with the demo (that exact URL). This is to protect users from the dangers of unbridled cross-domain access.
The above is merely a proof-of-concept implementation, demonstrating what becomes possible when you lift the heavy hand of the same-origin policy. A real solution to open cross-domain access will require careful planning. Stay tuned.
Got something to say?
or, read what others have said...