I warned about this back when all those new TLDs were being considered. Single-word TLDs are not properly supported in browsers, in DNS, or even at the glibc level.<p>At the browser level, is it a keyword or a domain? Try "ai". "ai" is a real domain, and there's a web site at "<a href="http://ai"" rel="nofollow">http://ai"</a>, touting the advantages of starting an offshore company in Anguilla. Most browsers interpret "ai" as a search term by default. If you enter "ai.", though, you've specified a rooted domain name (a feature few people know about) and should get the "ai" web site. Firefox understands this, but Android doesn't. Try various browsers.<p>At the glibc level, there's an exploitable bug, which I reported in 2012.[1] It's still open. The bug was first seen in 2011 and reported on serverfault.[2] The problem is that glibc DNS lookup has a feature which is supposed to allow abbreviating domain names. The idea was that if you're on "something.harvard.edu" and you look up "law", it tries "law.harvard.edu". The exploit is that if you're on "foo.com", and you look up "baz.com, glibc tries "baz.com.com". There's a domain "com.com", and it has a wildcard DNS server, so it will resolve "baz.com.com". What's there? A scam. "You are selected by G00GLE to be among the first few persons to win an iPhone 7...".<p>This behavior is a problem for all single word domains. Whether it is active depends on the hostname of your local host. It's mostly a server problem, but some ISPs issue clients hostnames such as "12345678.comcast.net", which means that "google" gets tried as "google.comcast.net". Fortunately, "google.comcast.net" doesn't resolve in DNS. Neither does "com.comcast.net" ISPs need to be careful about this.<p>(It's a big problem if you're writing a web crawler, which is why I know about it.)<p>[1] <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=13935" rel="nofollow">https://sourceware.org/bugzilla/show_bug.cgi?id=13935</a>
[2] <a href="http://serverfault.com/questions/341383/possible-nxdomain-hijacking" rel="nofollow">http://serverfault.com/questions/341383/possible-nxdomain-hi...</a>
A great case study in "The Web is hard."<p>I stumbled on this earlier this week: <a href="https://twitter.com/mholt6/status/838504217731948544" rel="nofollow">https://twitter.com/mholt6/status/838504217731948544</a> and found it amusing but confusing in two ways:<p>1) The prompt is pointing to the "Secure" icon; I thought it was asking me if I wanted to downgrade my protocol to HTTP.<p>2) The domain "google" made me and several others wonder if there was a hosts file entry for "google", which turns out there isn't.<p>No, of course, the real problem is much more complicated; a strange twist of omnibar meets DNS meets HSTS. This is definitely an edge case, but might be a glimpse into the complicated future of gTLDs and the emergence of ever-more web standards...
One very bad idea meets another.<p>Now, let's make every program more user friendly by obscuring the meaning of our input fields and creating very complex rules for how they'll act... Oh, wait, our programmers aren't able to understand our rules anymore? Nah, we are an AI company, we can live with that.
/Insert grumblings about insecurity of the omnibox (leaking internal corporate data) and my personal preference for firefox-style URL box and search box.
This causes funny behavior like <a href="https://pbs.twimg.com/media/C6L3IvsUsAABuyS.jpg:large" rel="nofollow">https://pbs.twimg.com/media/C6L3IvsUsAABuyS.jpg:large</a><p>Chrom(e|ium) will suggest to navigate to <a href="http://google" rel="nofollow">http://google</a> if you're opening google.com
Honestly, although I use the Omnibox/Awesome Bar/whatever a lot, I think it is ultimately a mistake: there are too many search terms which end up resolving to domains, esp. for a developer — and it was never a problem to just click in the search bar before I ruined my muscle memory and started clicking in the location bar instead.<p>One of these days I'll just disable it altogether.
To whoever edited my title: The bug report title is inaccurate. It's specifically about HSTS preloads, which is why my original title stated that instead of "gTLDs".