RE: [xml-dev] json v. xml

[sterling <sstouden@thelinks.com>]

Excuse me, but I would like explained the elements that represent 
the collection of facts that clarify your statement 

"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."

1. who are the haves and the have nots?  
  How many different classes of each exit?
   Who occupies the spaces in between?
   Is this a learning entity derived problem or 
           a   profit entity derived problem?
  
2. what classes of tensions are you referring to
   and how are the classes defined, if not obvious?

3. more fully explain what is meant by your 
   observation that Web 2.0 apps is
   a separation disease 
   (l like that description, but d/n understand it)?

Thanks for your help in clarifying these insightful
  observations of yours.

me
  



On Fri, 5 Jan 2007, Len Bullard wrote:

> 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
> 
> 
> 
> 
> 
> _______________________________________________________________________
> 
> 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
> 
>