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

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