Hacker News Reader

Comment by basilgohar | Hacker News Reader

Can someone explain why this couldn't have been implemented purely client side and validating if what was entered was first even a valid hostname? Or were the DNS queries only run after they passed an initial check?

I think this is one of the key problems that emerged by merging the search functionality into the location bar. I still now always enable the separate search bar for Firefox and avoid running searches in the so-called Awesome bar. I still consider a search and host lookup very different operations in my mind.

View on HN

I believe it was mainly to detect when a user is trying to navigate to an intranet site with a single-word name (for example http://fileserver). To do that, Chrome needs to make a DNS request for the word and check if it's valid.

However, you can have misbehaving ISPs that replaces all NXDOMAIN responses with something (producing false positives for what constitutes "valid" hostnames), or a guest portal that is hijacking DNS responses, so Chrome will make requests for random DNS hostnames that are unlikely to exist to detect if DNS hijacking is occurring and disable the intranet detection if it is.

The APNIC post[0] backs this up, saying it's the "Intranet Redirect Detector". [1] has more details on how that system works (which is basically what you said, but slightly more in-depth).

[0] https://blog.apnic.net/2021/02/04/how-chromium-reduces-root-...

[1] https://www.archyde.com/chromium-function-against-dns-hijack...

If that was the goal, it does a pretty poor job. The amount of times I've accidentally Googled things like 'internalserver', 'fileserver:80', or 'dockerhost:8000' over the years is way too high.

And when you do eventually reach any of them via manually prepending 'http://', they make the 'http://' not visible in the bar. What confusing signaling!

Hint for Chrome: if I'm appending a port and the DNS name exists I probably don't want to Google it.

Counterpoint, i do want to Google ml.net

Then you type !g ml.net

or ?ml.net

Or switch to Firefox, which haS an address bar and a separate search-only box.

This. I understand why some people don't know (or care about) the difference between the search box and the address bar, but why engineers accept the merged input is beyond me.

Because it saves, on the aggregate, keystrokes.

For something you do dozens of times a day even a tiny gain adds up over time.

I was going to argue that it doesn't save keystrokes when I frequently have to go back and fix the bad guess. But then I realized that you're right - the time saved over the years when I actually do want to Google a specific term likely *far* exceeds the time I've spent fixing the bad guesses.

I guess I'll just accept the flaws that come with it.

How does it save key strokes? To use the location/awesome bar you press Ctrl+L and start typing, to search you press Ctrl+K and start typing...

The vast majority of users won’t use this keyboard shortcut.

How does it save keystrokes? I press ctrl+L to enter a URL or ctrl+K to enter a search, the same number of keystrokes regardless of which box I want to focus.

I've searched for internal servers so many times I've just gotten into the habit of suffixing with '/' so 'internalserver/' goes to http://internalserver/

> If that was the goal, it does a pretty poor job.

Their goal is to treat the query as search, and then try to detect if a host named "internalserver" exists. If so, Chrome displays a banner saying "do you want to visit internalserver/". So they don't have to delay the search until the probe finishes, thus it never automatically make it work without another click.

Personally I don't like it either, so I usually type "internalserver/" (with a tailing slash) to skip the search.

tip: always end those names with the forward slash and it will try the name not Google the word. saves typing the protocol.

I always assumed they didnt make this easier so my mum doesn't go to almostBank:8000

if you go to host ports a lot i.e localhost you can spend a quick search to the sqlite DB for your preferences to make l<tab>:<port> expand out.

u have to edit the SQL. they "patch" the UI so it doesn't accept just arbitrary string patterns to tab complete but only URLs.

Can you provide more details about this? That sounds intriguing, but I think I’m missing something to fully understand what you’re talking about

This is what I ended up with, but looking back into it and localhost:%s/ is a valid search engine string but http://localhost:%s/ is not.

This script is made as a reference after I'd already done the setting so assume it needs editing to work.

I took a look at the sqlite db but I didn't see anything that stood out but I might be looking at the wrong file. Is it databases.db? You can get that tab-complete behavior with custom search engines though

Keyword: l, URL: localhost:%s

Then it works how you're describing with l<tab> and input the port. I personally define all the different versions of my servers that way so v1<enter> goes to something like internalserver:9001, v2<enter> goes to internalserver:9002, etc.

Interesting you made me look back into it and localhost:%s/ is a valid search engine string but http://localhost:%s/ is not.

This script is made as a reference after I'd already done the setting so assume it needs editing to work.

> they make the 'http://' not visible in the bar. What confusing signaling!

In recent versions of Chrome, you can right-click the bar and choose "Always show full URLs" to fix that particular stupidity.

Worth noting that this doesn't actually affect the behaviour of a single user at this point in time.

> Thanks, Matt, that's great to see. Note that that's the effect of the change in comment 37, which only affects Android. The desktop change is blocked on a planned experiment in M88. A wide rollout probably won't happen until late February or early March, at which point we expect an additional reduction in root traffic. [0]

They were doing the DNS interception check on Android, but a different path of code was actually doing the checks (in a different way). Android was basically sending out useless requests.

[0] https://bugs.chromium.org/p/chromium/issues/detail?id=109098...

Which amazes me. Chrome does this check every time network settings change, including a new IP. So your Android phone connecting to various networks just spammed this stuff for no reason. The fact that this fixed dropped root server requests by nearly 50% is astounding.

Normal users don't enter hostnames directly any longer. Even for the most common sites like YouTube.com, Facebook.com and Amazon.com they will largely search the name and then click on the top search result.

This behaviour actually suits Google well, because their incredibly lucrative "promoted results" are shown before the real destination site. You can't charge an advertising tax on users who browse directly to their destination.

Normal users don't type "fa" in the browser bar and get autocompleted to "facebook.com"?

Handshake [1] handles validation on the client side before making a query.

[1] https://handshake.org

Can you point to the specific piece of client side code that does this? It doesn’t sound like it inherently fixes the problem of either going to “myserver” (as in, http://myserver/) and “myserver” (searching the web).

Not all browsers are properly handling but placing a “.” after the name is a temporary fix.

Reply on news.ycombinator.com