JSON - Figurin’ It Out
So Tim, Sam, Dare, Don,
Lots of people are clearly trying to work around the same-domain restriction that most browser developers have built into XmlHttpRequest. A quick Google search will reveal lots of ways to manipulate the DOM that will probably work. Canaries and other server side techniques appear to be the appropriate answer to this security question at this point. All I really ask is that, if there’s going to be a vulnerability, it be on the server side so I can sue. If it’s on the client side it’s my responsibility as a client.
However, the question then becomes, should we open up XmlHttpRequest to cross domain queries or should we shut down cross domain stuff on JSON and its (future) descendants? Clearly, at this point there is a desire to be able to grab this data cross-domain and integrate it client side (mashups). I get the feeling that JSON is more about that than any desirable serialization attributes it may have.
Or am I completely off the mark?
Comments
Comment from Sandman
Date: January 19, 2007, 9:21 am
The only safe assumption is the client is corrupt. MMO games and Poker clients have assumed that for years. It doesn’t matter if the client is a browser or a fat-client. Removing cross domain from XmlHttpRequest won’t fix that since it’s a browser enforcement. The only real option is to pass a certificate in the parameters authenticating the caller (and even that is suspect, but slightly more secure). It’s not a JSON issue. JSON is just a marshaling protocol.
Write a comment