RE: [MIX] Feedback on the private origin & self-signed certificate requirements

I think the server on the loopback interface can use CORS to reject requests from non-intended public origins and browser extensions. The XHR2 draft http://www.w3.org/TR/XMLHttpRequest2/#the-setrequestheader-method says Origin header can't be overwritten (by an extension and scripts). I saw Chrome sets the header to "chrome-extension://<extension id>" even though my extension tries to set to certain value. 

Regards,
Zhigao

-----Original Message-----
From: Hill, Brad [mailto:bhill@paypal.com] 
Sent: Wednesday, September 17, 2014 1:23 AM
To: Mike West
Cc: Chen, Zhigao; Chris Bentzel; Brian Smith; public-webappsec@w3.org
Subject: Re: [MIX] Feedback on the private origin & self-signed certificate requirements

I think that for multi-user and multiple-app-principal systems, the presence of a listening server on the loopback isn't enough to infer the user's permission to allow an arbitrary web site to access it.

Something like existing prompts for geolocation or user media seems like a sensible model to follow to not break existing applications that use this, but asking for local/private network access is definitely less informative for the user about what is actually being granted.

-Brad


On Sep 16, 2014, at 5:21 AM, Mike West <mkwst@google.com> wrote:

> On Mon, Sep 15, 2014 at 5:59 PM, Hill, Brad <bhill@paypal.com> wrote:
> Mike,
> 
>  I hate to recapitulate the extensions debate we had for CSP, but I wonder if you've thought about whether we ought to have some (non-normative) language about this kind of thing when the JS global environment is an extension?
> 
> Oh, my favourite argument!
> 
> I agree that we should leave room for browsers to do the things that they want to do with extensions.
> 
>   The case of calling directly from the browser to another application's web server seems nefarious, but I know that it's a very common thing (at least in my technical circles, if not numerically in the store) for Chrome extensions to make use of localhost web servers or web sockets to connect web apps to other interesting things.
> 
> Yes. Chrome generally allows extensions to do things that we'd consider dangerous to expose to the web at large.
>  
> Or do you think that browser vendors will just make their own appropriate decisions on this without guidance, like how, e.g. Chrome extensions can talk in a limited fashion to USB devices but ordinary web pages cannot.
> 
> What would you suggest our guidance be? It's not clear to me from this email what position you're taking on the question of public/private IPs. :)
> 
> -mike

Received on Wednesday, 17 September 2014 02:02:48 UTC