RE: [xml-dev] json v. xml

["Len Bullard" <cbullard@hiwaay.net>]

It isn't my area of expertise, but it is a problem of almost every format
I'm aware of that has scripts in the content.   Yes it seems bizarre to
allow what is being suggested. I've paid no attention to JSON as I'm not
building for Web 2.0.  I'm animating for single user worlds that are then
folded into multi-user worlds.    I only note the repeating patterns in web
evolution and wonder if this one has a different outcome.

There are even weirder situations in the applications where the user can
contribute content (eg, adding avatars to scenes in Second Life).  Between
the security exploits (look up the newBuzz term 'griefer') and the ease with
which high-price content gets lifted and 'repurposed' (should I allow an
avatar I made for a single user world to be multi-user so it can be
'touchable'), one begins to give up on the web as a medium because it takes
waaaaay too many experts to make it work safely and securely given the over
abundance of people who want to make it easy and work for what they want.
Then you deal with the platform variants that are exploitable.  DRM and
binaries are bad but proprietary systems that trap the content are good.
Standards enable interoperation but they also create monopolies.

The tensions between the 'haves' (the technologists) and the 'have nots'
(the content builders) continue to grow.  Web 2.0 applications are a disease
in that respect.

The JSON vs XML 'January's navel gazing debate' is more of the same.  One
group wants it to be 'easy for their work' and everyone else is told to
accept that or be 'uncool'.   Anything that is open will inevitably become
complex or unsafe.  Anything that is closed will be safer and will last as
long as it does something enough people want to do and pay for:  MAC86.

len


From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 

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