[skissane]

> (1a) If at least two of the queries resolve to the same IP, store the IP as the "fake redirect address".

From reading the source, it actually does a HTTP HEAD chasing redirects, and records the origin of the final page, and uses that as the redirect address. So even if two hostnames yield different IPs, if they end up redirecting to same hostname, it will be detected

> (2a) if the two queries resolve to the same IP as the first one, we have a fake redirect. Don't do anything. Otherwise, show the "local domain" hint.

What if an ISP uses multiple IPs in the fake redirect, and alternates over those IPs in each successive response?

[xg15]

> What if an ISP uses multiple IPs in the fake redirect, and alternates over those IPs in each successive response?

Good point. I was wondering how they'd deal with that in the actual implementation.

I think you got the answer though: They match HTTP origins instead of IP addresses - so I imagine, you could do the same in step 2: Do a HTTP HEAD query to the search word and two additional ones to random hostnames, following redirects. If the final origins are the same, there is fakery going on.

A problem with this could be unexpected HEAD requests to actual internal hosts: There is no guarantee an internal host that was never meant to receive HEAD requests would react gracefully or in any way predictable to one.

I'm not sure how they solve this currently. Maybe this could at least be mitigated by only sending the HEAD request to the search word host if there is reasonable suspicion requests are being redirected - e.g. only if the two random hosts resolved and were both redirected to the same origin.

Finally, you could cut all of this short by also connecting to (search word):443 and trying to initiate a TLS session handshake. If the host answers, you know it's probably a genuine internal host that talks HTTPS and you don't need to do any additional probes. (And you can also abort the handshake and don't ever need to send an actual HTTP request to the host)

[skissane]

> A problem with this could be unexpected HEAD requests to actual internal hosts: There is no guarantee an internal host that was never meant to receive HEAD requests would react gracefully or in any way predictable to one. I'm not sure how they solve this currently

A perfectly legitimate answer is to not even try. Per the HTTP spec, sending HEAD is supposed to be harmless. If it causes harm, that’s a violation of the spec. I’m sure some legacy server out there segfaults on HEAD, but that’s not a browser vendor’s problem, and it isn’t up to the browser vendor to do anything to try to prevent it. Browsers (not just Chrome) send HTTP HEAD in other scenarios as well. And I think this problem is relatively rare in practice, since one hears few reports of it actually occurring

[xg15]

I disagree. In this case, it would be Google who is changing the status quo.

I think it's legitimate for a fully internal server on an internal network that only handles internal clients to only implement the parts of the HTTP spec that are relevant to the exchange.

If Google worms its way into that network and starts to talk to random servers, they'd be at fault for causing problems.

I think this holds particularly strong for this case as the requests are not tied to an obvious user action: If I typed "http://dumbo/" into the address bar and the browser's GET request broke the server, I'd be more inclined to view the server's team at fault than if I just searched for "dumbo" and found out the browser broke a server that I didn't even know existed.

Independent of that, it's of course good advice to always build your services as robust as possible - internal or not - and to follow the spec wherever you're able to.

[skissane]

> I disagree. In this case, it would be Google who is changing the status quo.

This code has been in Chrome since 2010. When you've been doing something for the last ten years, you aren't changing the status quo, now you are part of the status quo.

> I think it's legitimate for a fully internal server on an internal network that only handles internal clients to only implement the parts of the HTTP spec that are relevant to the exchange.

So, there are two ways of "not implementing HEAD": (1) ways that don't harm the availability of the service or other connections to it (return a HTTP error, abruptly close the connection, etc) (2) ways which do (e.g. crash the whole service upon HTTP HEAD on a single connection)

If a service isn't implementing HTTP HEAD in way (1), then Chrome isn't going to hurt it. If a service isn't implementing HTTP HEAD in way (2), then it is buggy, poorly written, and also insecure (HTTP HEAD becomes a denial of service attack), and that's not Google's problem, that's the problem of whoever maintains that service

In practice, few services which don't implement HEAD in way (2) are even going to exist, because browsers (both Chrome and others) regularly send HTTP HEAD in other circumstances as well (e.g. CORS checks). If HTTP HEAD makes your service crash, your service is going to be crashing a lot even if Google had never implemented this particular feature