On 5/11/10 1:10 AM, Nathan wrote:
it's almost inevitable that somebody
will make another OS browser that doesn't respect site origin policies
and CORS
And sites will then blacklist it, while users using it will get
exploited. So it won't gain significant market share, and the problem
will resolve itself.
Hold on. Making purely client-side applications isn't exactly an
inviolable human right. There are lots of things that can't be done
purely on the client side... yet.
yet.. but soon, as I'm sure you realise.
Sure.
Sure. It's just the only way to make this work right this second.
this may be the point.. but, if one were to make something else to
access resources on the web, in a browser, through JS, then it'd pretty
much just be XHR or browser extensions all over again wouldn't it..?
Yes. It'd be just like XHR but not sending the user's credentials.
Like http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#constructors for
example.
What would be circumvented? The point of CORS is that site A can't
pretend to be user U to site B and get information it couldn't get by
running wget on one of site A's own servers.
indeed, that's the issue - I'm not saying it's not an issue, or that
CORS shouldn't address it - merely that imho it's addressing it the
wrong way round, the exact same scenario could be stopped, using CORS
with an inverted model of allow then deny.
Not unless every single web site is updated first before deployment.
And there's no incentive for people to do that, so such a solution would
not get deployed.
Honestly, I understand the vendors not wanting to introduce an
insecurity in to corporate networks through their browsers,
That's item 1, but item 2 is not allowing evilsite.com to read data from
the user's banking site just because the user happens to follow a link
in an e-mail.
> even if it's with a different set of tech's
that run in a browser called something-not-xhr-but-does-the-same
See link above.
That's not necessarily true. If you can send requests of your choosing
using the user's client certificate to sites of your choosing and read
the resulting responses... how is that not impersonation of the user?
as you said above, the problem is stopping siteA pretending to be siteB,
> this makes it impossible, what it leaves is the scenario you note
> above.
No. The problem is stopping siteA pretending to be the _user_ while
talking to site B. That's the whole point of cross-origin checks, CORS,
etc.
Where an application in a browser with web access could access a
resource using a client certificate (after the user allows it)
That's a different situation. That would require explicit opt-in from
the user. In fact, imo it would require explicit opt-in to even see the
question being asked.
-Boris
