even worser if your alias is for an externally available server, and uri is actually is not to be disclosed

well, URI part does matter too. e.g. to avoid backend website software attacks it is better to have backend uri secure. so testing internally some website backend having such secret uri I do transfer it right to untrusted environment. And if server is actually live one and alias is just for a faster typing then we get an actual threat

.loc isn't a top level domain specified by IANA - see http://data.iana.org/TLD/tlds-alpha-by-domain.txt so I don't think Chrome should be doing a resolution here.

Passing to the network folks to confirm.

please note, that firefox (and, surprisingly, even IE) handles this properly, trying to resolve it regardless of is '.loc' TLD or not. Moreover, anything that is not a TLD must be checked twice, not TLD means that is private, so need to be twice careful

Removing assignment, marking this Untriaged.

I'm fairly certain this is WontFix/WAI. ICANN (via SSAC) has certainly highlighted repeatedly the risks of "TLD squatting", given ICANN's desire to make them widely available, and it does not (and cannot) be guaranteed to be kept private, so organizations that rely on this as a privacy/security feature are already in trouble.

I'll let Peter do the WontFix, he's the primary contact for the Omnibox design.

We don't try to resolve names before searching because the vast majority of all searches are, potentially, valid intranet names.  So we would have to resolve almost everything, which could have horrific performance implications for omnibox searches, especially in broken and badly-behaving DNS resolution scenarios.  Furthermore, we could no longer tell people ahead of time what their input will do; today, the omnibox makes it clear via icon what will happen when you hit enter, before you hit enter.

Other browsers either don't rely on the address bar as the primary search box and thus don't care about the potential problems here, or have not thought about them.

Chrome mitigates this by remembering any typed navigation, as well as infobar-triggered navigations, and defaulting to navigating in the future.  If you successfully navigate to my-alias.loc once (try just putting "my-alias.loc/" or "http://my-alias.loc" into the address bar, or clicking the link on the "did you mean" infobar you saw), we won't treat this as a search query again.

If you have secret paths that you don't want to leak, you should probably be accessing things over https to begin with.  Otherwise, even if navigation is the default on hitting enter, you could be leaking the path in search suggestion requests while typing.  Whereas if you start typing "https://my-alias.loc/my-secret-uri", we will stop sending suggest requests when you start typing the path, to avoid leaking information.

IMHO, at least you can add an option to toggle that on/off

No, we will not be adding an option.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot