RE: [xml-dev] json v. xml

["Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@cisco.com>]

Hi.

> > XML can be retrieved using the XmlHttpRequest, but only 
> from the same
> > server the page in which the JS is running comes from.
> >   
> Not true - that's the whole point for doing mashups. And you can use 
> XmlHttpRequest in effect to get or send anything.

I agree that XmlHttpRequest can get any kind of content that resides at
a URL.  

I still maintain that XHR can only be used back to the same server the
page originated from, was that part of your disagreement?

The rest of your points are well taken...

---->N

> JSON and XML aren't 
> the security problem XmlHttpRequest is. In particular it can 
> be run from 
> "onload" in the body tag which means the poor user is screwed 
> from the 
> minute they access the site.
> 
> Can we just clear up a few more things: 1. JSON is data 
> structures (like 
> XML) not objects (CS 101 - where are create/destroy/methods etc?). 2. 
> Like it or not, verbose end tags means XML has a degree of redundancy 
> that ensures correct structure - {} do not do that - and in large 
> documents and data files I see this as critical. 3. JSON also 
> includes 
> lots of useless redundancy - " everywhere is just the start, 
> so are the 
> limited and simple data types (why not include dates and times? it is 
> the 21C after all).
> 
> Rick
> 
> > JS (including JSON) can be included in the page using the 
> script tag or
> > a DOM equivalent created via JS in the page.  The source 
> from which the
> > script tag pulls a file full of JS source code can point to 
> any server.
> >
> > The fact that your page can easily get JS from untrusted 
> sources but not
> > XmlHttp content is bizzare as far as I'm concerned.  
> Changing browser
> > policies to tighten the restrictions on the scrip tag is unlikely to
> > happen.
> >
> > For security, I think filtering so that your JSON or JS always comes
> > from a trusted source is more important and more possible 
> than filtering
> > the JS/JSON once it gets to the browser.
> >
> > Just for the record, I think the "v." in the subject line 
> of this thread
> > is a mistake.  There is no generic JSON versus XML debate 
> outside of the
> > context of a particular problem.  The set of solutions 
> where you'd hold
> > both technologies side by side and compare their fitness is a small
> > subset of all XML uses.
> >
> > --->Nathan
> >
> >   
> >> 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
> >> --------------------------------------
> >>
> >>
> >>
> >>
> >>
> >> ______________________________________________________________
> >> _________
> >>
> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> >> to support XML implementation and development. To minimize
> >> spam in the archives, you must subscribe before posting.
> >>
> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> >> subscribe: xml-dev-subscribe@lists.xml.org
> >> List archive: http://lists.xml.org/archives/xml-dev/
> >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >>
> >>     
> >
> > 
> ______________________________________________________________
> _________
> >
> > XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> > to support XML implementation and development. To minimize
> > spam in the archives, you must subscribe before posting.
> >
> > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> > subscribe: xml-dev-subscribe@lists.xml.org
> > List archive: http://lists.xml.org/archives/xml-dev/
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >
> >
> >   
>