Some other contexts where it matters:

* Hard-coded host resolver bypass list that always resolves to 127.0.0.1 / ::1.
* When using the async resolver (Bypass list would take precedence over this, anyways...mostly).
* security_origin uses HostStringIsLocalHost.
* A bunch of random consumers use net::IsLocalhost().
* Consumers that just use IPAddress::IsPubliclyRoutable() should be fine, since it uses IP addresses instead of hostname.

As far as I can tell, this is a non-specified Microsoft deviation. Localhost-and-friends at least had well-defined specifications. I'm curious if this is some ancient Microsoft deviation (much like octal IP addresses or permissive resolution APIs) that just got carried forward.

I definitely don't think we should 'add' loopback to the special names list, which is generally used to grant more permissions than fewer. It may be best just to address it add the proxy.

Adding elawrence@ in case he still monitors bugmail, and since he previously introduced "<-loopback>" to IE9's proxy resolution logic :)

From the HostResolver perspective:
I'm not a fan of directly adding special handling for anything like this without a well-defined spec.  Too much danger Microsoft fixes it or we don't understand all the rules and cornercases, leaving us out as the odd spec deviant.  

Something we could consider is to detect such hostnames and, on Windows, always resolve them via getaddrinfo rather than async resolver.  Then we'll always be at least as conforming as the platform.  This is similar to what we do for *.local hostnames where by spec they should always be resolved via MDNS but not all platforms do so.

Here is a proposal to just special-case it for proxy resolution:

  https://chromium-review.googlesource.com/c/chromium/src/+/1333906

We can expand the scope later if needed based on feedback.

Given we've apparently had 0 feedback on this in the 5-6 years I've been watching the proxy label, I think we can probably count that as no feedback.  :)

#9: I was referring to broader feedback on how "loopback" is used and defined on Windows. I certainly agree that the proxy resolving compatibility case shouldn't be too interesting.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7aeea3a2da27e2bf566cf11e75f960124061c79c

commit 7aeea3a2da27e2bf566cf11e75f960124061c79c
Author: Eric Roman <eroman@chromium.org>
Date: Wed Nov 14 02:11:23 2018

Bypass the proxy implicitly for "loopback" (on Windows only).

Bug:  904889 
Change-Id: I52e5b4cc2bff0cff0b1c7d6ec55d26b01924c288
Reviewed-on: https://chromium-review.googlesource.com/c/1333906
Commit-Queue: Eric Roman <eroman@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607855}
[modify] https://crrev.com/7aeea3a2da27e2bf566cf11e75f960124061c79c/net/proxy_resolution/proxy_bypass_rules.cc
[modify] https://crrev.com/7aeea3a2da27e2bf566cf11e75f960124061c79c/net/proxy_resolution/proxy_bypass_rules_unittest.cc