- From: Mike West <mkwst@google.com>
- Date: Thu, 29 Sep 2016 09:42:01 +0200
- 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>
- Message-ID: <CAKXHy=eG6oC-CXKBGDRjrdCnD6Nv9R1z+wbQ4WqS7EO=MeGwaQ@mail.gmail.com>
On Thu, Sep 29, 2016 at 1:20 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > 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 >> `127.0.0.1`. 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 `127.0.0.1 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. -mike
Received on Thursday, 29 September 2016 07:42:54 UTC