W3C home > Mailing lists > Public > www-tag@w3.org > September 2016

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

From: Mike West <mkwst@google.com>
Date: Thu, 29 Sep 2016 09:42:01 +0200
Message-ID: <CAKXHy=eG6oC-CXKBGDRjrdCnD6Nv9R1z+wbQ4WqS7EO=MeGwaQ@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.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 1:20 AM, Melvin Carvalho <melvincarvalho@gmail.com>

> On 28 September 2016 at 14:24, Mike West <mkwst@google.com> wrote:
>> On Tue, Aug 2, 2016 at 8:51 PM, Mike West <mkwst@google.com> wrote:
>>> * In https://github.com/w3c/webappsec-secure-contexts/issues/43, Erik
>>> suggested that the move to exclude `localhost` was the wrong way to solve
>>> the problem, and that we should instead treat it as "secure" if it resolves
>>> to a loopback address. Recorded in the spec as
>>> https://w3c.github.io/webappsec-secure-contexts/#issue-8ea95bab.
>>> Without some change in the way that agent's DNS resolvers handle these
>>> names, I'm reluctant to change the spec, but perhaps pushing for that
>>> change is a reasonable thing to do.
>> Following up on this now that we've hit CR: I've written up the change to
>> DNS resolvers suggested in the GitHub discussion at
>> https://tools.ietf.org/html/draft-west-let-localhost-be-localhost.
>> The general response has been positive, but opinions from folks on this
>> list would be appreciated. If we can get something like this proposal
>> adopted in user agents, I'd be comfortable calling `localhost` as secure as
>> ``. WDYT?
> I currently use my browser to connect to localhost (via http and https).
> A couple of questions:
> 1. Is this spec something that affects user agents today, or something in
> future.  Id love to hear a short description of how.

Which spec? Secure Contexts, or the localhost update?

The former describes a set of constraints that some user agents are
imposing upon some APIs. The initial set of constraints are centered around
securing the transport and communication channels available to a page. I
expect it will continue affecting user agents today and tomorrow as we
continue to lock more APIs down.

The latter is an attempt to clarify language in RFC 6761: the current text
basically boils down to "localhost _should_ mean loopback", I'd like it to
say "localhost _must_ mean loopback". That will continue to have effect so
long as we use names for loopback interfaces.

> 2. Is there an easy workaround?  For example could I alias my localhost to
> be called another domain name via /etc/hosts or using a CNAME that tunnels
> through my firewall (which I think would work for me at home but not when
> im traveling).  Or is there a flag to switch it off in the user agents
> settings.

I don't know what "workaround" means in this context. What is it that you'd
like to see?

If you're asking whether ` myamazingdomain.yay` in your
`/etc/hosts` will continue to work, yes, of course it will. :)

If you're asking whether `myamazingdomain.yay` would be considered a secure
context, no, not by default, but your user agent should give you
configuration options to make that decision for your own local development.

Received on Thursday, 29 September 2016 07:42:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:14 UTC