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

Re: `localhost` as Secure Context, take 2 (was Re: CfC: Transition "Secure Contexts" to CR; deadline August 2nd.)

From: Emily Stark (Dunn) <estark@google.com>
Date: Thu, 29 Sep 2016 08:15:06 -0700
Message-ID: <CAPP_2SZkc-zhJnzY77ZgJUFkDZPWn1X1YxDKuNFG0O+Ga8Ch5A@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Brad Hill <hillbrad@gmail.com>, Jake Archibald <jakearchibald@google.com>, Erik Nygren <erik+w3@nygren.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>
On Thu, Sep 29, 2016 at 12:56 AM, Mike West <mkwst@google.com> wrote:

> On Wed, Sep 28, 2016 at 7:58 PM, Emily Stark (Dunn) <estark@google.com>
> wrote:
>
>> We twittered about this briefly, but I wanted to check: is the proposal
>> that 'let localhost be localhost' goes through and then Secure Contexts
>> changes to say that browsers should hardcode the resolution of local
>> hostnames to loopback IPs?
>>
>
> My goal with the ID is to give Chrome cover to reject resolutions of
> `*.localhost` that don't map to loopback IP addresses. We'd either fail the
> resolution, or fallback to 127.0.0.1, or something similar. I don't have
> strong opinions about the exact behavior, but the impact would be that we
> could continue treating `localhost` as a secure context. I think that's in
> line with developer expectations, and I would appreciate other browsers
> following along.
>
> To that end, Secure Contexts would revert https://github.com/w3c/
> webappsec-secure-contexts/commit/77175e335f96e52431888dfacf382c47e9637aeb,
> and add a requirement for conformant user agents to ensure that localhost
> resolution follows the ID.
>
> Does that make sense?
>

Yep! Thanks for the clarification.


>
> -mike
>
Received on Thursday, 29 September 2016 15:15:57 UTC

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