Chrome breaks my website by hiding www in address bar
I have a personal website, let's call it "www.myname.com", that is visited somewhat frequently by various people. However, when they are sent to my website, will Chrome correctly inform them they are currently viewing "www.myname.com"? No. It (incorrectly and baselessly) assumes the www must be meaningless, and lies to the user by showing the website address as simply "myname.com" instead.
The crux of the issue is that the root domain "myname.com" does NOT point to my website, and will simply time out without a response. There is nothing I can do to fix this. My domain host does not allow ALIAS records on the root domain, only A records. Conversely, my server host (Heroku) does not allow A records for routing, only ALIAS. As such, I'm stuck with the www solution.
Basically, if a visitor remembers the address Chrome shows them on my website and tries to revisit it via "myname.com", they will simply be sent into the void, with no idea of what is happening.
There is no justification for hiding the subdomain from the url. The subdomain and the root domain point to DIFFERENT locations, and Chrome will NEVER know if the difference is significant or not. Redirecting www to the root domain is just a cultural norm. What's next? Showing "fruit.com" when you visit "apple.com" because it's linguistically similar and maybe could point to the same place? Apparently showing the correct address of the website doesn't matter, so I see no reason not to.
And what's the potential upside for the user? Saving 3 characters and a dot in the address bar. Is it really worth breaking the domain name system for that?
Stop it, please.
P.S. Everything I've mentioned above applies to Safari as well.
P.P.S. I suspect people will tell me to change domain host or server host. I'm looking into it, but it's a hassle and it would be nice to know Chrome isn't trying to actively trick my visitors in the meantime.
63 comments
[ 4.3 ms ] story [ 136 ms ] threadIt's that visitor only see "example.com" because the www is hidden. When they later type in "example.com" in the address bar to revisit the website (because that's the address chrome shows them) they are just sent into the void with no idea what is happening.
They then go back to my website via some link that was sent them to find the correct url – but again see "example.com" in the address bar and tries to visit it again in a new window – but of course it doesn't work this time either.
The visitor is then thoroughly confused why my website only works when they visit it via a link, and not when they type in the url directly.
Most people (reasonably) assume the text in the address bar shows the correct address, since that's how it works in 99% of cases. URLs containing www are the only exception.
But I think it's equally important that the user can trust their browser to show them the correct URL for the website they are visiting, not a "best guess".
www.example.com is a web server, but example.com is going to point to domain controllers.
You could set up IIS to redirect on the domain controller as a work around, or Chrome could stop hiding important info from users.
You could also train users, but we know how that goes.
But I don't think it's reasonable we should have to play these mind games with the browser because they have arbitrarily decided "www" is always equivalent to the root domain for everyone.
But the fact that someone has implemented a solution doesn't make it okay for Chrome to lie to the user, in my opinion.
If they change the ns records just write a script to auto update your a record to the new ns record.
I sincerely hope you get Google to change their ways, but personally, this coming around again was the motivation I needed to stop using Chrome on Android, and I hope I'm not the only one.
All that said, it's hard to make Google change things, and it's relatively easy to run a static http(s) server that redirects everything to www and maybe serves some HSTS headers. Assuming your traffic is small, you can do this on the smallest vm on any cloud VPS. Or probably on some serverless platform, too.
Edit to add, you can always redirect www to vvvvvv and I think Chrome would show that, and as you noted, Safari likely would too.
Maybe only redirect to v's if the User Agent is Chrome/Safari.
If you visit "news.ycombinator.com", Safari will correctly show "news.ycombinator.com", not the (different) website "ycombinator.com". Unless the subdomain is www, of course, which is hidden.
Safari always hides the path following the domain name, which is probably what you are thinking of.
Maybe you can find a cheap or free host with a A (and AAAA if you feel like it) that can host a quick http redirection to your www domain.
I'm just curious how developers are so blind to the issues of showing a subdomain that they assert that there is NO justification?
Can we perhaps assume a bit more good faith, or just consider that perhaps google has SOME (maybe bad) justification for this change?
I can easily think of MANY reasons to hide the subdomain, starting with the classic secure.bank.chase.com-url.io type phishing sites.
And this is actually illustrated here, if you don't have control over root domain, should google be able to trust your subdomains?
I would suggest that in 2021, if you can't get content to your root domain (or a redirect), you should update how you approach your hosting. I've been able to get content on a root domain for over 15 years.
Ie, look to yourself before ranting at google.
I'm curious, can you think of a good reason to hide only www?
This is a false assumption. Your average user has probably never realized that "www." is not optional, and that with and without it are resolving differently.
This is very much a problem that you can, and should, solve FOR your users via properly configured DNS settings. Otherwise you're picking an odd hill to die on.
I promise I mean no disrespect. In fact, to put it another way, even if Chrome did what you said, it would not solve your issue - which is users failing to reach your site. Hope you can get it sorted with your provided, or switch to another. I've had good luck with Route53 via AWS.
It is a completely sensible assumption that the full domain name will be visible to users at all times. Google is the one who is making their browser do strange things like this that break the web.
Conversely, my partner didn't realise a domain needed https:// at the front to be valid.
It's a tradeoff I suppose. Some people are used to "Facebook" and some people are used to "www.facebook.com" (Apps vs webpages). I think Google are trying to move the web to a more app based setup, where you only see the Facebook logo and the Facebook name. Of course that's a security risk because you can't see the domain name to verify, so they do the closest thing they can and only show you the root domain
What you are not allowed to have is a CNAME record in addition to anything else. So if you want a TXT or SRV or MX record, you can't also have the CNAME. Makes sense as the latter basically means "look here instead".
Shortly after, they started hiding www, and openly said that they intended to eventually hide the amp prefix as well - which would help their own goals.
"www." was never a mistake that needed to be hidden, any more than any other subdomain. I bet that if Firefox had 90% market share and decided to hide the "translate" or the "maps" of maps.google.com, that Google would not find any justification amusing. www is a subdomain, and if a dev doesn't think it should be there, he could just avoid using it.
It opens security issues (by showing the "wrong" URL), usability issues ("read me the URL letter by letter"), and it forces developers to deal with a incorrect setup that can change any day. What if Google then hide "app." or "dev."?
But Google does what is best for Google.
And there is truth to be afraid of Cloudflare. However, that is somewhat of "an appeal to hypocrisy".
The obvious difference is that Google harvests all the data and usage and combines it with other data to profile all of your site's visitors.
Cloudflare is not in that market, and even if they were they don't have the other pieces to combine it with.
But, even leaving that out, Google did its best big bully act to show how much they don't care about you with their CDN, which is totally different than Cloudflare: They required you to modify your site - and even make it slower with heavy opaque scripts - so that they have more control than you do, they abused their search monopoly and the browser monopoly to force you onto their CDN and hurt competing CDNs, they set the guidelines of what resources and how you can send through the CDN (vs CF)...
Sometimes you just want to copy the domain portion of the URL, without the hidden parts (scheme, subdomain).. You think what you select is what you copy? Wrong, Chrome is "smarter" than you and you end up pasting the entire URL, that you did not even see!
Their design meant they had no choice but to break one use case or the other. Either you'd copy an incomplete, invalid URL meant for display purposes, or one containing chars you did not select. Bad UX either way..
I have to admit I don't have much sympathy for this. Do better at hosting your own authoritative dns properly so you can actually control the zone file for your domain. You can do it on a $1 per month virtual machine. It's that low in resource needs.
And no, asking someone to run a $1 server to get around it is not sufficient either. Why would you think a PaaS app would need a dedicated DNS server? Defeats the purpose.
I don't agree at all with chrome mangling stuff in the address bar, but if you're not running your authoritative dns properly and don't have actual control over your zonefile, it's not a good sign.
Of course the routing to my website was broken, and needed a fix.
But if the routing to my website is broken, Chrome clearly should not choose present the broken URL to the user as the location of my website.
You cannot ensure every domain on the internet remains working at all times. But you can ensure your browser will not trick you into sharing a broken domain with others, by falsely presenting it as working to you.
And yes, it is frustrating for chrome to make this change, but it's also really uncommon and not very efficient to have your base domain go nowhere.
A synthetic lookup of the target, with DNS responding behind the scenes with the right magic.
> And yes, it is frustrating for chrome to make this change, but it's also really uncommon and not very efficient to have your base domain go nowhere.
Cloudfare is free just like Google is free. You pay with your data.
I know the feeling but it's not a battle worth fighting. Don't fight the river, sometimes just go with the flow.
- When providing an example of a domain, use example.com, example.net or example.org,[1] not myname.com, mydomain.com, etc.
- www isn't a subdomain; it's a label. www.example.com is a subdomain.[2]
[1] https://datatracker.ietf.org/doc/html/rfc2606#section-3
[2] https://datatracker.ietf.org/doc/html/rfc1034#section-3.1
RFC 6761
https://datatracker.ietf.org/doc/html/rfc6761
If a website doesn't have a record for @ (naked domain), I consider it to be broken.
Google did this in Chrome specifically to enable fuckery with Amp and hide shady behavior.
Their own page ranking penalizes sites that don't use the www prefix. They know both situations are valid, they just found it easy to throw smaller site owners under the bus.
However bad Google is, though, the real culprit is the OP's host. They're not giving users the correct tools to run websites.
www != .
1. In AD, the A records for your domain point to domain controllers, which you most definitely don't want to host your website from.
You might say that perhaps Google played a part in that because it reminded me that I don't necessarily need to put the www. in the address bar.