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

Re: [secure-contexts] `*.localhost` + DNS

From: Mike West <mkwst@google.com>
Date: Tue, 3 May 2016 14:08:52 +0200
Message-ID: <CAKXHy=c6c4s-9fBdA2VqGy+De_Sf5pkD_a5y-YdVj-reUv=nDw@mail.gmail.com>
To: Craig Francis <craig.francis@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, May 3, 2016 at 1:43 PM, Craig Francis <craig.francis@gmail.com>
wrote:

> As a developer that works on multiple websites, I have a wildcard DNS
> entry that points `projectABC.laptop.example.com
> <http://projectabc.laptop.example.com>` to 127.0.0.1 (as an aside it
> resolves to 192.168.0.5 for the browsers in a VM).
>
> I would like this setup, where the DNS does resolve to 127.0.0.1, to be
> considered a secure origin, so I can easily develop websites without having
> to setup HTTPS on my local machine (I suspect I will need to anyway, but
> though I'd mention it).
>

Understood. This is something we've resisted offering in the past due both
to conceptual complexity, as well as nondeterministic behavior. It would be
difficult for you to understand why, for instance, `
project.laptop.example.com` was secure when it pointed to `127.0.0.1`, but
not when it pointed to `192.168.0.5`, because that resolution is completely
opaque to you, the user.

A better solution, I think, is for browser vendors to provide an override
mechanism for origins you specifically care about: Chrome
has `--unsafely-treat-insecure-origin-as-secure="
http://project.laptop.example.com"`, and I assume Safari, Opera, Firefox,
and Edge could be prevailed upon to provide similar controls as suggested
in https://www.w3.org/TR/secure-contexts/#development-environments.

-mike
Received on Tuesday, 3 May 2016 12:09:45 UTC

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