It is exactly the same issue.
A domain is a domain. Google is arbitrarily dictating your CNAME from the user's perspective.
What if you don't serve your site off of mysite.com is google going to automatically try again at www.mysite.com?
What if you have distinct content at both domains?
This decision is stupid.
If you have an example of somebody who needs to serve different web content for foo.com and www.foo.com, I look forward to seeing it. But I've never seen one, and when I've seen it happen accidentally it's due to idiocy.
Sometimes. Far from always.
In some environments, `www` may be under an entirely different administrative domain, with lesser authority than the top level domain which is delegating web services to the `www` group by way of creating a dns record and/or adding an http(s) redirect to the parent domain.
Having some string values arbitrarily considered trivial is dangerous.
See: lbl.gov has address 128.3.41.146 vs www.lbl.gov has address 35.196.135.136
The root domain points to hosts at the lab. The subdomain has been delegated off to Google.
These string values are already considered equivalent, which is why Chrome is making this change, and why every reasonable site has one redirect to the other.
Often these separate groups aren't part of the same organization. They're a different organization or contractor paid to maintain a web presence.
The third and ninth comments in the linked bug present real world examples of this behavior.
The 3rd is about pool.ntp.org, which is a random ntp server, and which shouldn't be serving up web content. They did happen to pick www.pool.ntp.org as the URL for the docs on the NTP Pool Project, but if "www" never was a thing, the would have happily picked something else. E.g. poolproject.ntp.org or ntp.org/pool/ would have been fine.
Just as ftp.mysite.com is not mysite.com and mysite.com in not mysite.io and http://mysite.com is not https://mysite.com. You get the point.
They are all different and important in my opinion. Any argument that hiding the "www." part makes it easier for the user is equally applicable (and wrong) to ".com"
http://www.ntppool.org is not http://pool.ntp.org
and
https://citibank.com.sg is not https://www.citibank.com.sg
and
https://m.tumblr.com/ is not https://www.tumblr.com/
Yet Google makes them all appear to be the same.
There are lots of other odd filtering behaviors in the issue if you want to check out the comments
For example, should:
www.www.www.subdomain.www.www.www.domain.com show as subdomain.domain.com
How is that right?
How does making those two destinations appear to be the same thing make the user "safer" under any stretch of the imagination?
As I mention elsewhere, the first two are bad examples. (In fact. ntppool.org and www.ntppool.org are the same thing.) The third is a hack from the era where responsive design, browser sniffing, and polyfills didn't exist. It should probably die too, but doesn't have to here. The m.tumblr.com name is distinct from tumblr.com and is of the form I think better. Note that they didn't use www.m.tumblr.com.
This happen fairly often in universities and some other organizations that can have convoluted structure.
Most sites in English, and even that is doubtful.
There's a full world out there of people and businesses using ccTLD like .fr, .nl, .co.uk, .hr, .rs, .es, .jp...
Of the TDL you mention the top one is .jp at less than 2%. If you remove the qualifier under the .uk TLD you get an additional 2%. The rest don't make the chart.
https://www.statista.com/statistics/265677/number-of-interne...
No, it was useful when abstracting machine identity from domain names such that there was a many-to-many relationship was less common, so “www” was the most specific domain name element for the server being accessed. (And a system that needed more than one server might have a homepage on “www”, and various subsites and apps on “www1”, “www2”, etc.)
OTOH, there may be places that still allocate servers that way for simplicity.
Browsers don't use SRV records for HTTP. With them one wouldn't need www subdomain CNAME hacks.
If I were solving this, I'd instead push to eliminate "www" altogether, not sweep it under the rug. It was useful circa 1996, when users might plausibly be using something other than the WWW with a browser. But it has become entirely vestigial.