There is an actual (small) reason for the existence of "www" nowadays. You cannot have a CNAME record for the domain apex (example.com). Many dns providers implement a workaround by resolving the CNAME record into A/AAAA records when queried.

https://serverfault.com/questions/613829/why-cant-a-cname-re...

You can but it prevents you from having other records there, which includes things like an MX record. Just a nitpick, as in practice that prevents most people from being able to use a CNAME on the apex.

I upvoted you because you're correct - it's a failing of the system.

My original point still stands though - we used to use 'http://' and 'http://www.' as a signal that this was a web address. I cannot believe this will still stand in 5 years time. The default is now the domain name, not the phone number.

Something that I was struggling with just today. Of all the days to update Chrome... At first I thought my redirect was broken.

Another good point, I forgot about that - thank you.

"www" was not a marketing trick, it was legitimately a different domain, by convention. General users never understood it, so companies started to have to add it to match their weird expectations.

To associate a base domain with a company identity happens to be true MOST of the time, but isnt actually true. Plus, foo.example.com follows different security rules than bar.example.com (CORS, certs, etc)

The problem here is that the precise domain has a technical meaning...but consumers are using it for a different meaning. Once that is also useful BUT NOT THE SAME.

Pretending the url matches this new meaning (and altering the display to match) serves both groups poorly.

There was never a requirement for www. to be anything other than the bare domain for most people. It became useful because it was synonymous with being a web thing right back when people hardly knew what the web was. This was serendipity, which turned out not to be serendipitous when people had to write it on signs / read it out on an advert etc.

I see no reason now to associate www. with the web version of your service. If I receive a request on port 80 or 443 for the bare domain, what's a better option than service the 99% of people who want a webpage?

You are splitting hairs on this one.

> It became useful because it was synonymous with being a web thing right back when people hardly knew what the web was

You're missing some history here (or we're talking past one another) Back then ( source: lived through it) subdomains for particular protocols were pretty common (www.example.com, ftp.example.com, gopher.example.com, mail.example.com) were pretty common, though not a requirement at all. Almost all the users were technical, so this helped users AND admins. Plus, machines were FAR less powerful back then, so anything exposed to the "public" probably didn't want to handle multiple purposes anyway.

Then non-technical users came in, saw "www.example.com" being used many places, and assumed it was part of the system. New domains either created a "www" subdomain or lost traffic (until browsers started trying to compensate). Note that what we're discussing is a switch in behavior. Prior to what the article is discussing, a browser would try the domain as typed, and if it failed would try prepending "www" AND ADD IT.

> I see no reason now to associate www. with the web version of your service

First, you still have people that type the "www" automatically because they never learned that was technically incorrect.

Second, what if you're reselling subdomains? The concept of "base domain == identity" is relatively recent and possibly temporary.

Third, what if you don't HAVE a single "web version of your service"?

The internet (and the web) has succeeded (granted, half by accident) by providing loose rules so practices can evolve inside those rules. If we start encoding the current practices in the rules, the rules no longer handle evolution well (or possibly at all).

I'm splitting hairs because hairs sometimes matter.

Sure, perhaps there is no reason to associate www. But the issue here is a browser showing an incorrect url.

Message 3[1] in the linked discussion has a great counter-example: "How will you distinguish http://www.pool.ntp.org vs http://pool.ntp.org ?

One takes you to the website about the project, the other goes to a random ntp server."

I do totally agree about m., but it's not Google's place to dictate that, rather it's a decision for each entity to make for themselves.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=881410...

Easy answer. If you end up where you wanted to go, you are in the right place. If not, google it. This is how the vast vast majority of users behave.

What about amp. prefix? You know that's the whole point of this, right? They're going to hide the fact that you're viewing the entire web through amp.

Did you look at the bug report? It's rife with valid examples of why this behavior is wrong on Chrome's part. For example, when "www" isn't the first subdomain, Chrome still elides it.

This thread contains many examples of professional technologists who don't know what a URL is. You, for example, don't seem to know what a URL is.

I guarantee you, most non-tech people don't know what a URL is. People know what links are, to the extent that they can click/tap on them to get to some thing, or copy them and share/email them. That's not the same as knowing what they are.

