Re: Chromium's support for CORS and UMP

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

Received on Tuesday, 11 May 2010 13:54:16 UTC