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

It's not just about protecting the server, it's about protecting the user
from having information outside the browser privacy model disclosed
silently, as in the bug Mike referenced up thread.

-B
On Sep 16, 2014 7:04 PM, "Chen, Zhigao" <zhigao.chen@sap.com> wrote:

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