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

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

From: Emily Stark (Dunn) <estark@google.com>
Date: Wed, 4 May 2016 12:03:42 -0700
Message-ID: <CAPP_2SaRGPgSe3wKJsvc_i8ZCyRSeJvEak5t-ACfR=-J6Q806w@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: Mike West <mkwst@google.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, Richard Barnes <rbarnes@mozilla.com>, Craig Francis <craig.francis@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, May 4, 2016 at 9:46 AM, Daniel Veditz <dveditz@mozilla.com> wrote:

> On Wed, May 4, 2016 at 9:25 AM, Mike West <mkwst@google.com> wrote:
>> 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.
> ​It's a terrible argument for what the spec should say, agreed. Does
> influence how our team prioritizes implementing specs (this seems like a
> small gain for a lot of work).
> ​
>> 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 `` <>
>> won't talk to the internet), and allow developers to make informed
>> decisions about the risks that they're capable of making.
> ​I haven't talked to our team but I'm confident we wouldn't blindly
> whitelist *.localhost as "secure" if we can't get the IP information to be
> sure. We might consider treating "http://localhost/" as "secure-enough",
> even knowing that the occasional eccentric maps that somewhere else.

Why differentiate *.localhost from localhost when RFC 6761 doesn't treat
them differently? (I imagine that the argument is that most resolvers treat
localhost as special even if not *.localhost, but that seems like shaky
grounds on which to call something secure-enough.)

> -Dan Veditz
Received on Wednesday, 4 May 2016 20:49:52 UTC

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