- From: Richard Barnes <rbarnes@mozilla.com>
- Date: Tue, 3 May 2016 08:44:12 -0400
- To: Mike West <mkwst@google.com>
- Cc: Craig Francis <craig.francis@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAOAcki-zuvE35Pr4A9neJWkuOca9=MmYuBe1s6FDr-4kOh_geQ@mail.gmail.com>
On Tue, May 3, 2016 at 8:08 AM, Mike West <mkwst@google.com> wrote: > > 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. > Yes, we probably could, if people really want it. It's getting pretty trivial to set up HTTPS locally, though. https://www.youtube.com/watch?v=nk4EWHvvZtI --Richard
Received on Tuesday, 3 May 2016 12:44:42 UTC