Don't we already do that? https://cs.chromium.org/chromium/src/net/dns/host_resolver_impl.cc?type=cs&l=526

subdomain.localhost already resolves to a loopback address.

As per 3.1 in https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03

estark@ and rsleevi@ can confirm, but I'm pretty sure we don't do the right thing on some platforms in the presence of search domains or /etc/hosts files. I haven't looked into the details yet, so I'm unfortunately not able to point you to the bits that would need to change. :(

We should also send an "Intent to Implement" before unilaterally making these changes, although estark@ may have already done both (I2I and implemented)

I have to dig up some bugs and page back in all the edge cases here.  Issue 683213  is one such edge case; also I guess we have to figure out something to do about proxies.

I haven't sent an Intent to Implement for 'let localhost be localhost', and I don't think I did when I made some changes to localhost resolution back in the day. (Probably should have -- I might have just not known that I2Is were at thing back then.)

How do we plan to treat the edge cases between say proxy and cache layers?

Is this bug just about the host resolver side, or the bigger issue of trying to guarantee that http://localhost is a trusted origin?

 * When using proxy server might not use DNS resolver. Hence http://localhost/ could still be a insecure remote response. Would the plan be to intercept at a lower level and always treat localhost as a bypass domain? (Whether to bypass localhost is a configuration option in most system proxy settings; we could conceivably do this as the use cases for remote localhost are limited; but I think I have seen this used at least on Android for testing)

 * Would we do the check before HTTP cache lookups? If not, what happens if you have saved http://localhost/ to the HTTP cache from a remote response (for instance having been served by proxy server) and then replay it later treating it as a secure origin?

* I suppose localhost must be immediately resolved to a loopback address as per 
"Name resolution APIs and libraries MUST recognize localhost names
       as special, and MUST always return an IP loopback address for
       address queries and negative responses for all other query types."
Furthermore, you never know how proxy server would resolve localhost, thus we might better bypass proxy and return an immediate result.

* As long as .localhost. would always be resolved as a loopback address, I think there is no need in storing that information in cache.