W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: Chromium's support for CORS and UMP

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 10 May 2010 23:34:48 -0400
Message-ID: <4BE8D058.2090904@mit.edu>
To: nathan@webr3.org
CC: public-webapps <public-webapps@w3.org>
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.

> 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.

> and indeed make mistakes + learn from them.

Not when their mistakes don't really affect them.  See "externality".

>> 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.

> 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.
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).

> 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.

-Boris
Received on Tuesday, 11 May 2010 03:35:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT