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
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
