Chrome breaks my website by hiding www in address bar

Google introduced AMP, and were eager to eventually have the whole web forced through their infrastructure without it being obvious.

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.

Yet nobody seems to have a problem with Cloudflare...

What is it that Cloudflare does that is similar to this ?

I assume he meant that AMP was essentially a CDN, which meant that Google would be hosting the web on their edges, which is similar to what Cloudflare an other CDN's are doing on their edges.

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)...

www stands for world wide web so if you're looking for www with a web browser over that new fangled thing called the Internet, it's redundant.

That is a problem to be fixed by the server, not the client.

One of my pet peeves against chrome's URL is how it breaks copy paste.

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 assumed this was a step in conditioning users to search for the brand (and maybe click on the brand's ad, or a competitor's, instead of the organic listing halfway down the page) instead of navigating directly. They don't even have a chance to make anything when you type in a domain name directly. AOL keywords v2.0.

This is a UX problem, not a technical issue. I think you may be misguided in assuming that if the "www." portion was present to users that they would automatically understand the issue at hand.

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.

> I think you may be misguided in assuming that if the "www." portion was present to users that they would automatically understand the issue at hand.

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.

It is a completely sensible assumption that the full domain name will be visible to users at all times, but it is not a completely sensible assumption that even if it were the case that the whole URL were visible ithisn chrome, that it would solve the issue.

I don't expect Chrome to solve my issue with the broken url. I do, however, expect them to not make it worse by falsely presenting the broken url as a working url to the user (while hiding the one that actually works).

I'm still angry about browsers hiding the http:// and https:// part of URLs. That is part of the URL.

Yes, that is ridiculous! It's not even a URL without the scheme.

Come on now. They gave us the cool looking Lock icon, right /s

I'm not saying that Chrome's behaviour is correct, but in my opinion your DNS configuration is not ideal. If you prefer the www subdomain, it's common practice to at least redirect http(s) requests on the root domain to it. People don't expect a root domain not listening to http(s). They may also skip writing the www and assume your website is broken.

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 agree it's not ideal. But Chrome is making it even worse for absolutely no reason, which really grinds my gears.

If you're willing to use cloud flare, you can set up a page rule on the bare domain to http(s) redirect on the free accounts.

You aren't allowed to have a CNAME on the naked domain - it has to be an A record. It's not a shortcoming of the host. You'll have to make an A record that points to the same IP as www.

You can have an ALIAS on the naked domain.

True, but ALIAS records are not a standard DNS record, but rather a (by now very common) local workaround on the authoritative server.

That's not true. The domain name system doesn't really know about different levels of domains, so such a rule doesn't even make that much sense.

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".

While you're technically correct that the specification doesn't specifically say that you can't have a CNAME on the root domain, it is still true that you cannot have a CNAME on the root domain because DNS requires that you have SOA and NS records on the root domain, which means that a CNAME is not possible due to the rule you cite.

> Thehe 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.

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.

Chrome shouldn't make big changes to requests. Changing the host is unacceptable.

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.

if you own your own domain name and run your own httpd, being able to properly format an authoritative DNS answer so that when people type "burrito.com" into the address bar, it goes to your webserver at www.burrit.com, is a bare minimum level of doing things normally on the internet these days.

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.

I would have hoped it was clear from the P.P.S. that I was working on a fix for the hosting situation.

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.

There's free good DNS hosting out there. Dns.he.net for example.

I find it funny that you'd post this on a site that does exactly this to all displayed URL's.

http://wwwizer.com/naked-domain-redirect

Great service, thanks! I'll implement it immediately.

But the fact that someone has implemented a solution doesn't make it okay for Chrome to lie to the user, in my opinion.

Or use CloudFlare and just create 2 a records to your zone and then setup a url redirect.

If they change the ns records just write a script to auto update your a record to the new ns record.

That service is more than a decade old.

I did not mean to imply someone created it today to solve my specific issue.

From memory, Safari's behavior is a bit different than Chrome. Safari shows just the domain name regardless of what the subdomakn is, but Chrome shows the URL with www removed. It's a subtle difference, but Safari is more obviously showing something that's not usable to type from a screenshot or whatever.

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.

This is not correct.

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.

Any host that doesn't allow proper dns to be setup is a worthless host. The www is essentially a cname and not needed at all in a properly setup and configured dns server.

If you use Cloudflare for your DNS (which is free) they will allow cnames for the base domain, and when someone requests your domain Cloudflare will just query for the result of the cname themselves and return the IP as though you put in an A record. You can additionally choose to proxy your site behind Cloudflare's servers, but you don't have to.

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.

Ie. exactly what other providers call ALIAS records.

A synthetic lookup of the target, with DNS responding behind the scenes with the right magic.

> If you use Cloudflare for your DNS (which is free) they will allow cnames for the base domain, and when someone requests your domain Cloudflare will just query for the result of the cname themselves and return the IP as though you put in an A record. You can additionally choose to proxy your site behind Cloudflare's servers, but you don't have to.

> 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.

Maybe controversial opinion, but I hate seeing www everywhere. It's annoying.

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

Welcome to the pain that those who run Active Directory domains[1] run into.

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.

Honestly switch to cloudflare and stop fighting.

I know the feeling but it's not a battle worth fighting. Don't fight the river, sometimes just go with the flow.

I have to say I no longer type www. into my web browser anymore, every website that I would type the address for I completely skip the www.

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.

"There is no justification for hiding the subdomain from the url."

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.

Chrome happily displays the subdomain for secure.bank.chase.com-url.io, it would only hide it for www.com-url.io. No phishing prevented.

I'm curious, can you think of a good reason to hide only www?

Nitpicks:

- 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

- www.example.com isn't a subdomain; it's a FQDN

subsection1h, learn to cite most recent and applicable IETF.

RFC 6761

https://datatracker.ietf.org/doc/html/rfc6761

Can you change from "www" to something else that won't be filtered? "web.myname.com" might serve the purpose if you could do it.

That's an idea, I'll think about it.

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.

Why are we even using the www subdomain? It's ugly and useless.

If a website doesn't have a record for @ (naked domain), I consider it to be broken.

Because the web operates on standardized protocols, and the use and function of the "www" prefix is a defined and well known part of the protocol. It's got its own dns record, and can be functionally different than a bare site.

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.

I'm sorry for the ignorance, but which protocol states that we need the www.?

I don't think that's what's happening? Chrome doesn't actually redirect from www.example.com to example.com, it just hides the "www." from view?

My problem is not that it automatically redirects to example.com.

It'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.

ahhh, gotcha. Yeah that sounds like a problem the host should offer a remedy for, and if not, whelp, yeah... change of host.

I agree.

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".

One common scenario I could see this being a problem is a Windows domain where the admins chose to use the root domain.

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.

I just get annoyed at the address bar not showing the full address. Thankfully some Chromium derivatives have a toggle to get the full url to show, but only on desktop.