[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: json v. xml
Hi Nathan You're right - what a pain - I was going to use that - now I'll have to make calls to my server so it can make the calls to the other servers :( or just put in iframes ;) At any rate it's just another arms race PS JUMP? http://xml.coverpages.org/draft-sayre-jump-03.txt the wheel is being reinvented already ... <sigh /> Nathan Young -X (natyoung - Artizen at Cisco) wrote: > 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@l... >>>> subscribe: xml-dev-subscribe@l... >>>> 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@l... >>> subscribe: xml-dev-subscribe@l... >>> 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@l... > subscribe: xml-dev-subscribe@l... > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|