You're making a dangerous assumption about what people know, including yourself.

> "domain.com" isn't ambiguous

But that's because it's .com. Now, there are too many gTLDs, and companies will build their brand around their use of .io, .me, .cs, .es, etc. Just the other day I saw a link that caught my eye to studio.zeldman, and I had to take a moment to hover over the link to see if that was some new branded gTLD.

Nitpicking: .io, .me, and .es are ccTLD (respectively British Indian Ocean Territory, Montenegro, and Spain) and have been around for at least a decade. .cs was a ccTLD for Czechoslovakia.

Ahem. "www" comes from the times, when you had to have a dedicated machine, or, at least, a dedicated network interface, for each service. Hence, you had an FTP server, creatively named "ftp", and your WWW service ran on a host surprisingly named "www". A concept similar to well-known addresses.

That time has never existed. Some did separate things that way, many did not.

That time absolutely existed. Was common. Source: lived through it.

No, it didn't. Some separated services that way, but it was never any more necessary than it is now. Source: used to run an ISP through the early days of the web, and collocated services on the same host all the time.

The idea of the commenter I replied to that you 'had to' have a separate host or interface for each service is flat out false.

When people split it, it was over capacity or manageability concerns, but often we also set up separate hostnames for different services just because it was what people expected; often it pointed to the same hosts.

yep. or ftp (or mail/smtp/whatever) was a single host separate from the web servers, and www was a CNAME to a virtual ip/load balancer.

Still separated physically.

That time wasn't even that long ago.

The point was that this was always a choice - there has never been a point where it was required. My first ISP back in '93 ran mail, web, ftp and shell accounts on a single pc. So did the ISP I cofounded in 95. It isn't and never has been a technical limitation, but a choice down to what worked for you. Especially as address rewriting firewalls also existed back then, so multiple services pointing to the same external IP in no way implied they had to be the same physical host.

For us (early regional ISP, mid-'90s), a lack of separate per-service hostnames caused significant scaling fragility.

In the initial rollout, all services were served from a single physical host with just one listening IP, which the bare 'example.net' resolved to. (Was this naive of us? You bet.) Other service hostnames (www., smtp., etc) were all just either CNAMEs to that hostname, or A records to that IP.

When our SMTP usage started to exceed the capacity of that single host, we tried to move 'smtp.example.net' to a different host. This is when we we discovered that many users were configured to use 'example.net' for SMTP instead. We had to update all of those users' configs before we could turn down SMTP on the original host. (We couldn't afford big-iron load balancers, and they were less common then - we just used DNS round-robin for load distribution).

At that point, we realized that customers were using bare "example.net" for everything - homepage, SMTP, POP3, IMAP, FTP, DNS, shell access - you name it. It was easy to remember - and it worked. So it was hard-coded everywhere - FTP scripts, non-dynamic DNS settings, etc. And this was looong before email clients had automatic configuration detection, so that was all hard-coded, too.

So we had to painfully track down all the users who were still hitting 'example.net' for SMTP, and help them update their configs before we could turn down SMTP on the original ancient host. The other services had to go through a similar painful transition.

We concluded that the only way to prevent this from happening again was to make sure that the bare hostname never offered any services at all - except for a single HTTP service whose sole purpose was to redirect 'example.net' to 'www.example.net'.

From then on, each new vISP domain had the same non-overlapping service namespace ... so that the otherwise inevitable configuration drift would be impossible.

Later, with the rise of things like email autoconfiguration, load balancers, and POP/IMAP multiplexors (like 'smunge'), we had more options. But at the time, avoiding services on 'example.net' was the only way to go (for us). Having a bare 'example.com' as the sole hostname in the browser bar was a sign of brokenness. :)

I wasn't claiming it was a technical limitation or a requirement, just that the time where this happened certainly did exist. Choice or not, the time existed. That was my point. Fair enough.

I disagree about the 'm.domain' convention; it's good and useful. I like the ability to retrieve a mobile site on my desktop, and vice versa. Sometimes I'll be on a site that's difficult to read on mobile, and speculatively try the 'm.domain' - often it will work. When the site itself tries to autodetect what device I'm using, it often makes a poor decision that is not subject to appeal.

