W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2016

RE: [MIX] Carveout for `127.0.0.1`?

From: <Axel.Nennker@telekom.de>
Date: Tue, 3 May 2016 12:09:38 +0200
To: <rbarnes@mozilla.com>, <dev.akhawe@gmail.com>
CC: <mkwst@google.com>, <evn@google.com>, <public-webappsec@w3.org>
Message-ID: <7B1E2B3A05FF2341B03CE032075423072EA371F222@HE101454.emea1.cds.t-internal.com>
The most important part for me is that mechanisms like this work across all browsers.
We used things like file:///<file:///\\> and http://localhost/ in the past but never built a product using it because the behavior changed even from browser version to browser version.
The current definition in Secure Context contains too many MAYs and SHOULDs to really help developers here.
https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy


So if MIX gets me a standard way of communication with an app or local server then I want this.

Axel


From: Richard Barnes [mailto:rbarnes@mozilla.com]
Sent: Freitag, 29. April 2016 16:37
To: Devdatta Akhawe
Cc: Mike West; Eduardo' Vela; public-webappsec@w3.org
Subject: Re: [MIX] Carveout for `127.0.0.1`?

I support using the definitions from Secure Contexts.  I do not support special casing for MIX.

Sent from my iPhone.  Please excuse brevity.

On Apr 29, 2016, at 10:35, Devdatta Akhawe <dev.akhawe@gmail.com<mailto:dev.akhawe@gmail.com>> wrote:

Yes, please. And I support it because I think it is a good idea :)
On Apr 29, 2016 1:45 AM, "Mike West" <mkwst@google.com<mailto:mkwst@google.com>> wrote:
On Fri, Apr 29, 2016 at 10:27 AM, Eduardo' Vela" <Nava> <evn@google.com<mailto:evn@google.com>> wrote:

Yes please!
I'm not sure if you're supportive because it's a good idea, or because it will let you break more things. :)

On Fri, Apr 29, 2016, 09:46 Mike West <mkwst@google.com<mailto:mkwst@google.com>> wrote:
Currently, mixed content checks block `http://127.0.0.1` from loading in a page delivered over TLS. I'm (belatedly) coming around to the idea that that restriction does more harm than good. In particular, I'll note that folks are installing new trusted roots and self-signing certs for that IP address, exposing themselves to additional risk for minimal benefit. Helpful locally installed software is doing the same, with even more associated risk.

I'd like to change MIX to use the Secure Contexts spec's notion of "potentially trustworthy" origins as opposed to toggling strictly based on the URL's protocol. This would be a normative change that would force us back to CR again. *shrug* Seems like it might be worth doing anyway.

I've filed https://github.com/w3c/webappsec-mixed-content/issues/4 to cover this, and have a PR up at https://github.com/w3c/webappsec-mixed-content/pull/5 for discussion.

WDYT?

Note also that I'm thinking about this in the context of https://mikewest.github.io/cors-rfc1918/, which aims to create more restrictions on Internet -> Intranet -> Local traffic that are probably more reasonable. That's going to be tough to ship, but I'm aiming to have a prototype for discussion at our May F2F.

-mike
Received on Tuesday, 3 May 2016 10:11:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC