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

On Wed, May 4, 2016 at 6:16 PM, Daniel Veditz <dveditz@mozilla.com> wrote:

> On Tue, May 3, 2016 at 6:22 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>> Are you saying that the intent is to not consider the actual resolved IP
>> address of the host but rather the host portion of the requested URL? It
>> would seem less "hacky" to have a rule that simply says, if the host
>> resolves to 127.0.0.1 it's secure.
>
>
> ​It would be less hacky to the user, but at least in Gecko there's not
> currently a good path for the DOM layer that is making these security
> decisions to get the resolved IP address from the networking
> l​ayer​​. As a practical matter it would be far easier to support a flag
> as Mike suggested than to rewrite a bunch of internal APIs.
>

I don't think this is a good argument for the position; we should support
users when it makes sense to do so, even if it's annoying work for us as
browser vendors.

I think a better argument is that the Secure Contexts spec is setting up a
default set of behavior which needs to be "secure" for all users,
developers or not. I think it's totally reasonable to be conservative in
those defaults, while giving developers the tools they need to develop.

We should not, for instance, whitelist everything under `*.test` as
"secure", because we have no idea whether those endpoints would end up
being "secure". We can, however, allow developers to do so locally if they
so desire.

Similarly, we don't know that `*.localhost` is resolving to the loopback
address. In the absence of certainty, it makes sense to default to
something conservative (we _know_ that `127.0.0.0/8` won't talk to the
internet), and allow developers to make informed decisions about the risks
that they're capable of making.

-mike