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