[uf-rest] Introducing JAHAH

[Bob Ippolito]

> Hi David,
>
> On Jan 5, 2006, at 12:01 PM, David Janes -- BlogMatrix wrote:
> > ... I'm willing to put technology out there that exploits a hole --
> > or rather "hole", as I think of it. If it JSON/JSONP/JAHAH take
> > off, it's actually easy to add a security bridge within the
> > browser: only allow pure string/dictionary/list/number/basic type
> > definitions to be made on a cross-site script load.
>
> I think the counter-argument to this is that, rather than requiring a
> security-sniffer to evaluate malicious code for security-safeness
> before 'actual' evaluation, far better to use a declarative data
> format and build a rigorous parser into the default library.   No?
>
> -- Ernie P.
>
> P.S.  Ouch, did I really use that many buzzwords in one sentence?

It's not a security flaw.  It's in there by design and it's not going  
anywhere.  It'd kill adwords, among other things.

By the point you're browsing a web page, you're trusting the content  
provider and browser to do no harm.  Script tags with remote hosts  
only end up in that page if the content provider puts it there and  
*rusts the remote host.

If you come up with a "solution" that allows for safe exchange of  
data, you're providing for another use case... namely, exchanging  
data with an untrusted remote host.  That's certainly a valid use  
case, but it's a different one that JSONP doesn't claim to solve.

Note that even with a safe wire protocol, nothing stops the content  
provider from using eval() to run code from untrusted hosts, or to  
simply HTTP proxy to untrusted hosts -- it's up to the content  
provider.  You've already trusted them and nothing can stop them from  
extending that trust to another party if they choose to.

-bob