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