Re: Chromium's support for CORS and UMP

Over the past few years numerous others have hit this issue, for 
instance TimBL and his team on the Tabulator project - they had to move 
to a browser extension where the access is granted, as have many others, 
and as I'll probably end up doing, and those that follow after me.

quote TimBL yesterday in response to this issue: "Note if they run an 
add-on, like Tabulator, then they skip this problem as the code is 
deemed trusted." [1]

Here's what happens, applications are no longer portable, and moreover 
they are platform specific, as more and more start to see the web as a 
data tier then they too move to making browser extensions - browser wars 
/ social impact / and notion of trying to "own" the web (or access to) 
aside...

This leaves us in a scenario where it is the norm to download, install 
and trust an application that runs in the browser, and applications 
which have all the access that xhr would have today without any same 
origin rules and CORS.

Now, if you apply the same origin restriction and push browser 
extensions in to CORS too, then either the apps everybody then depend on 
stop working, or everybody opens up the data with CORS and the original 
issues CORS tries to address are back.

Problem is, do you address it in the past when it's been noted (time 
machine?), now, or wait till the .... really hits the fan?

CORS completely unlinks the web, it makes it not a web (as far as xhr is 
concerned anyway) - the only solution that will work, now and through 
the future, is to invert the model - everything is public unless access 
controlled otherwise - this is why the web works, and xhr doesn't.

arguably broken as somebody recently said.

[1] http://lists.w3.org/Archives/Public/www-tag/2010May/0015.html

replies to specifics below, but they are pretty much obsolete given the 
above.

Boris Zbarsky wrote:
> On 5/10/10 11:14 PM, Nathan wrote:
>>>> 2: Implement a user UI confirmation screen to allow JS applications xhr
>>>> access to other origin resources. (Similar to the allow desktop
>>>> notifications scenario in chromium)
>>>
>>> Under what conditions would the typical user be able to make an
>>> informed decision here?
>>
>> under the same conditions that it's the web and they can put any address
>> in to the address bar that they want?
> 
> That's not the same thing as giving site A access to data from site B.

agree~ish, imho it's more the user giving the Site A potential access to 
all the data from Site B which the user has permission to see; if the 
browser pops up that facebook is trying to access company-payroll then 
surely the user will be able to make a pretty informed decision..?

>> surely people are free to make decisions
> 
> Yes, but forcing people to make decisions given insufficient information 
> is not a nice thing to do, exactly.  It happens all the time, but 
> purposefully making it happen more often is not called for.

agreed, perhaps if that decision was taken out of their hands for 
critical resources which they didn't control (like company-payroll) it 
would be a better scenario... perhaps one could use something like cors 
to limit xhr access to critical resources..

>> and indeed make mistakes + learn from them.
> 
> Not when their mistakes don't really affect them.  See "externality".

agreed, and as above | still the same thing though, the site A/B admins 
/ security people should be covering that I guess..

>>> You're being _way_ too optimistic about this. "corporate sys admins"
>>> are still using HTML blacklists in HTML filters on a routine basis,
>>> after years of education attempts...
>>
>> Yes I'm probably being way too optimistic, incompetency of some doesn't
>> mean it's not a better approach.
> 
> It might if the "incompetency" is widespread enough.  We need to design 
> for the world we live in, not some utopia where everyone has infinite 
> amounts of time to study everything and be an expert on it.

again, agreed - hence why I'm suggesting that it's better to flip the 
scenario order, allow unless denied, as the people who are in charge of 
security of sensitive data should really be doing the studying for their 
chosen career, not joe public who just wants to put up a few blog posts, 
social profile etc on a shared host - how do you explain to joe that his 
public profile isn't viewable in his public profile viewer unless he 
changes some CORS headers on his shared host that he doesn't have access to?

>> I get the feeling I'm not the first person to say this, and certainly
>> not the last - yet feel a bit of a brick wall here - who's web is this
>> again?
> 
> All of ours.

:)

>> no.. CORS is needed if you want to perform any actions cross-site, with
>> or without credentials, yeah?
> 
> No.  If you don't need credentials, then:
> 
> 1)  You could have the UA ask your server to perform the action
>     cross-site itself.  No one's stopping you from doing that.

well noted - yet the whole point of making a purely client side 
application is so that it doesn't need a server and uses the web as a 
distributed data tier.. not to mention http cache'ing and bandwidth 
issues, it creates a silo, a bottleneck, adds in a layer where all a 
users data in-out can be monitored and collected, more.. there are many 
implications to this.

> 2)  You could use one of the APIs being proposed that do not send
>     user credentials and hence might well not require CORS, since
>     they will only be able to fetch public data (modulo the
>     firewall/routing issue, which will indeed need to be resolved).

? what's the point in CORS if it can be completely circumvented?

>> And for the use-case where there are user credentials needed then the 
>> browsers all ready do a pretty good job of
>> asking for credentials / certs and letting the user decide what to do;
> 
> In the 99% common case they just send the credentials automatically 
> without asking the user anything.
> 
>> it's the one case where CORS totally isn't needed because the server at
>> the other side does it's own auth* ...
> 
> No.  The whole point here is that just because a user visits your site 
> doesn't mean that your script should be able to impersonate that user 
> when talking to other sites.  That means either not allowing your script 
> to talk to other sites unless they explicitly say they're ready for that 
> sort of thing (current setup + CORS) or not allowing your script to 
> impersonate the user in the requests it sends.

granted, conflation over the current common setup, and the scope I'm 
talking about which is using client side certificates over https, 
restful and stateless - no impersonation can happen :)

Best & obviously nothing personal at all,

Nathan

Received on Tuesday, 11 May 2010 04:28:45 UTC