Re: Chromium's support for CORS and UMP

Jonas Sicking wrote:
> On Mon, May 10, 2010 at 6:38 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>> * Nathan wrote:
>>>> If you do not depend on a user's special standing with a third party
>>>> site, you can configure your server as proxy between your user and the
>>>> third party site. That's more difficult for you, but easier for users
>>>> and maintainers of third party sites. If we'd do away with the access
>>>> restriction, it'd be easier for you, and more difficult for users and
>>>> third parties. What we have now is largely due to following the path
>>>> of least resistance (which is probably true for most web technology).
>>> Is it possible to set up a server as a proxy, where a client side ssl
>>> certificate is also proxied through, should the server at the address
>>> being proxied request one?
>> If there is a special relationship between the user and the third party
>> site, your site would similarily have to have a special relationship
>> with at least one of them (for example, you might need the user's certi-
>> ficate). In essence, in this scenario, the third party restricts access
>> to those who can prove a certain identity; since you are not them, you
>> cannot do that. This would be a rather broken scenario though, on the
>> one hand you cannot directly access the third party server because you
>> lack some user's certificate; on the other hand, you do have access to
>> it if your server proxies the access over the user's browser (if there
>> were no access restrictions in place, be those default rules or "CORS"
>> rules or something along those lines). That is largely the problem that
>> is sought to be avoided here.
> 
> For what it's worth, my main concern isn't IP based authentication
> between different 3rd parties.
> 
> My main concern is corporate firewalls which allow users sitting
> inside the firewall to access content on intranet servers, while
> preventing outside parties from even sending IP packets that reach
> those intranet servers.
> 
> A browser running on a computer inside the firewall must not allow
> external sites to access the internal servers, effectively using the
> browser as a proxy to circumvent the firewall. If a browser allowed
> that I suspect it would become very unpopular. Rightly so in my
> opinion.
> 

Sigh, it looks like there is no way around this other than to use CORS, 
thus if I may ask 3 things for consideration:

1: Provide servers with the option of placing a domain wide CORS policy 
in a .well-known directory

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)

3: Standardise a way of having signed scripts that are trusted (like 
mozilla have implemented)

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 
(from the ua vendors, large tech sites, more social techcrunch/rww type 
sites etc). Whereas no amount of media coverage will ever inform the non 
professional web population that they have to add these headers to their 
resources (let alone them actually doing it).

Surely we can't be dependent on CORS indefinitely, perhaps some form of 
planned path as to how CORS might be phased out? [one day restful https 
web access control will be the norm and the need for CORS removed].


Aside: do any of you know where I'd be best to suggest the possibility 
of having in browser NSS methods available to javascipt to sign, 
encrypt, decrypt data using client side certificates / remote public keys?

Best,

Nathan

Received on Tuesday, 11 May 2010 02:22:48 UTC