On the downside, the m subdomain makes for terrible social media posting.

E.g. a commenter using Wikipedia's mobile site posts a link to said page and desktop viewers are unexpectedly taken to the mobile, not desktop, page.

And Google decision makes it even worse by making the incorrect display incomprehensible.

This whole comment is two-faced.

People know what a URL is. But this issue demonstrates misunderstandings of URLs, as "www.x.y" is not necessarily an official "x.y" page.

"www" == "web address", or "m. is ridiculous" which are annoying fashions (agreed there!), but that has literally zero impact on the security characteristics, implying yet again that people do not understand URLs.

---

No. This comment is a perfect example of why this is not safe to do. It's throwing open the door to abuse.

What makes you think that http requests are the only thing domains are used for? Mentioned elsewhere in this thread, Active Directory requires that the A record for the bare domain be pointed to the PDC.

If you're serving email from example.com, for reputation reasons you should have the bare domain's A record pointed at your primary MX.

I understand that here on HN we're focused around web-based companies, but for every other corporation, there is a plethora of other services served out of a domain -- of which web/www traffic is maybe 10%, if not less. Everything from email to voip to directory services to vpns to crazy internal apps all rely on the corp's domain/domains, and you definitely should not be pointing your bare domain at your web server (which, chances are, is some contractor-built page living on GoDaddy completely outside your own infrastructure).

In a typical company, you'd have some server serving example.com doing some or all of the above. It would then be running a light http server which accepts requests on 80/443 and permanent-redirects them to www.example.com.

This is why www matters.

How about older people? Can your parents explain the difference? Mine can't and I can assure you most of them are the same.

Try this:

Grandma: I'm typing domain.com into my browse on [random device] and it doesn't work.

Nerd grandchild: well that's because it doesn't exist.

Grandma: But it works on my other computer.

Nerd grandchild: that's because the browser tries lots of domains like www.domain, domain.org and so on when you enter domain.

Grandma: yes, I noticed that. When I enter www.domain.com, it automatically corrects it to domain.com. So that's must be the right one, surely?

Nerd grandchild: Nope. domain.com is the correct domain. It's just trying not to confuse you.

Grandma: ?

Good point - but even my mum (65 and not very good with phones or computers) will just bash the bare domain into her browser.If it's got "www." she'll use that, if not she won't. She still knows it's a web thing, the www. for her and everybody else is superfluous.

Things change. We've had something like 30-odd years of URLs. The people who can't deal with this are vanishingly small, and those that can't are likely not your target market; or they're the sort that'll just consider Facebook to be the web.

I'm not disagreeing with your point btw that some people can't deal with this - all I disagree is the extent.

> We've had something like 30-odd years of URLs.

24 from the RFC, 26 from the discussion that led to it, per Wikipedia.

Good point. I was on Janet / ARPANet before the web. Point conceded!

I'd bet good money this change was put in by people younger than the web.

That may be true, and while I wholeheartedly disagree with this change, those that are younger than the web are the next Shepard's of the web.

We're going to see more and more changes that the "old folks of the internet" are going to hate. Some, or even many, of these changes will actually be good changes. We shouldn't prejudice on age.

Again, to be clear, I think this particular change is horribly broken.

Older people care more about consistency than "usability". They can successfully complete long tasks, maybe with several retries but they can, but if they are consistent. Input a long text somewhere, dial 15-20 digit phone number etc. But they can't usually deal with unpredictable situations, where computer will "intelligently" help them, fill parts of the input, when same action is different on different devices, when they need to know how system will behave in advance.

PS: consider how you would guide an older person over the phone when he/she is accessing Citibank website (for which www.citibank is different website), with Chrome will "intelligently" hide essential part of the address.

Agree to that - my experience exactly. Very recent example. My father's using Skype to talk with family. They refreshed UI, he got new version installed and that was it. I've had to answer multiple questions what does this and that button do. "The same dad, it just looks a little bit different." What I got as an answer was "It's placed somewhere else. It is so confusing. Couldn't they just left everything were it's always been..." Thankfully I have remote access to his desktop so I can guide him around in situations like this.

And I am quite sure removing 'www' on the address bar's domains is as confusing.