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

I am confused why this is part of the mixed content specification. I
think it is pretty easy to say that loopback interfaces are secure and
not part of the mixed content threat model (network attacker). The
question of what we should do with the loopback interface should be
addressed in a separate discussion/spec, if needed.

Not to say this discussion shouldn't be had---but I agree with Zhigao
(and Mike?) that this is a reasonable exclusion from this spec.

--dev



On 16 September 2014 20:05, Brad Hill <hillbrad@gmail.com> wrote:
> 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:59:48 UTC