- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 11 May 2010 09:53:38 -0400
- To: nathan@webr3.org
- CC: public-webapps <public-webapps@w3.org>
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