I adopted your URL convention (windowname=true) for interoperability purposes. It would be nice if, like JSONP, this convention or something like it gets standardized.

-Ray

Your comment about lack of opt-in is incorrect, window.name does require opt-in from the server, the server must respond by setting the window.name property, this is how it signals authorization. Additionally, this protocol actually opens up the door for some very powerful UI based authorization approaches due the frame sandboxing, that can make cross-site authorization more interactive and easier to build than XHR where authorization must be negotiated using techniques similar to OAuth (although OAuth can’t be done with cross-site XHR).

We will be doing some more posts on using technique with authorization and meta-data transfers (substitute for headers). I will also be doing a post about how to use window.name with the XHR API, a consistent API is certainly one of the goals as well, this post was simply introducing the technique.

Moreover, the problem with these kinds of solutions is that creating a consistent “Ajax” interface (meaning, for instance, the familiar native XHR api) becomes a lot harder and more hacky. And I believe a consistent API should be the premiere focus, not just finding yet another loophole in the browser (that may change or get plugged up later anyway).

In addition, there are some important limitations, such as the lack of ability to set request headers, nor the ability to make authenticated calls.

And this approach is dangerous because it utilizes no built in security or authentication to allow such cross-communication. Models which include the server in the decision process, such as opt-in server policies (crossdomain.xml) are IMHO a lot more robust and should be where we are focusing our energies, rather than thinking the browser alone, with a dynamic (ie, hackable) javascript engine, will be able to ever solely and securely solve this problem.

Adobe Flash has better than 99% browser acceptance, and has made great strides in their security model for cross-domain communication (though clearly there is more to be done!). So I still don’t understand why so many people want down-play solutions that rely on a plugin like flash in favor of all these other hacks? I think it’s pointless elitism to say that solution “a” is better than “b” because “a” hacks only the native browser environment and “b” uses extensions to it.

Flash and their security model were built with specific and intentional support for cross-domain communication, in a secure fashion, and I think it deserves more attention as a viable alternative.

To this end, flXHR (http://flxhr.flensed.com/) is a javascript+flash solution which implements an api-compatible drop-in replacement for the native XHR, with secure cross-domain communication support.