W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2014

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

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 16 Sep 2014 20:05:17 -0700
Message-ID: <CAEeYn8gXE=4u6vGTs-_Ea3NTO-uqCv7bUs83X1eAh52AzOt0VQ@mail.gmail.com>
To: "Chen, Zhigao" <zhigao.chen@sap.com>
Cc: Brian Smith <brian@briansmith.org>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Chris Bentzel <cbentzel@google.com>, "Hill, Brad" <bhill@paypal.com>
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
>
>
>
Received on Wednesday, 17 September 2014 03:05:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC