[thelist] ajax, javascript libraries - security.

[Charles]

> Your two points contradict themselves.

I don't see the contradiction, so must not have been clear enough.  Let me
try again.

My first point was that JSON doesn't have the capability of defining
behavior.  It's just a simple, compact data format.

My second point was that it's A Bad Thing to eval() anything that might
contain untrusted code, which is true.  Now, JSON (by definition) *cannot*
contain code.

However, the leap I didn't make explicit is that an untrusted source may
send you JavaScript *instead* of JSON.  Obviously, that's where you're
screwed if you try to take a shortcut by using eval() on data returned by an
untrusted source.

> If you think that eval()-ing or using the script tag workaround is a good
idea or a benefit of JSON...

eval() is one letter from being evil, so obviously it's appropriate in 25%
of cases.   :O)   It *is* a benefit of JSON, in that when eval() is safe to
use, it can be thousands of times faster than parsing XML. 

> The article we are discussing points out that this great feature assumes
that it will never be used maliciously.

My philosophy is that writing secure code requires that one assumes that all
features will be used maliciously.

-- Charles