It is quite true that for any Web browser that automatically executes javascript contained in an innerHTML property, innerHTML offers the same security issues as JSON. And if innerHTML, and the execution of Javascript in any page one loads in a browser, are both OK, then in a browser JSON must be OK, since it doesn’t make things any worse. Doug Crockford made this point during the discussion in Boston in December. (Of course, he also said quite clearly that he thought browser security was a huge problem.) But as my colleague Thomas Roessler (see link above) has pointed out, Javascript and JSON are not used only in browser contexts.

On the other hand, the json.js file from json.org provides an easy to use API for safely parsing a JSON string with: “some JSON data”.parseJSON(). That’s at least as easy to use as eval() and is safe. There’s nothing quite so easy and safe in the XML world, though it may be possible to create such an API, and that’s the core point to understand. The issues you raised are about the parsing API, not the data format syntax. An API that lets the programmer easily demand: “Overwrite my data model with this data I got from the network and haven’t vetted” is asking for trouble. You can implement such an API for any data format syntax, as evidenced by both XML and JSON parsing APIs in current browsers. Avoiding this kind of problem requires a level of competence from the browser API designer. You can’t solve this problem just by your choice of data format syntax.

Anyway, your general point is perfectly sound, and is one of the reasons why I refuse to use C++ — there is one right way to do each thing, and 49 wrong ways, and the simple and obvious way is always among the 49.