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

Re: Chromium's support for CORS and UMP

From: Nathan <nathan@webr3.org>
Date: Tue, 11 May 2010 04:14:27 +0100
Message-ID: <4BE8CB93.1050300@webr3.org>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: public-webapps <public-webapps@w3.org>
Boris Zbarsky wrote:
> On 5/10/10 10:21 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? surely people are free to make 
decisions, and indeed make mistakes + learn from them.

>> 3: Standardise a way of having signed scripts that are trusted (like
>> mozilla have implemented)
> Mozilla is removing signed script support.  It leads to too much 
> complexity, is disabled by default for users anyway, etc.

code signing sucks and is too complex then, best scratch that idea.

>> Ideally, a long term shift towards global access unless denied by CORS
>> would be an ideal solution (imo), typically corporate sys admin's will
>> be a bit more up to speed when it comes implementing security features
>> than joe public, and quite sure that a security bulletin + a bit of
>> coverage around the web would get the information in to the right hands
> 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. And I guess we could reasonably assert 
that if they have corporate intranet sites, at some point they'll get an 
xhr application that runs in the browser and be exposed to cors, 
probably adding global access and exposing themselves anyway..

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 

>> Surely we can't be dependent on CORS indefinitely, perhaps some form of
>> planned path as to how CORS might be phased out?
> CORS is only needed if you want to perform actions cross-site with the 
> user's credentials on the other site, right?  For that use case, I would 
> in fact expect us to depend on CORS indefinitely.

no.. CORS is needed if you want to perform any actions cross-site, with 
or without credentials, yeah? 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; 
it's the one case where CORS totally isn't needed because the server at 
the other side does it's own auth* ...

and option 1: domain wide well-known CORS?

Received on Tuesday, 11 May 2010 03:15:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:24 UTC