
Chrome 69: “www.” subdomain missing from URL - gouggoug
https://bugs.chromium.org/p/chromium/issues/detail?id=881410
======
parliament32
Considering a subdomain "trivial" is ridiculous... there's a difference
between "www.example.com" and "example.com". Not only can they serve different
sites, they can even have different DNS records!

It seems that "m." is also considered a trivial subdomain. So when a user
clicks a link to a "m.facebook.com" uri, they'll be confused why FB looks
different when the browser reports it's on "facebook.com".

I sincerely hope Firefox doesn't follow suit.

~~~
trocadero
>there's a difference between "www.example.com" and "example.com"

Can you link to a site where these two are different?

~~~
ddebernardy
From one of the comments there:

[http://www.pool.ntp.org](http://www.pool.ntp.org) vs
[http://pool.ntp.org](http://pool.ntp.org)

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

~~~
trocadero
Those go to the same place for me

~~~
dsl
Some small subset of pool servers run an HTTP server that redirects you to
www. Not all of them. You just got lucky.

~~~
Volundr
That's exactly right. www.pool.ntp.org is the project site. pool.ntp.org is
for getting an NTP server. Which one you get will depend on your location and
random chance. That server will run NTP, but what it happens to run on port
80, if anything, is up to the operator of the server.

------
CmdrKrool
Lots of people saying this is for the benefit of non-technical users.

For me, this is a minor inconvenience, precisely because I'm technically
capable/interested enough to handle the inconsistency.

But this kind of stuff (and I am speaking somewhat generally here) tends to
frustrate me, precisely when I'm trying to educate or deal with a non-
technical user in some capacity where it happens to matter. I can't just tell
them, " _that_ is the address of the page, and that will _always_ lead to the
exact same place if you type it fully and correctly, and that's that". Instead
I have to get my head around what if they're using browser X or operating
system Y, I have to ask on the phone first, "hang on, tell me what you see on
your screen", I have to say to the lady who's eagerly sat in front of me with
pen hovered above paper waiting for me to dictate how to do a thing in
straightforward steps, "well it depends, first you have to check this thing,
and if it's like this then you can do this but it might also be like that in
which case it's a bit different, let me explain" \- and this is usually the
point at which the non-technical user gets tired and throws the book at me.

In short, I think _consistency_ of information and process is usually much
more understandable and useful to users of any level, than the dumb
'simplification' of this half-baked information-hiding.

~~~
euske
I wholeheartedly agree with this. There are two sides of the debate now. One
side says that the machines should be clever enough to guess the user's
intention and go around of their mistakes, while the other side says that the
machines should stay as dumb and square. The question is about who is handling
the complexity of this world, and in my opinion it should be often left to the
human, not to the machines.

~~~
masswerk
The worse outcome may be, if there's an ambiguity involved and the smart
system takes precedent, but occasionally happens to take the wrong route – and
suppresses any feedback for the user to intervene or even notice. Which is
much, where we have arrived by this. I guess, collateral damage has become a
matter of everyday life.

------
sam_goody
Most comments assume that this is for solving user confusion, or security, or
building a better URL scheme, et al.

It's not, that is all smokescreen.

As ivs wrote[1] They are going to hide amp subdomain, so you don't know if
you're looking at AMP or the actual destination. And then suddenly the whole
world funnels through AMP.

And for that reason, it won't be reversed until people call them for what they
are actually trying to do.

[1]:
[https://news.ycombinator.com/item?id=17928939](https://news.ycombinator.com/item?id=17928939)

~~~
untog
AMP pages are served through google.com, though? It's one of the big problems
with them.

~~~
Seirdy
Not always. Sometimes Google results have taken me to websites like
"amp.reddit.com" on mobile.

------
ozfive
This and many other changes over a course of a short period of time have
caused me to go to Firefox exclusively now. I heard Firefox is going to stop
third party cookie tracking altogether. Why not give Google the big finger and
use a different browser? Vote with your cold hard actions if you feel so
strongly about something.

~~~
rckclmbr
I switched to firefox a year ago. Its a little slower, but im a lot happier.

Ive been trying to degoogle as much as reasonable. I moved to fastmail as
well. Still using an android, but would switch if a reasonable alternative
that wasnt iphone came up. Im not paranoid or a privacy nut, just think google
is too involved in my life.

~~~
saintPirelli
Same here. Have you found any viable alternative to the Google Calendar? I'm
at the point where I'm thinking about hosting a calendar project from GitHub
myself.

~~~
kwk1
Nextcloud, whether self-hosted or otherwise, works great! It's just WebDAV.
You can get calendar, contacts, task, and note syncing, and it can even host
your documents for reference management software like Zotero.

------
crazygringo
Safari already hides "www.". In fact it hides everything except the root-level
domain, e.g. "[https://www.google.com/about/"](https://www.google.com/about/")
shows just "[lock] google.com".

Firefox and Opera show the full domain but gray out everything in the entire
URL except the root-level domain, so "www." is gray.

Just saying, de-emphasizing and hiding parts of the URL is clearly a trend.
This isn't just a Google thing.

~~~
nichochar
this is actually the main reason I cannot use Safari. It always boggled my
mind that they made this decision.

For power users, they never look at the url unless they want information from
it, in which case the `www` is valuable.

For low tech users, it can lead to straight up incomprehensible issues, like
sites not rendering properly (think of a `m.*`).

The UI gains are so small, that part of the screen is never really looked at,
but needs to be there, and typically has tons of horizontal room... I don't
get it

~~~
floatingatoll
Low-tech users don’t often understand that a difference could possibly exist
between “m.” and “www.” at all.

However, if it shows the TLD, they can confirm it says “google.com”. Imagine
they’re visiting a Paypal phishing link, to the domain:

www.paypal.com.www.com

The most important thing to show the user is “www.com”, because they’re
expecting “paypal.com”. All the rest is nonessential for protecting users from
bad actor sites.

~~~
boomlinde
Looking at the bug report, Chrome would actually show "www.paypal.com.www.com"
as "paypal.com.com". At least Safari does the wrong thing the right way.

Personally, I always want to see the full URL. It's fine if part of the
domain, the scheme etc. are grayed out to emphasize the second and top level
domains, but don't omit elements that are necessary to fully identify the
resource because the lowest common denominator may think that
fishing.com/paypal.com is paypal.

~~~
floatingatoll
Yep, I verified that bug as well, apparently they never planned for "www"
being somewhere other than at the front of the domain name. Sounds like they
already know, woot!

------
Already__Taken
The UX of moving what I'm looking at instantly under click is very unpleasant
too, www. and http and even the "secure" "not secure" banners is like 200px
shifts.

Lots of google's UI is getting (or has) things shifting instantly under the
pointer it's quite annoying. The new gmail design quick-tools are often in the
way, unknown until you actually click. Hell calling on my phone shifts the
speaker and keypad buttons over instantly when someone picks up. Often placing
the person I just called on hold if they answer too fast.

Wasn't this a pretty well covered UX rule to not move shit around on users. Up
there with don't use modes and the like.

~~~
NathanCH
> The UX of moving what I'm looking at instantly under click is very
> unpleasant too,

Could you expand on this? What are you referring to?

~~~
rhizome
I don't know if it's the same thing, but I'll bite: it's absolutely maddening
to edit or select part of a URL.

Click in the address bar and the entire address is selected, then you click on
any part of it to either select a part or to place your cursor in order to add
to it, after which Chrome appears to first shift the entire URL to the right
in order to show the protocol, then it places the cursor within the shifted
URL under your pointer. This causes (attempted) selections to be established
from some other place in the URL than the user intended.

~~~
Exuma
chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains

~~~
rhizome
This is about Google having a fundamental weakness in product management and
UX, giving me the equivalent of a Windows Registry setting to change is not
helping, practical as it may be.

------
userbinator
Those who are saying this change is to make things "easier" for certain non-
literate users may be correct, but they should consider whether such a
justification is desirable at all from a moral perspective.

No doubt all of us have at some point been forced to learn things that we did
not find particularly useful or pleasant to learn at the time, but then later
experienced a great "satisfaction of knowledge" when faced with a situation in
which that knowledge became advantageous or even essential, and then proceeded
to use it to better ourselves.

Imagine a world in which none of that learning took place; one in which you
never have to think, everything you see and do automatically satisifies you
and keeps you in a blissful state of ignorance. Who makes the decisions in
that world; or rather, who _can_ make those decisions? Who is in charge of
your life? Not you.

Gradually reducing the motivation to learn, by making things "easy" and
hiding/obfuscating anything that could be used as a starting point for more
learning, makes for a population that won't think, won't learn, won't question
or rebel. It makes them docile and easy to control.

Making statements like "ordinary users will never learn" is one thing, but
explicitly making decisions to ensure that status quo is a horrible trend.
It's quite a genius plan, and certainly used by organisations other than
Google, but thoroughly disturbing.

I've said a few times before in the past: "knowledge is power --- they don't
want you to have too much."

~~~
pdkl95
Some of my comments from 4 years ago when Chrome hiding URLs was just an
"experiment":

[https://news.ycombinator.com/item?id=7694919](https://news.ycombinator.com/item?id=7694919)

------
fireattack
I'm ok with hiding "www.", but it also hides "m." which is sometimes very
confusing (I once opened a m.facebook.com link and was very puzzled why it
uses the mobile site when the URl bar just shows "facebook.com").

~~~
idbehold
What you may be surprised to learn is that Chrome isn't just stripping "www."
from the beginning of the subdomain. "subdomain.www.domain.com" displays as
"subdomain.domain.com"

~~~
Klathmon
I just downloaded canary and tried it and you are absolutely right.

about.www.github.io shows as about.github.io

I'm on board with this change in general, but this is absolutely something
that needs to be fixed.

Not only is that just annoying and wrong, but it could be dangerous in some
situations.

Also, it doesn't just stop at one removal.

    
    
        http://www.www.about.www.www.stuff.www.www.example.com
    

shows as

    
    
        about.stuff.example.com
    

Interestingly though it doesn't remove it if it's the TLD, or the actual
domain (so stuff.www.whatever shows as stuff.www.whatever).

~~~
mrunkel
I'm guessing this is implemented as s/www\\.//

~~~
evozer
Here is the implementation:
[https://github.com/chromium/chromium/blob/master/components/...](https://github.com/chromium/chromium/blob/master/components/url_formatter/url_formatter.cc#L71)

------
austincummings
Looks like this is intentional. To change it back go to
chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains and
disable the setting.

~~~
chch
Additionally, if this flag ever goes away, the
"kFormatUrlOmitTrivialSubdomains" is the internal flag for this, it seems[1],
though its description says it's "Not in kFormatUrlOmitDefaults"[2].

Back when they removed the "http:" off of URLs, I used to use a hex editor to
turn the kFormatUrlOmitHTTP bit flag off every time I got a new build, so I'd
get the URL formatting I wanted, but eventually lost the mental wherewithal to
continue the hack every week.

[1]
[https://github.com/chromium/chromium/blob/3d41e77125f3de8d72...](https://github.com/chromium/chromium/blob/3d41e77125f3de8d722b6d8303599abaf2a91667/components/url_formatter/url_formatter.cc#L454)

[2]
[https://github.com/chromium/chromium/blob/78aae16be65e409075...](https://github.com/chromium/chromium/blob/78aae16be65e409075816860e948d1536a548234/components/url_formatter/url_formatter.h#L82)

~~~
exikyut
I have wanted to figure out for ages how to compute the location of these
types of flags/vars in binary files.

Incidentally I want to figure out how to do this on Linux.

I presume I need debug symbol files, which I can download easily.

How would I do this?

------
wolco
I hope people start moving from chrome to firefox. The standards they pushing
are harming the web in ways.

~~~
fastball
If only Firefox's JS handling didn't melt my laptop.

~~~
inetknght
Then turn it off.

~~~
fastball
I actually like to use websites that were made in the last decade, so instead
of doing that I just use Chrome.

------
theandrewbailey
It begins. I saw this this morning, and thought it was something that was
coming in the next few versions, not _right now_.

[https://www.wired.com/story/google-wants-to-kill-the-
url/](https://www.wired.com/story/google-wants-to-kill-the-url/)

WTF? People get angry when you just move their cheese without notice.

~~~
komali2
>People get angry when you just move their cheese without notice.

Sorry, unrelated, but ahah, what is this saying? I love it and have never
heard it before. I guess it's from some sort of book?
[https://hbswk.hbs.edu/item/cheese-moving-effecting-change-
ra...](https://hbswk.hbs.edu/item/cheese-moving-effecting-change-rather-than-
accepting-it)

~~~
theandrewbailey
It's an idiom.

[https://www.quora.com/What-exactly-does-who-moved-my-
cheese-...](https://www.quora.com/What-exactly-does-who-moved-my-cheese-mean)

------
lucideer
Even if you believe this is in theory a good idea, in practice it's clear that
Chrome has implemented this extremely badly.

As Comment 5 on that issue points out:

> _This does appear to be inconsistent /improperly implemented. Why is www
> hidden twice if the domain is "www.www.2ld.tld"? [...] If the root zone is a
> 301 to the "www" version, removing "www" from the omnibox would be
> acceptable since the server indicated the root zone isn't intended for use.
> This isn't the behavior, though._

> _If example.com returns a 403 status, and www.example.com returns a 404
> status, the www version is still hidden from the user. The www and the root
> are very obviously different pages and serve different purposes, so I
> believe the should be some logic regarding whether or not www should be
> hidden._

It's not very difficult to come up with a simple algorithm that checks HTTP
standard responses and implements this in a sensible way: it seems Chrome's
developers haven't even stopped to think about how this should be done
properly though.

This is not so much a new policy issue as a buggy implementation issue.

~~~
snsr
Even dumber, from another comment-

> Another case I ran into:

> "subdomain.www.domain.com" displays as "subdomain.domain.com".

~~~
Avamander
And people like github.com/m can now host something and it'll look as
`github.io` hosted it.

------
bopbop
This is the third story today about a Google's handling/intentions towards web
addresses and general webpages. The theme is Google wants/may want to push a
new set of Google orientated web standards. This seems the least likely of the
three to be strategically related,however.

The other two: Google may/may not be pushing the open web standard towards
their own AMP pages, instead:

[https://news.ycombinator.com/item?id=17920720](https://news.ycombinator.com/item?id=17920720)

Google wants to get rid of URLs but doesn't know what to replace it with:

[https://news.ycombinator.com/item?id=17925761](https://news.ycombinator.com/item?id=17925761)

------
ValentineC
I stumbled upon this bug too, and here's why this is not okay to me:

For a couple of hours, I thought Citibank Singapore's website was down.

If one tries accessing citibank.com.sg, there's no redirect to the www.
subdomain. (That's still the case, if anyone wants to try.)

If Chrome didn't hide the www., I would have been able to tell from Chrome's
search/address bar that the various banking services that I've been accessing
were all on the www. subdomain.

While that is shoddy implementation on Citibank's part, hiding the www. most
definitely didn't help with the troubleshooting process.

~~~
crispyporkbites
It's not a shoddy implementation on Citibank's part. Google are just fucking
the web over so we all have to fit their structure.

This is standard incumbent behaviour, they are drawing up the moat bridge,
inch by inch.

~~~
lvs
I think the downvotes here are uncalled-for. This is correct. Google is
leveraging a dominant market position to make seemingly frivolous changes that
will ultimately benefit them commercially.

Come on, you know where this is going: They are going to hide amp subdomain,
so you don't know if you're looking at AMP or the actual destination. And then
suddenly the whole world funnels through AMP.

~~~
_pmf_
> Come on, you know where this is going: They are going to hide amp subdomain,
> so you don't know if you're looking at AMP or the actual destination. And
> then suddenly the whole world funnels through AMP.

That's probably the reason for this utterly bizarre change.

~~~
kmlx
isn't it because urls are Number 1 for phishing thou? wouldn't removing urls
altogether and move towards full identity checks be better for the web? and
relying on citibank singapore to hire the right people to fix their website...
never going to happen.

~~~
sherman_google
> wouldn't removing urls altogether and move towards full identity checks be
> better for the web?

Hey we'd be open to it, but we'd really prefer to have an RFC to read...

Instead, we got a quiet auto-update, without patch notes.

Good bye, open web. It was fun while it lasted.

------
jwr
This is idiotic and harmful. We already lost information about the protocol,
because somebody believed it is "too complex" for users. Now we're losing
other parts of the URL. It's making a joke of the SSL/TLS padlock, too — what
exactly is the padlock supposed to tell me? It used to signify that a "known
authority" certified that I'm connected to whatever I see in the URL bar. But
now that browsers take liberties with modifying the URL bar as they see fit,
it becomes increasingly meaningless.

~~~
soared
99.9% of users have no idea what any of the words you just said mean. The
change was made for them, not for you (the .1%)

~~~
wpietri
You're missing jwr's point. He's arguing that this is harmful for users,
especially the ones who don't know what the words mean.

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.

~~~
uberman
Why not drop .com then as well? Most sites are on .com domains after all.

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.

~~~
wpietri
It's not the same issue at all, in that domains with different suffixes are
controlled by different people while foo.com and www.foo.com are controlled by
the same people.

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.

~~~
subway
> while foo.com and www.foo.com are controlled by the same people

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.

~~~
slg
Isn't that simply due to internal politics? Whoever owns foo.com might
delegate www.foo.com to someone else, but they ultimately control both.

~~~
subway
It's due to different groups controlling different parts of the
infrastructure, allowing for separation of privilege -- and is the whole
reason www even existed to begin with.

Often these separate groups _aren 't_ part of the same organization. They're a
different organization or contractor paid to maintain a web presence.

~~~
slg
Yes, but those are decisions made by whoever controls foo.com. This may not be
a good decision by Google, but I don't think they should be held responsible
for a decision that was made by whoever controls foo.com.

~~~
muraiki
This is completely backwards, because Google just made this decision _now_!

------
Klonoar
Yo, this is... going too far, c'mon now.

While sure, www seems odd now, it's still a subdomain and we're inching into
territory of obscuring things that matter for small gains in end-user
perception that aren't _that_ impactful.

~~~
asimpletune
Yeah this is weird. Which users are bothered enough by the leading www enough
to justify messing with semantics?

~~~
_wmd
My bet is this decision is driven somewhere by marketing morons who want
'www.google' (presumably a domain that will at some point exist, the TLD
already does) to render as simply 'google'

~~~
parliament32
Technically there's no reason why a TLD can't have an A record. If they own
"google." they can point it to whatever address and serve whatever they want.

~~~
ucarion
Until recently, [http://ai](http://ai) did exactly this. They also had MX
records, so n@ai was a valid email address.

~~~
hunter2_
That link works fine for me. It doesn't for you?

------
DamnInteresting
If the browser uses some technique to detect that www.domain.com is
functionally identical to domain.com for a given domain, then I don't see a
serious problem with this. But if they are short of that certainty, they're
obscuring a critical part of the URL, and harming usability (e.g., if I want
to jot down a site's URL for later use, I might get something unexpected).

~~~
teilo
That's not the case. I run a server that does not respond to "www." If I enter
"www.myserver.com" into the address bar, I get a DNS lookup failure, but the
address bar is now showing "myserver.com." That's damn confusing, and this is
an idiotic default on Chrome's part.

~~~
lozenge
That seems like an edge case worth submitting a separate bug for.

~~~
king_phil
Think public suffixes! It is long, so definitely not an edge case.

You can write a small script to look up all PSL domains and check if the www
and APEX domain has the same dns records.

Our implementation (we control 15 or so) does not, have a www-subdomain for
the domains. Anybody can register the www-subdomains.

------
CGamesPlay
Lest anyone think that Chrome is being innovative here, this is Safari's
default behavior for when the URL bar isn't focused. When you click on the URL
bar, the subdomain, protocol, and path all appear.

~~~
stronglikedan
Which drives me crazy, because my users send me screenshots in support
requests. Now I have to spend even more time explaining to them how to
click/copy/paste the URL. It was a terrible UX choice when Safari did it, and
it's a terrible UX choice now that Chrome has done it.

~~~
qubitcoder
Fortunately, it's trivial to toggle this setting in the Safari preferences--
and then the full URL will appear by default.

------
normo12
Suddenly "www.com"'s value has skyrocketed in the eyes of scammers. How about:

* login.<target_site>.www.com -> login.<target_site>.com

* members.<target_site>.www.com -> members.<target_site>.com

Even some carefully chosen <target_site>.www.com's will now be valuable:

* login.www.<target_site>.www.com -> login.<target_site>.com

What a stupid idea...

~~~
Ajedi32
That's just a bug which I'm sure will be fixed in the next release.

For this to actually help scammers (after the bug is fixed) they'd need to own
www.example.com but not example.com, which is unlikely to say the least.

~~~
normo12
Yes, it is a bug, but until it's fixed it's a potential attack vector.

------
combatentropy
Dear Google, just do syntax highlighting. Make the subdomain gray. You can
even color https: green and http: red. But don't hide them. I really think
syntax highlighting will accomplish the same thing for less technical users.

~~~
theyinwhy
Grey is usually understood as greyed out: not selectable, non-functional and
therefore counter-intuitive as well.

------
soared
Why does this matter? Users don't care and its easier to remember/understand
that all websites are just "x.com" rather than sometimes being "www.x.com". If
you have some server/troubleshooting/network/dev problem with it, the missing
info should be moved to developer tools.

This is just removing data that is useless and confusing to 99.9% of users -
whats the problem?

~~~
crispyporkbites
Because they are on www. and not *.

What happens when you copy and paste that URL?

Now every single website that wants to support Chrome needs to ensure that
[https://foo.com](https://foo.com) is always redirected to
[https://www.foo.com](https://www.foo.com), or at least works as if it's www.
It doesn't matter that most websites already do this, it's not standard, and
represents Google breaking standards because they are big enough to do their
own thing.

It's just one of the 1000s of papercuts that google is inflicting to keep
users from switching web browser.

~~~
eclipxe
When you copy and paste, it has the whole URL - just like when you copy and
paste now it will include http(s)://

~~~
pishpash
What if you visually copy and paste? Parent is right.

~~~
kowdermeister
One more reason to set up a redirect from or to www. _

~~~
lwansbrough
Many MANY legacy sites serve different information at those two domains.

~~~
baby
And this is wrong.

~~~
tazard
Maybe you have a niche target and not looking for mass adoption. It's not
"wrong" it's just not normally the way things are done.

------
bguillet
This reminds me of Windows hiding file extensions by default. So annoying...
now you don't know what your dealing with, it's harder to modify etc

------
1zael
Seriously? This is such a bad change, I hope they revert this patch in the
next update. There's a world of difference between the two and this is going
to cause an ecosystem nightmare.

------
ronilan
That took just 8 years....

[http://blogoscoped.com/archive/2010-09-17-n17.html](http://blogoscoped.com/archive/2010-09-17-n17.html)

------
abalone
_> This is a dumb change. No part of a domain should be considered "trivial".
As an ISP, we often have to go to great lengths to teach users that
"www.domain.com" and "domain.com" are two different domains..._

What ISPs teach their users anymore these days? Why the heck do we want to go
back to that?

Time for a modicum of historical perspective.

If you care about usability this is clearly an improvement. This is part of a
long-running industry trend -- Safari does this too -- to improve the
usability of the Internet and technology in general.

At EVERY STEP in that journey there has whining and griping from the more
technically advanced folks (like all of us on this forum). They zero in on the
negatives, the tradeoffs that come with simplification. They don't see the
positives because they're technically advanced enough and don't benefit from
simplification (or so they think).

Then after the griping whines (sic) down and they realize the world didn't end
and the downsides really weren't that bad and we move forward towards a
better, simpler, more usable web.

Like, who actually runs separate HTTP servers on example.com and
www.example.com anyway? Everyone is hyperventilating over contrived "the
principle of it all" examples. Bottom line, Apple & Google are putting
usability above technical pedantry. That's the right priority for mass market
technology products.

~~~
slenk
Two prominent examples noted in the bug:
[https://citibank.com.sg](https://citibank.com.sg) and
[https://www.citibank.com.sg](https://www.citibank.com.sg) are different,
[http://www.pool.ntp.org](http://www.pool.ntp.org) and
[http://pool.ntp.org](http://pool.ntp.org) are different.

Like, big companies run separate servers on the two domains.

That's besides the fact where if you have www.example.www.example.com, it
rewrites to example.example.com.

~~~
DougBTX
The first citibank url doesn’t load for me, so it is site vs not site rather
than two different sites, and both those ntp urls are redirecting me to
[https://www.ntppool.org/en/](https://www.ntppool.org/en/) \- perhaps there’s
less substance than meets the eye to those complaints.

~~~
hrez
user1 - [https://citibank.com.sg](https://citibank.com.sg) doesn't work for me

user2 - it's fine, here is a screenshot of it working (while showing
"beautified" [https://www.citibank.com.sg](https://www.citibank.com.sg))

how is that not confusing?

~~~
wingworks
I think it's more on the website owners to fix their sites, users expect
domain.com to be the same/auto-redirected to www.domain.com or vice versa. I
think it's a good thing what Chrome is doing, it will push website owners to
correctly set up their domain redirects and in the end, lessen end-user
confusion.

~~~
NathanCH
I think this is a fair comment but Chrome has been doing this a lot lately.
They'll make a change and developers must scramble to fix their websites.

It's the same with autocomplete earlier this year. One day Google decides to
ignore autocomplete="off" and all hell breaks lose.

Interesting to note, they have reverted this change. Google now respects
autocomplete="off" in some scenarios (i.e. when autofill is not triggered via
name attribute).

Note: autocomplete !== autofill

------
ihuman
Is this really a big deal? Don't many websites either redirect the www to the
non-www, or the other way around?

~~~
theprotocol
It's about the principle. www is a valid subdomain.

Browsers are supposed to be as unopinionated as possible since they are
_browsers_ , not mediators, and their job is to implement the standards of the
web.

~~~
eli
You want your browser to show unlimited popup windows too?

~~~
aarongray
No, but I want my browser to notify me that its blocking popups rather than
just hiding them from me entirely and assuming I never wanted to see them
anyway.

------
darth_mastah
To be honest, I want to see the actual domain I'm on in the location bar, and
not some obscured version of it. In what universe is hiding part of the domain
an usability improvement? What does it improve? Confusion? Misinformation?
Lack of trust in the location showed by the browser? It's so stupid I had to
check the calendar to make sure it's not the 1st of April today. I didn't
check it in Chrome though, for fear that some days might have been hidden away
as they have been considered trivial.

------
jklinger410
You know, as much as I'm all for considering www a trivial subdomain, this
should have had much more public discussion before implementing it into the
most used browser in the world.

------
teilo
To be clear, the "www" is only missing from the URL that is displayed in the
address bar, while the browser is still attempting to resolve and fetch the
URL with the "www." So instead of something that would completely break many
websites, this is just something that is as confusing as hell for no good
reason.

When a website requires "www" to resolve and respond, who in their right mind
would want it hidden in the displayed URL?

------
tenebrisalietum
URLs can be complex and sometimes not intended for human consumption.

So fine, don't display the URL. Define a full-on standard that lets a user
agent show a "friendly but not unwieldy" name to the user. You have that funky
Graph API or whatever Facebook started to allow URL posts in Facebook to
expand to include site info. Why not just use that at the top of browse? Then
design the browser to allow access and editing of the URL somehow if desired
(an old browser called 'OB1' didn't display the URL unless you pressed Ctrl-W,
for example), but don't display it by default.

The truth is probably not many technical people directly enter URLs in
browsers any more.

Honestly maybe it wasn't a good idea to allow query strings in URLs. Perhaps
deprecate them and keep URLs looking like hierarchical filenames. Which
honestly, is still something difficult to understand for non-technical people.

But this crap of hiding parts of it is dumb.

------
pdeuchler
I, for one, cannot wait until this is exploited somehow by phishers

------
nbrempel
Safari has been doing this for some time.

The "trivial subdomain" will show when you click the url bar, however.

~~~
firloop
I'm much more okay with Safari's implementation, because it's significantly
more discoverable. Safari also makes it much simpler to disable this behavior
altogether, with it earning a place in the settings ... rather than being
behind some "flag" that may disappear in some future release.

------
tankenmate
Google has signed a contract with ICANN as it is a registry and a registrar.
In that contract it has agreed to limit behaviour that affects the security
and stability of the name system. This behaviour of chromium is in
contravention of that contract.

------
type0
I like how hugues.a. summarized it there:

This is Google making subdomain usage decisions for other entities outside of
Google. My domains and how subdomains are assigned and delegated are not
Google's business to decide.

------
akerro
We allowed this to happen, we allowed Google to claim Internet and web, they
make rules now, give up to and embrace hiding www. and to AMP before it's too
late and you're out of the loop.

------
adrianmonk
I can somewhat understand the urge to de-clutter the URL and emphasize which
parts are most important.

But I'd prefer they did it in another way which doesn't involve hiding
anything. For example, render the most important parts of the URL in bold
type, a color that contrasts more, or a slightly larger point size.

That way, you still make it easier for the eye to pick up the parts that the
browser believes probably matter most, but you don't make it impossible to see
the parts that might also matter.

------
JTbane
This makes me glad I use Firefox and have dropped chrome entirely.

------
tripzilch
Google doesn't want you to use URLSs.

It must be this. They haven't given a single positive reason, except "users
need not concern them with this information", which is so vague it's not even
a reason.

Google is still (partly) a search engine, and people interacting with the
address bar is pretty much the opposite of using a search engine. So Google
wants to discourage that. They will never teach users how URLs work, how to
read them and definitely not how to construct them, because it makes people
less dependent on their search engine.

Think about it. Even the security part. Google wants to be the arbiter of what
is secure and what is trustworthy. Anything that lets users figure this out
for themselves, or that can be mediated without Google coming in between,
takes away from this power.

They don't show http/https any more, just a coloured lock icon. The meaning of
that lock icon is for Google to decide, unlike the meaning of http/https.

Now they take away information from the address bar, claiming it is irrelevant
and none of our concern. They just want you to click on the links in their
search engine, or some app or assistant thing.

One thing it is NOT about though, is distraction. If anyone knows that users
can tune out irrelevant information perfectly fine, it's Google. They are an
advertising network, after all.

------
Groxx
> _Why is www hidden twice if the domain is "www.www.2ld.tld"?_

plus

> _" subdomain.www.domain.com" displays as "subdomain.domain.com"._

and

> _[http://m.tumblr.com/](http://m.tumblr.com/) _[1]

Hoo boy. Can we officially call this a "shit-storm"? It seems extremely poorly
thought through.[2]

[1] seriously, visit that right now. utterly brilliant username, I wish them
all the best.

[2] unless you want to sell invisible AMP URLs. but then I want you to lose
your job.

------
ryenus
The issue has only 46 comments at this moment because they have restricted the
permission to comment, very nice. I thought there would be hundreds of,
otherwise.

BTW, it sucks that existing comments cannot be voted or reacted with emojis,
they should know this:
[https://bugs.chromium.org/p/monorail/issues/detail?id=4248](https://bugs.chromium.org/p/monorail/issues/detail?id=4248)

------
webXL
This should have been an opt-in feature. And if enough people opted in, only
then do you make it the default, and _when_ you do that, alert all users to
that change.

Hiding the protocol was understandable. For web pages it was 99% http or
https, and they could convey which with an icon. (iOS Chrome still shows it
for some strange reason). Then mobile Safari dropped everything but the domain
name and everyone freaked out. But you can get everything back in Safari by
clicking on it, but not on Chrome. Such a simple thing to implement.

If anything they could have just hid the query string, unless it's fairly
simple like HN comments pages (item?id=17927972). But with pushstate, you
could just hide the ugly bits (tracking, language, etc.) from the user. Take
this Chrome promo URL:

    
    
      https://www.google.com/chrome/whatsnew/?hl=en&brand=CHZQ&utm_source=google.com&utm_medium=homepagepromo&utm_campaign=m69-whatsnew
    

Using JavaScript, before anything is displayed, simplify it to:

    
    
      www.google.com/chrome/whatsnew 
    

And if you don't like _www._ , don't host at or link to that subdomain!

------
blitmap
Not in favor of Google deciding yet again how I want to browse/view the web.
I've been extricating myself from Google services slowly, and I think it's
time for Firefox again. Kind of arrogant to decide something like this for
more than a billion users, and a step backward for those of us in IT who have
a hard time getting the user to understand a visual difference in the address
bar.

------
jgowdy
If only we had something other than the subdomain to indicate what protocol we
want to use to access the host in question. Like maybe some kind of... port
number and/or protocol prefix.

"www." is useless. Eliminating it wouldn't be a bad thing.

"m." for mobile sites is extremely archaic. Sites should work on mobile
without special subdomains.

If you issue subdomains to strangers on your root domain, the URL bar showing
the subdomain shouldn't be your "security model."

The root domain is the root authority behind the site in question. Chrome
showing users that information in a clear and concise way isn't "subverting
the domain name system".

Safari has been doing this for a long time, and Chrome/Chromium have
settings/flags that allow you to turn this behavior off. The amount of crying
over this change is ridiculous in my opinion. As long as they keep this
configurable (in fact, they should add a UI config for it) I see no problem
here.

~~~
furi
"www." is useless until you have multiple servers. Say you run a game server
and a website on a web server for that game server as well. You need to give
them separate domains so that they can resolve to separate IP addresses i.e.
"www.example.com" might resolve to <web server IP> and "example.com" might
resolve to <game server IP>. This is far more robust, faster and simpler (and
how the system was intended to be used) than trying to set up some kind of
proxying system on one of the servers to handle traffic really intended for
the other one. In real world usage of course you'd probably put the game
server at "game.example.com" and the web server at "example.com" but either
way you end up with a subdomain, the arrangement with "www." as the subdomain
instead of "game." is not really any more useless. I believe this can possibly
be worked around with SRV records but then you have to rely on whatever your
client might be handling SRV records.

> If you issue subdomains to strangers on your root domain, the URL bar
> showing the subdomain shouldn't be your "security model."

What do you propose instead? Azure gives me custom subdomains for my servers
that are immensely useful, being much more regular and memorable than IP
addresses. I only see two solutions here: stop doing that or let anybody with
access to subdomain creation pretend to be "azure.com". One of them is
comically dangerous and the other is throwing out a perfectly good feature to
save a handful of characters in the URL bar.

------
Yizahi
The point of this change is not to mess with www. or m. any other subdomain.
The real reason for this change is obviously from latest google moves is to
hide one and only one subdomain from users - amp. They really don't want you
to know when you are not on independent website but actually inside google
silo, playing by google rules.

------
xg15
Is this supposed to be the first step of this? :
[https://arstechnica.com/gadgets/2018/09/google-wants-to-
get-...](https://arstechnica.com/gadgets/2018/09/google-wants-to-get-rid-of-
urls-but-doesnt-know-what-to-use-instead/)

------
tripzilch
This is such bullshit. They call it a "trade off", but a trade off between
what exactly? On the one side there's a non-trivial number of negative
consequences to this change, and on the other hand, the maintainer person
literally is unable to give _any_ other reason besides, "this isn't
information that most users need to concern themselves with in most cases".

No other reason given besides that _very_ vague assumption about .. I'm not
even sure, say if most users _need_ not concern themselves with information
that isn't there, does that mean they would otherwise be concerned about it?
And what does that mean? And how is it bad? And why don't you just say so?

I'm calling bullshit. If there is a reason why they decided this, it is not
that. My bet it's something political.

------
miguelmota
Surprised to see not a single mention of Brave [1] in this large thread of
comments as an alternative browser. It's not the best for development, but for
casual browsing it's great. Brave blocks all ads and trackers.

[1] [https://brave.com](https://brave.com)

------
adamgravitis
I would just point out that HN does this in the title of every link posted,
and has been doing this for years.

~~~
skykooler
HN removes all subdomains, not just "trivial" ones. That's a separate issue.

------
westoque
As a developer on multi-tenant applications that are mounted on different
subdomains, considering `site.com` same with `www.site.com` should be outright
illegal! There is nothing trivial about the domains above and are considered
separate unless configured to be pointing to the same record.

------
noypi
[http://www3.www.audi.ch/](http://www3.www.audi.ch/)

------
philo23
This is only visually what's displayed in the address bar, similar to how they
started dropping http/https from the start of URLs a while back.

While I'd personally disagree with these kind of changes, and I would always
prefer it to show the http/https and the www dot, it doesn't actually break
things like copy and pasting the URL from the address bar. You still go to
www.google.com when you type in www.google.com, it's just trimming away the
www dot displayed in the address bar.

I think for the vast majority of non-technical people it's not really going to
make even a little bit of difference. If anything it'll make it easier to spot
what domain they're on, assuming they're even checking to begin with.

------
c0nsumer
Have any of you with corporate-type proxies been seeing authentication issues?
Since moving to Chrome 69 a number of our users are reporting repeated proxy
auth prompts when this should normally be handled transparently by Kerberos.

~~~
noinsight
Yes, Chrome 69 has a bug with Kerberos:

[https://bugs.chromium.org/p/chromium/issues/detail?id=872665](https://bugs.chromium.org/p/chromium/issues/detail?id=872665)

~~~
c0nsumer
PS: This becomes REALLY fun if you use cnames to load balance proxies. Which
use Kerberos. <sigh>

------
trjordan
It's technically correct that www.example.com and example.com are different
domains and can serve different stuff.

So are [https://example.com](https://example.com) and
[http://example.com](http://example.com).

If you serve materially different content based on small differences, that's
user-hostile, and common tools have no obligation to support you. Chrome
shouldn't cater to sites that change behavior based on a www prefix, because
the vast majority of users expect those sites to be the same. Hiding the
prefix won't change their mind.

~~~
muraiki
Small differences? A subdomain or an entire protocol is a small difference?
And what about any web site that uses a "m." subdomain that doesn't intend it
for mobile? I don't think that calling these things "small differences" is
reasonable. And really, it makes perfect sense to not serve the same content
over an insecure connection than over a secure one, but thankfully that change
hasn't happened!

------
Multicomp
So now they've added "Restrict-AddIssueComment-EditIssue" to the bug. [Edit:
This means that only users with EditIssue permissions may comment on it]
Apparently we've complained too loudly for their liking.

------
manigandham
Most people don't notice or care, so this change makes no difference for them.
For the few that do care, this change makes things worse.

So basically a dumb design-by-committee change that just wasted effort for
negative progress.

------
CoachRufus87
Thank you to whomever submitted this. My main annoyance is that when I want to
go to a subdomain, I'll typically start typing foo.domain.com, but now the
browser sets it to www.foo.domain.com. Annoying.

~~~
michaelmrose
What browser auto inserts www? It's neither firefox or chrome.

~~~
CoachRufus87
Let me clarify: since the subdomain is hidden, I now have to munge with the
URL input field to just get the full url to show up so that I can then modify
the subdomain.

------
stevewilhelm
If I was designing the user experience for accessing content from a global
information, entertainment, and commerce network that would be used by a
large, global, non-technical user base, I would not use the current URL
format.

I would wager the twelve character prefix
"[https://www."would](https://www."would) make no sense to 99.9% of the users
and should be the default for over 99.9% of requests they would be making any
given day.

I am guessing Google has evidence that this is the case.

------
cc-d
Between this and AMP it looks like google's abusing their market dominance to
seize control over the open internet.

We were able to somewhat break up microsoft's attempt at something similar in
the 90s through anti-trust legislation, perhaps it's time to look at google?

On a side note, it seems like the openness of the internet has come under
attack more and more often in the past few years, from a combination of
corporate and government entities. It's absolutely essential that we keep the
internet open, transparent, and free.

------
Ajedi32
This isn't entirely without precedent. Firefox does something similar by
greying out the `www` in the UI, Chrome just decided to take things a step
further by hiding it entirely.

~~~
gsnedders
Firefox's behaviour is that is makes everything except the eTLD+1 grey,
because that's what's normally useful for evaluating authenticity. There's no
distinction made between `www` and any other subdomain.

~~~
tinus_hn
These are all in the same origin so they can read cookies and manipulate
pages.

~~~
Sohcahtoa82
This is not true unless the cookie is specifically marked to be domain-wide.

There was a time when IE misbehaved. Not sure if this fixed in Edge:
[https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-
to-c...](https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-
domains/)

~~~
gsnedders
> There was a time when IE misbehaved. Not sure if this fixed in Edge:
> [https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-
> to-c...](https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-c..).

Pretty sure that was fixed in Edge _and_ IE (as a security issue).

~~~
Sohcahtoa82
While that certainly may be the case, it's been shown time and time again how
many users (and even sys admins!) are bad at installing patches.

------
makecheck
I don’t understand the war on URLs. I can’t even _edit the link a bookmark
uses_ in some browsers now, which is infuriating for SharePoint or other sites
where “currently displayed URL” is not a clean and canonical URL (even though
one exists). And when the terrible random URL jumble currently in the address
bar won’t even reproduce the page correctly later, this ceases to be a
bookmark.

URLs may be _weird_ but they are _not_ so complex that we need these games.

------
russellbeattie
This is a classic example of techies, marketers and MBAs deciding what is "too
confusing" for "normal" people to understand.

This is why the History channel shows reality TV instead of programs about,
you know, history. It was decided that "history" that doesn't involve
celebrities, aliens or Nazis is just too boring for normal people.

Google has decided that the 50% of population who are confused about the
basics of URLs are more important than the rest of us who have been using them
for over 25 years without problems. This will in theory allow Google to target
a larger swath of the population. In practice, it simply takes something
useful away from the rest of us.

It's "digital ochlocracy": The targeting of the least common denominator to
the detriment of those with greater knowledge or expertise.

~~~
type0
It's more sinister than that, they are devaluing the importance of URL so that
you would have to search for it; the worst is yet to come.

------
xd1936
...I'm okay with this, I think. Has www (http over tcp/ip) not become the
default protocol for "the internet" in the average person's mind?

~~~
QasimK
I think websites should just stop using "www." entirely and host directly on
their domain rather than a subdomain.

~~~
peterwwillis
This causes browser security problems, it creates load balancing issues, it
makes failover harder, etc. Only works for small sites that don't need to be
highly available.

~~~
QasimK
Why does it make loadbalancing and fail-overs harder?

------
mvpu
Spirited discussion! I think for the average Joe, this change does not matter
(i.e neither good, nor bad). Two better changes: a) highlight https / secure
connections even more prominently, and b) detect and highlight misspelled
domain names (a major cause of phishing attacks). Rationale is that for the
average Joe, a clear warning that they are about to go to a bad site is more
valuable than looking at the accurate domain name.

------
hughes
Anyone know if this checks for a DNS record that supports equivalency between
the www/empty subdomains? It's possible for them to have different values.

~~~
fpoling
Even if DNS is the same, the host receives full host name in http and/or TLS
headers and can trivially serve different content.

------
ezequiel-garzon
Whether "we" like it or not, URLs are increasingly becoming a rare techy term.
It is no wonder the average user has a problem with URLs with the advent of
omnibars. I for one can't sometimes "force" Chrome to go to domain.com instead
of searching that expression. Oh, and try to view the full URL you're
accessing on your iPhone, particularly if you're GETting something other than
/.

------
throwawaymath
I like the implementation bug mentioned that shortens
subdomain.www.example.com to subdomain.example.com. That's just actively
dangerous for users.

------
JoshMnem
Looking at everything that Google is doing at the moment, it looks like a
shameful power grab for the entire WWW.

I suspect that Google wants to gradually get rid of URLs, because if users
can't identify websites by their addresses, they will be more dependent on
Google Search. Landing on search pages means that users will click on more of
their well-concealed ads.

I think it's also the reason why Google Chrome's URL bar has such terrible
auto-completion functionality. It appears designed to send users to Google
Search to click on ads instead of taking them directly to their destinations.
Firefox's old address bar didn't do that. (The newer address bar in Firefox
appears to be following Chrome's time-wasting functionality, and its auto-
completion no longer works well.)

Without URLs, users won't know whether they are really on your site, viewing
your content on google.com (via AMP), or in some kind of app or PWA. To get to
an item of content, most people will end up clicking on an ad in Google Search
or land on an AMP page that eliminates most monetization options that don't
involve passing the money through Google's systems.

URLs shouldn't be trimmed at all. When you're on the URL,
[http://example.com/](http://example.com/), (note the trailing slash), Chrome
will only display "[http://example.com"](http://example.com"), even if you
copy it onto the clipboard. (It's still possible to fix it in Firefox with
about:config.)

Technology shouldn't be made more restrictive and stupid -- users should be
taught how to use technology correctly, and they will adjust. I've even met
professional programmers who don't really understand URLs because their
browsers mask the real URLs. The WWW isn't only about consumption -- it's
about creating as well. People need to know how it works in order to create
things.

------
jrnichols
When people say they're sick of Google deciding what's good for the whole
internet and leveraging their massive marketshare.. it's stuff like this
they're talking about. Other little things too like their own non-standard
implementation of IMAP/POP stuff. Invisible to most average users, who
continue to merrily click away on Google $EVERYTHING and Gmail.

------
pluma
Isn't this the same logic that still results in Windows users running malware
because someone sent them _sexy_nudes.jpeg.exe_?

------
nofunsir
I'm going to assume there will be no convincing The Team of people whose
Wonderful Idea this was. [https://www.wired.com/2016/11/googles-chrome-
hackers-flip-we...](https://www.wired.com/2016/11/googles-chrome-hackers-flip-
webs-security-model/)

No more red purses? Give me a break.

------
lwansbrough
Surely Google of all companies has the resources to see exactly how much
disruption this will actually cause. And I don't believe they get to make the
decision based on that, but they should share the numbers. Any domain that
returns different content between "m." and "www." vs. the apex domain are
affected.

------
lvs
Does it hide AMP subdomain? If so, I think we all know what this is about, and
it's dirty and should be stopped.

------
Domesist
Google shouldn't be the authority to decide whether one Domains' part or
another is "trivial".

------
PinselPanther
This is kind of what happened to the KeeFox addon for Firefox. The developer
one day decided to have a new default for URL matching. Instead of matching
the hostname, i.e. old.reddit.com, it would then match the 'domain' i.e
*reddit.com. Back then it was as stupid as this is now...

------
vinceguidry
I am in favor of the change. I do not think hiding technical information from
non-technical users is a bad thing. Making it impossible for technical users
to work it out is the bad thing.

If technical users want their own browser mode, where all these things are
readily available, then I'd be all for that.

Clicking on the browser location bar should reveal the full URL. But the noise
of the protocol, the www. prefix, and the param string is all irrelevant to
the experience of the casual user of web browsers and should indeed be hidden.
We're already hiding a ton of stuff from them already, if you want to go see
it, you can always "view source".

One argument in the thread was that 'www.pool.ntp.org' and 'pool.ntp.org' go
to a website and a nameserver respectively. Nontechnical users will never want
to use a web browser to access a nameserver, so there's no UX benefit to
distinguishing them. From a URL entry standpoint, it should go to the URL that
was typed into the location bar. There isn't a conflict.

~~~
shiado
It breaks how the web is supposed to function. There is no consensus on the
utilization of subdomains and which ones are considered to be trivial. I could
write an app which maps usernames to subdomains and Chrome would break this if
a user had a username which was in the trivial list. I think Tumblr is a site
which does this. It really isn't about technical or non-technical, it is about
what subdomains can be used for.

Edit: well I was right, this breaks in the new Chrome,
[http://m.tumblr.com/](http://m.tumblr.com/) , tumblr usernames on the
'trivial' list are broken.

~~~
vinceguidry
There's no such thing as "how the web is supposed to function." There is an
ideal that the plurality of the early web once sought to chase. There are more
ideals that the more commerce-friendly users and creators of the web started
to chase.

The norm is always shifting. It's our job as technologists to accommodate how
people want to use technology, not to tell them that the way they want to use
it is wrong. Because if we try to tell them no, then they're going to use the
freedoms we labored so hard to give them to stop listening to us.

~~~
type0
> There are more ideals that the more commerce-friendly users and creators of
> the web started to chase.

What are those?

> It's our job as technologists to accommodate how people want to use
> technology, not to tell them that the way they want to use it is wrong.

If some kids wish to use the technology to do DDos attacks it doesn't mean we
should build it into the browser, the same is true here.

> Because if we try to tell them no,

Just say No to this crap, that's all.

------
nkkollaw
For web developers it's a pain, but I can see how it might help everyone else
(which is I assume the vast majority).

At least they haven't been as idiotic as Apple and didn't remove everything
but the domain name like Apple did, and they did it incrementally.

------
gondo
From the chrome flags [1] page: "On Mac, this enables MacViews, which uses
toolkit-views for native browser dialogs." What is MacViews and how do I check
if it is enabled?

[1] chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains

------
cwkoss
Wow, if this actually gets released, might be the final straw to get me to
switch off Chrome.

------
ezoe
I switched to the Firefox some time ago when Chromium always eat precious
whole one CPU core time for stupid field trials.

Now I know Chromium is developed by bunch of idiots who don't understand the
practical consequence of omitting the part of domain name.

------
sakisv
It's 2018 ffs and internet is everywhere. People should be expected to have
better understanding of the internet and of what they see on their address
bars.

Maybe instead of masking users from the "complexity" we should be teaching
them instead.

------
jancsika
This is AWESOME! Thank you Chrome!

On a completely unrelated topic, there is a bug I'm noticing: ICANN doesn't
allow emojis in TLDs.

What? That's ridiculous-- I can put them in the _main_ part of the domain name
along with an enormous number of cute homoglyphs. So why not smileys and
homoglyphs in TLDs? If users can deal with smileys in the main domain that
tells where the site is, surely they can deal with them in the little extra
part that comes at the end. Everything's just .com underneath anyway so what
would problem be?

Google has done the work to remove the unsafe part of domains. Now our domains
can really shine. So give us more bling to put in there, ICANN! C'mon.

Also-- why not www as tld? I love "biz" and "pizza" as much as anyone, but
excuse me they got nuthin on the world wide web. C'mon ICANN give us "www" in
the Trailing Little Domain! We're ready for it now! :)

Best, Your Userbase

------
ourcat
Just noticed: When clicking the main 'home' logo on facebook in Chrome 68,
it's taking me to [https://www.facebook.com](https://www.facebook.com)

I'm sure it never used to do this. Did it?

------
infinity0
This is about as ridiculous as javascript making == not homomorphic for the
reason of "making it easy for newcomers".

Please, _predictability_ and _consistency_ is what helps newcomers, not
pandering to prejudiced intuitions.

------
SllX
So apparently when Google said they would like to "fix" URLs, what they
actually meant was that they would like to break them, whine about how broken
they are in the future, and then come up with something worse.

------
everydaypanos
Although a firm NO-WWW believer this is hilarious because it is not the same
as hiding http(s):// this is technically speaking an alternation of the url.

Still..with Google's horrible AMP efforts this seems nice :)

------
chris_wot
Has anyone tried www.www.com? what's the bet that domain will display oddly...

And what if I setup a domain with a subdomain of the www? I'm sure also
someone clever could find a way of using this for phishing.

------
euyyn
Isn't this on purpose?

------
cyberpanther
I would love to get rid of www but this going to confuse the heck out of
people. We could get rid of www if more DNS providers supported ANAME. And
Google Domains does not. How bout start there.

------
ForHackernews
[https://www.wired.com/story/google-wants-to-kill-the-
url/](https://www.wired.com/story/google-wants-to-kill-the-url/)

------
nodesocket
Curious, why did www.foo.com become the standard instead of using the
apex/root foo.com domain? Was this because of the DNS limitations of using
CNAME records at the apex/root?

~~~
detaro
Because HTTP was one service among many, not the primary one, and failed to
use a different DNS record than A to look up the target, unlike other
protocols which manage this redirection to the "$protocol server" that way
instead of through a subdomain name. (E.g. mail has MX records to find the
mail server, many other protocols use SRV records to discover their specific
targets)

------
pathartl
Instead, what they ought to do is go through the top 10,000 domains and test
to make sure that:

1\. www.* doesn't end up as a 404 or DNS resolution error

2\. www.example.com matches the content from example.com

3\. www.example.com -> example.com is a valid permanent redirect

and then finally

4\. Publicly shame them. Don't hide it from people because you run into all
sorts of UX issues.

I really hate www. for a multitude of reasons, but the biggest one is just
thinking about the amount of time spent saying it out loud. Nothing aggrivates
me more than turning on the radio and hearing "go to our website DOUBLE YEW
DOUBLE YEW DOUBLE YEW DOT <some long name like nelsonfurnishingandrepair dot
com>". That's like two seconds of air time they could recover.

------
brod
relevant quotes from a recent Wired article "Google Wants to Kill the URL"

> "People have a really hard time understanding URLs" \- Adrienne Porter Felt,
> Chrome's engineering manager.

> "But I do know that whatever we propose is going to be controversial." \-
> Parisa Tabriz, director of engineering at Chrome.

[https://www.wired.com/story/google-wants-to-kill-the-
url/](https://www.wired.com/story/google-wants-to-kill-the-url/)

------
mmilano
Firefox is my primary browser, so it doesn't affect me, however this has
already caused confusion within the web agency world I work in, both with
technical staff and clients.

------
iveqy
Many not tech-savvy users I know, never use URL's. They use the address bar
for doing a google search and then they click on the correct site in the
search results.

URL's is already dead.

------
frazras
Look at this
[http://www.this.www.is.www.not.www.really.www.google.com](http://www.this.www.is.www.not.www.really.www.google.com)
:-D

------
alasdair_
The worst case of this that I've seen is with Safari on mac. The domain gets
completely hidden if it's an HTTPS site that is "verified" (i.e. the entity
shows up in Dunn and Broadstreet)

Visit "www.apple.com" in Safari and you will get "Apple, Inc" in the URL bar
after a moment.

This seems like a potentially reasonable choice until you realize that someone
could register, say "Apple, Inc" in another state and get a HTTPS cert to
match it. One phishing email later and the Safari user is convinced they are
logging in to the correct domain.

I can see lots of new phishing attacks made possible because of this. :(

------
nyxtom
Between this and other recent changes they sure have been making some pretty
terrible decisions lately. Hopefully this change is reverted.

------
acid303
Pressing alt+d selects the address in the address bar but does not expand it,
the expanded one is copied when you press ctrl+c. Hilarious.

------
ourcat
Crikey. Looking at the various tests done by people on that thread highlights
some pretty amateur string logic by whoever implemented it.

------
snissn
as a developer i can already forsee the pain of debugging an issue with
cookies and realizing that it comes down to the subdomain

------
LeoNatan25
Chrome 69 has been a joke so far, in UX, design and bugs (on Mac). It's good,
because it will push more people to Firefox.

------
sathackr
Goodbye Chrome.

I dumped Microsoft when they tried to shove Windows 10 down my throat. I use
them only when I have to now.

It's now Firefox for me.

------
dhruvrrp
It’s wierd how everyone seems to be so against to this change. hasn’t safari
been doing this since forever?

------
sodosopa
What a stupid bug and yes it's a purposely developed bug. Will cause a lot of
problems as noted.

------
madisfun
Embrace, extend, and extinguish. The story of Google and the Web. Don't
AMPlify the issue.

------
keymone
it's true that this change is going to break some stuff for some people, but i
welcome it. www has to go. it provides no meaning (as opposed to
john.example.com) and it serves no purpose, we have schema in URLs to figure
out the protocol and port.

------
amenghra
Lol at "subdomain.www.domain.com" displays as "subdomain.domain.com".

------
znpy
the amount of assumptions that browsers make nowadays is really getting out of
hand.

Chrome on my work laptop doesn't even bother resolving a name that certainly
does not look like an url but exists in the network.

Instead it will look it up on (guess what?) Google.

~~~
jazoom
There's a particular 8-letter, simple subdomain for my domain (.com) where
Chrome treats it as a Google search. Doesn't do it for any other subdomains.
It makes no sense.

------
sjs382
Where's the list for which subdomains Google considers "trivial"?

------
microcolonel
Is this a Mac-only bug? I'm running Chrome OS and it looks just fine to me.

~~~
rkeene2
Chrome 69 has not be rolled out to ChromeOS yet, at-least on the stable
channel.

------
tschellenbach
Just updated to see it in action. Seems like a nice improvement for end users.
Don't think there is any reason not to do this, other than a nostalgic desire
for things to stay the same. Most sites already have a www. to . redirect in
place and if you don't its a trivial change.

~~~
uberman
Why not drop the .com then as well? Most sites are on .com domains after all.

~~~
CydeWeys
The obvious difference is that that's higher up in the hierarchy rather than
lower in it. www.example.com and example.com are controlled by the same
entity; example.com and example.foo may well not be.

------
SquareWheel
How immature to submit this as a bug. It was obviously an intended feature.

~~~
ng-user
However it was intended by the developers is irrelevant to the average user
using the product. To many many people this is a glaring bug.

~~~
SquareWheel
Bugtrackers are not an appropriate place to post feedback on products. They
are for listing bugs.

------
NathanCH
This is worse than the time Google ruined autocomplete and autofill:
[https://bugs.chromium.org/p/chromium/issues/detail?id=587466](https://bugs.chromium.org/p/chromium/issues/detail?id=587466)

------
nogbit
Same response as yesterday, stop using Chrome, now, there are alternatives.

------
download13
This seems fine.

I'm assuming you can always click to expand and show the full URL.

For a lot of people (devs especially) it would be nice to be able to change an
option to see the whole URL at a glance, but for most people it's just a
confusing mess they have to look through for the domain name.

------
rawoke083600
Ja this is terrible idea !

------
phillipseamore
It's been like this on mobiles for a couple of years right?

------
damm
Doesn't this make it easier to phish? Seems like it to me.

------
tigrezno
Fellow HN's, why the hell are you still using chrome?

------
tuxone
Who cares will switch the flag. Who doesn’t, just doesn’t.

------
megous
Presumably chromium doesn't do this. I can see www.

------
homero
Subdomains are very important, stop hiding where I am.

------
Svoka
Chrome is a new IE.

------
bluejay2387
Is anyone else starting to see parallels between Google's attitude toward
"progressing" Chrome and Microsoft's attitude towards IE in the 3-8 version
days?

------
Venipa
chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains

disables this new "feature"

------
DewWisp
"trivial", yeah okay sure...

------
sigzero
Just leave it alone Google. Sheesh.

------
bradezone
Man, I hate authoritarians.

------
vincentmarle
Next up: “.com” is trivial too, let’s remove that too.

------
joeyyang
Nice

------
ajfabb
epic bikeshed

------
shawn
Since everyone is wondering why, and since I happened to stumble across a
reason during my time as a pentester, here you go:

Spearphishing is still one of the most common ways of breaching a corporate
network. If I target you, you will likely fall for one of my attempts. If you
are a company rather than a person, my odds go way up, because I have N
chances to trick someone rather than 1 (where N is roughly the number of
people at the company with email access).

This is one of those things that everyone says "Ha, I'm smart. _I 'd_ notice.
You can't trick me."

And maybe you are. But you're also distracted. And that's my greatest
advantage against you. All I need is to sneak in an unexpected Github prompt
that looks completely authentic, and now I have your Github password. Wanna
bet you don't have 2FA turned on, even though you know you really ought to?
And even if you do, it's getting easier to social engineer your way past
AT&T's lovely customer support:
[https://www.youtube.com/watch?v=caVEiitI2vg](https://www.youtube.com/watch?v=caVEiitI2vg)

Ok, what's the point?

This: _Every character in the URL bar unrelated to the apex name is a deadly
distraction._

Right now, how do you know you're actually on HN instead of some knockoff?
"ycombinator.com".

How many characters do you have to read unrelated to that?
"[https://news](https://news). /item?id=17927972"

The most _vital_ part of a URL for vetting identity is also, usually, the
hardest to see.

Now, I don't know whether google made this change in order to assist with
this. But it's one possible justification, and a step in a good direction.

We may not like it, just like we didn't like when Google removed the clickable
"cached" links from search results, but in this case consumer protection
outweighs our urges as a power user.

~~~
fmpwizard
if the idea is to protect users so that you don't end up clicking on
[https://news.ycombinator.com.myhackerdomain.com](https://news.ycombinator.com.myhackerdomain.com)
, you then open the attack of a platform where they offer custom subdomains,
and you have

[https://original.blogger.com](https://original.blogger.com)

and then

[https://fake-original.blogger.com](https://fake-original.blogger.com)

if I make them look the same, and the address will hide the subdomain, it
looks like a step backwards in securing the web

now, imagine the actual platform has a payment section, and I create a fake
subdomain that looks pretty similar, email you, boom, I get your cc info
because I tricked you into entering new cc info (assuming your scenario of
someone being distracted)

~~~
Sohcahtoa82
Only supposed " _trivial_ " subdomains are hidden, such as www. and m.

Anything else is still shown. fake-original.blogger.com will still show up as
fake-original.blogger.com because fake-original. isn't a trivial subdomain.

I still think it's a stupid move, though. It's a simplification that is
incredibly unnecessary and may be harmful when dealing with the rare site that
doesn't treat www.domain.com and domain.com as the same.

------
HyperTalk2
Once you get as big as Google or Apple, you're too big to fail and there is no
longer any pressure to make good decisions because there are no actual
consequences for making moronic decisions.

------
yAnonymous
A bunch of monkeys would have caught most of these bugs during testing - and
have done a better job with the coding in the first place.

>[http://www.example.www.example.com](http://www.example.www.example.com) ->
example.example.com

What the fuck. I don't even.

------
rhacker
The fix is to change your subdomain from "www" to "amp". You can read more
about it at the IETF website located here:

[https://www.ampproject.org/](https://www.ampproject.org/)

Please submit any complaints you have as a video on YouTube.

~~~
test6554
Please tell me this is a joke...

~~~
ihuman
The "Please submit any complaints you have as a video on YouTube." part really
makes it look like a joke

~~~
progval
That line was added as an edit

------
another-cuppa
Glad I don't use Chrome. Hope this doesn't happen too Firefox or that'll be
another entry in my /etc/portage/patches

------
sureaboutthis
I would guess this makes Chrome and non-standards compliant browser.

------
peterwwillis
Google attempted a more extreme version of this four years ago:
[https://www.extremetech.com/computing/181657-google-moves-
to...](https://www.extremetech.com/computing/181657-google-moves-to-kill-off-
the-url-entirely-in-new-version-of-chrome)

So they're doing it again, just slower:
[https://www.extremetech.com/computing/276454-google-wants-
to...](https://www.extremetech.com/computing/276454-google-wants-to-kill-the-
url)

I'm pretty sure the eventual plan is to force everyone to browse the web using
a version of the App Store, which we all know is incredibly secure, and never
difficult to use.

~~~
rkeene2
I don't think your conclusion is correct, but the assertion that they want to
get rid of the URL was posted on Hacker News a couple of days ago:

[https://news.ycombinator.com/item?id=17911009](https://news.ycombinator.com/item?id=17911009)

------
therealmarv
Cool, the internet is changing is to my personal preference. Don't like www.

------
drivingmenuts
Stupid crap like that is one of the reasons why Chrome isn't my primary
browser.

