[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] json v. xml
- From: noah_mendelsohn@us.ibm.com
- To: "Len Bullard" <cbullard@hiwaay.net>
- Date: Fri, 5 Jan 2007 14:41:31 -0500
Maybe one of you folks with more experience in the security aspects of the
JSON/XML business could clarify something for me. I've heard it alleged
that among the other attractions of JSON is that typical browser security
policies allow one to do cross-site retrieval of JavaScript in
circumstances where XML retrieval would be disallowed. Two questions:
1. Is this true?
2. If so, am I the only one who thinks this is bizarre? Whatever the
history of these policies, we have a situation in which information
transmitted in the form of an executable Turing-complete programming
language (JavaScript) are allowed, but in which information in the form of
a declarative markup language are blocked as a security risk?
Now, I'm not against JSON. The other good reasons for its use have been
mentioned in this thread. I also understand that anyone with any serious
interest in security will not blindly eval whatever they get back as
purported JSON, that the JSON subset of JavaScript is indeed declarative
and not even close to Turing-complete. I even agree that one can transmit
Turing-complete code as XML (XSL comes to mind, or you can put C Code in
into CDATA I suppose.) The point is that almost no sensible default
processing of XML raises the same sorts of security issues that would
normally be associated with executing arbitrary JavaScript, and we all
know that one of the ways to try and trick a JSON client is to send it
non-JSON JavaScript..
So, insofar as my sketchy understanding of the situation is correct, and
blithely ignoring the many compatibility issue that prevent sensible
changes to already-deployed systems, wouldn't it make sense to ensure that
the security limits on cross-site downloading of script fragments such as
JSON are at least as tight as those on XML? Then, insofar as cross site
access to JSON survives such changes, we could go back to letting users
choose whichever format makes them happier in a given situation.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]