
Chrome hides www and https:// in the address bar again - heyyyouu
https://www.bleepingcomputer.com/news/google/google-chrome-hides-www-and-https-in-the-address-bar-again/
======
gvx
I would have no trouble with hiding "[https://"](https://") in the address
bar, as long they show it for other protocols (including http). It might help
move us to a world with https everywhere even faster.

I still prefer Firefox: protocol, subdomains and path are greyed out but still
clearly legible. This way I can eyeball "on which site am I?" quickly (and
read google-secure-payments.google.via.net as via.net for example) and still
have access to the full URL in 0 clicks.

~~~
acqq
It seems that Firefox stopped copying [http://](http://) (when I want to copy
URL) which is very annoying to me.

I need the whole address when copying.

~~~
csours
I have the opposite complaint: when I highlight a portion of the url in
chrome, it prepends the [http://](http://) anyway. If I have the whole thing
selected it would make sense to prepend the [http://](http://)

~~~
dwild
I can't reproduce what you say, it doesn't prepends [http://](http://) in my
case. Are you on Windows?

~~~
csours
Yes, on Windows. You do have to select the first part of the url, but I often
just want the host and port, ie localhost:8080 instead of
[http://localhost:8080](http://localhost:8080)

~~~
snlnspc
This is so minor but it slows me down working every day. If I didn't select
it, don't copy it. If I clicked in the center on a specific spot, drop the
cursor right there instead of selecting a section.

------
jdashg
This reminds me of how Windows frustratingly hides file extensions by default.
This sounds low-upside/high-downside to me, but it's the sort of thing with
simple arguments-for (easier for clueless users! Cleaner!), and nuanced
arguments-against (eliding rarely-useful details in special cases causes
ambiguity, and can lead to confusion is some cases, particularly for clueless
users).

~~~
mholt
Finder on macOS does this too. It's maddening...

There was an article recently about "hostile architecture" and this is
similarly a "hostile software design" to prevent users from doing something
the developers don't want them to do.

~~~
jorvi
Its hostile for power users but it prevents grandpa from renaming
'IMG_144.jpg' to 'Idaho_grandkids', hammering enter on the 'are you sure you
want this' nag screen and then wondering what broke his picture.

~~~
yrro
This was never a problem with classic Mac OS.

Files had a type code and a creator code. The type code told application
whether they could open the file. The creator code told the Finder which
application to open when the file was double-clicked.

It was impossible for the user to change either (in the stock OS).

~~~
thaumasiotes
> It was impossible for the user to change either (in the stock OS).

That's... much, much worse than dot extensions.

~~~
mrkstu
He's mis-stating it slightly. You couldn't fiddle with a file's creator code,
but there wasn't much reason to.

The type codes were editable, in the sense you could choose the default app
you wanted to open files of that type, which is really what you'd want to
modify most of the time.

~~~
yrro
I don't remember this being the case. I don't think it was possible to change
either a file's type or creator code without a tool such as ResEdit that
wasn't included in the OS.

BTW, I think you're referring to the 'creator' code, not the 'type' code. The
'creator' code determined which application would open a file when it was
opened. And it was per-file; I don't remember any mention of a system-wide
'default application' or anything like that.

This was actually rather nice in practice. It meant a JPEG image created by
e.g., GraphicsConverter would be opened by GraphicsConverter when double-
clicked; whereas one saved by a web browser would be opened in the web
browser. But either could be dragged into either application in order to open
the web-browser-saved image with GraphicsConverter.

------
Rebelgecko
Google must really hate URLs. My search results recently stopped showing the
full path of the URL, just the domain name. It was a huge pain because I was
looking for an item at Ikea and couldn't tell if a result went to their
American site or to their UK, Saudi Arabian, Qatari, etc. site (apparently the
same item can have small differences in different countries— I almost bought
the wrong lightbulbs because the UK version of my lamp uses a different size
bulb).

~~~
privateSFacct
Google sees folks falling for google-secure-payments.google.via.net type URLS.
They see all the gaming people do with URLs in search results (including
abusing the names of other brands like Amazon).

There are lots of developers who like distinguishing these subtle topics. I
can tell you in a larger enterprise deployment most of these changes will be
welcomed (yes, people do still click on bogus URLs believe it or not - FAR
more often than I would expect). Or think that the url amazon.lowprice.com is
an amazon website in a search result.

Folks claiming google is hiding the owner of the website forget that the
actual owner of the website is reflected by the END of the domain name, not
the earlier parts. In some shared hosting situations this is confusing, but in
the end whoever controls the end actually is in control.

~~~
Rychard
> Folks claiming google is hiding the owner of the website forget that the
> actual owner of the website is reflected by the END of the domain name, not
> the earlier parts.

Perhaps this distinction could be made more clear by switching to reverse
domain name notation.

~~~
klntsky
There are lots of security manuals for beginners suggesting to look at the
_ends_ of URLs. Imagine the amount of confusion it will introduce.

------
badrabbit
URLs represent and identify content,controling them means you control content.
In the short term these changes mean little but in the long term this will
benefit google immensely. Google just loves slippery slopes.

Identity and payment are extremely important to any ordered system of social
interaction. More than content itself,controlling them helps one control
everything else.

I am trying hard to avoid believing conspiracy theoris about Google.

Maybe a legal requirement for intetnet standards compliance makes sense?

~~~
privateSFacct
The focus of this change is to improve the identification of content. This
coupled with payment has been subject lots of fraud where users misled about
the owner of a website.

google-payments-secure.via.net is not a google payment website despite the
google in the domain name. The key part that signifies the ownership /
identify of the person hosting the site is the END of the domain, the
google.com part. That is the owner of the web property, not whatever appears
before that.

~~~
badrabbit
That's what google uses as an argument too and I am too familiar with the
problem.

The problem here is that _Google_ is in control of the solution and the
solution is designed by them without consulting everyone else and in a way
that would be advantageous to their long term dominance and prosperity.

I don't trust google and they certainly don't have my consent to shape the way
I and the society I live in interact with each other.

I will say it a million times if needed. I do not trust google. Period. They
ask forgiveness instead of permission and they love slipperly slops and bait-
and-switch psychology tricks to get their way.

------
pmccarren
I'm certainly not a fan of the new URI scheme, but it is worth pointing out
that Safari has already made the same change. Furthermore I'm not convinced
said change is a net-negative for the average consumer.

Safari added the setting "Show full website address", which does just that. I
wouldn't have a problem if Chrome followed suit and defaulted to the new
scheme, but gave us the option to show the full URI.

~~~
cpeterso
Safari only shows the domain name. Chrome still shows both the domain name
(minus "www.") and URL path.

~~~
pmccarren
Check your Safari setting "Show full website address". Checking it will show
the full URI.

------
RobertRoberts
This is a giant AMP scam.

The next change will be that it will trick users into thinking they are on are
on a real site like example.com but will instead be on Google.com/example.com.

But chrome will remove google.com just like http/s.

~~~
cpeterso
Chrome on Android already hides the "google.com/amp" URL prefix for AMP URLs:
[https://blog.amp.dev/2018/01/09/improving-urls-for-amp-
pages...](https://blog.amp.dev/2018/01/09/improving-urls-for-amp-pages/)

~~~
RobertRoberts
Thanks for the tip, I haven't used Chrome on my phone enough to notice this.

This is really sad and dangerous for the web. I don't know why people aren't
up in arms over this kind of devious behavior from Google.

If Microsoft had pulled this in the late 90s early 2000s there would have been
senate hearing and talks of breaking up their monopoly.

------
crazygringo
To place this in context -- Safari _already_ does this and even more, hiding
the path after the domain as well.

Firefox does something in the middle where it makes the
"[https://www."](https://www.") and path lighter gray, while the domain name
is black.

I think this is just about ease of use and displaying the most relevant
information. Regular users think of it as "google.com", not as
"[https://www.google.com"](https://www.google.com"). And the full URL is still
there whenever you click through to select or copy.

------
bhauer
This is "mobile-first" mentality in a malignant retroactive form, where it is
taking away functionality and behavior that is already established in the
desktop environment to better match user expectations set in the mobile space.

Mobile browsers often elide the protocol and trivial hostnames from domains in
order to economize on precious screen space of phones. Desktop browsers do not
face the same constraints. A desktop browser can play to the strengths of
desktop computing—taking a "desktop-first" point of view—and display the full
URL with the abundant space available. See Firefox's display of the full URL
with a highlighted color for the domain. Alternatively, they can be made
subservient to mobile and adopt conventions established from constraints that
do not exist in the desktop space.

Mobile-first is frequently damaging to new desktop software projects, but in
my experience it's atypical for mobile limitations to be back-ported to
established desktop software.

------
dlandis
It's just so bizarre how strongly the Google product people continue to insist
that this change is beneficial to users when so many users themselves
simultaneously insist that it's not. Combined with the fact that their
explanation is dubious at best (i.e. www is not a technically a "special
case"), I find it very hard to believe they do not have additional,
confidential reasoning for making this change.

~~~
annadane
Yeah forums where the company "interacts" with users is great.

"This change is beneficial." "No, it isn't." "Yes, it is." "But it isn't!" "We
respect your feedback but we're implementing it anyway."

------
lone_haxx0r
"The Chrome team values the simplicity, usability, and security of UI
surfaces.

This change is the complete opposite of simple. Simple is showing the real
URL. Complex is trying to remember in what cases Chrome hides part of the URL
and trying to guess what website you're viewing.

~~~
UncleMeat
Simple is showing the full http headers. Simple is showing iframe urls.

Of course it isn't. URLs are largely made of useless and incomprehensible
information for most users.

~~~
lone_haxx0r
If the bar was called the "http headers bar" then simple would be showing the
full http headers, but it is called address bar, so the simple thing to do is
to show the address.

------
TazeTSchnitzel
I work for well-known tech company [redacted] and visiting our website with
the www omitted does not work from within our network. But if you've just
updated Chrome, it would now be unclear whether you typed the site name right.

My previous employer [redacted] had its marketing site on www and actual SaaS
application product on www-less. Again a case where mis-typing would be made
more confusing by Chrome.

~~~
bsmith0
Those both seem like implementation issues.

~~~
TazeTSchnitzel
They're not good practice on the part of the website operators, for sure, but
they are real examples of the root and www domains being different. In my
experience there are also lots of old or government sites that just plain
don't work without the www.

And when the person phones up tech support “ma'am, does it show the www. in
front of the website?” “no” “sorry you need to retype” “it still doesn't show
www.” is going to happen.

Or someone will write down the URL from the screen, and when someone else
types it in, it won't work.

Oh, right, and there's the same issue with sites where [https://](https://)
has a different site to [http://](http://)!

------
mholt
Ah yes, this fun bug:
[https://twitter.com/mholt6/status/1037810122603421696](https://twitter.com/mholt6/status/1037810122603421696)

------
kenforthewin
This is extremely annoying for a project I'm working on that involves
subdomains. If I set nginx to redirect `example.com` to `www.example.com` I
want to verify it in the browser.

~~~
notatoad
my chrome hasn't updated yet, but my understanding of this change was that you
could display the full unmolested URL by simply clicking in the address bar.
is that not the case?

~~~
blahyawnblah
double clicking. but still.

~~~
quink
Wow, that is mad. So glad I switched to Firefox.

------
fadisaleh
Can someone help me understand why this is a big deal? Safari has had this
change for a while and I haven't felt like I'm missing anything. Where's the
slippery slope? Does have to do with AMP?

~~~
heyyyouu
It has nothing to do with AMP. There's a lot of reasons why, but one reason is
for example, two different sites can technically be hosted on www. and the
non-www version, if the site isn't set up to redirect the www to the non-www,
for example. So this could, in certain scenarios, pose a security risk in that
if you pretend that www and the non www are the same sites -- when they're not
-- it can make it easier for those that hijack one or the other to get away
with it. Now, that's fairly extreme and esoteric. But there are actually times
in development when you use subdomains, which this makes more difficult, and
there's other subdomains they're considering trivial which, in fact, aren't.
This is really good discussion on the topic and why this change just simply
ignores so many technical issues, best practices and simply realities:
[https://bugs.chromium.org/p/chromium/issues/detail?id=881410](https://bugs.chromium.org/p/chromium/issues/detail?id=881410)

------
RandomGuyDTB
This is great and all until you (like me) need to be able to differentiate
www.example.com from example.com and [https://](https://) example.com versus
[http://](http://) example.com. My website doesn't forward example.com to
www.example.com (due to errors on my part that I don't know how to fix, my
email is in my profile and if you can help I'd greatly appreciate it).

I don't know if there are any scenarios in which a properly-configured website
(mine isn't) needs to differentiate example.com from www.example.com. But I
liked the ability to do so easily.

~~~
notatoad
>need to be able to differentiate ... [https://](https://) example.com versus
[http://](http://) example.com

this requirement is handled by the "not secure" badging, which is much more
obvious that requiring users to pick out the "s" in the middle of a string.

[https://security.googleblog.com/2016/09/moving-towards-
more-...](https://security.googleblog.com/2016/09/moving-towards-more-secure-
web.html)

------
_o-O-o_
What a slippery slope. I imagine a future when the entire URL itself has
disappeared and we live in some sort of Google-controlled walled garden
environment, like what they're trying to do with AMP[0]. Some sites _only_
work with WWW prefixed as the APEX DNS record is misconfigured and points to
nothing. I've even seen some sites point to `0.0.0.0' but had a CNAME record
for WWW and I could then view the site.

[0] [https://developers.google.com/amp/](https://developers.google.com/amp/)

~~~
y_molodtsov
Then these websites are broken and needs to be fixed. In the end, the most of
the people would probably search for it in the first place.

~~~
horsawlarway
broken according to who, exactly?

It's entirely reasonable to choose to host http/https traffic on a www
subdomain and host entirely different services at the non-www domain.

The internet is not just http traffic. Full fucking stop.

There are plenty of systems and industries where the actual web front-end is
an after-thought.

------
chmod775
A coworker and me got bit by this just today.

I introduced him to a new tool I built for internal development, and wanted
him to access the locally running instance of our codebase.

Took us some time to figure out that chrome was trying to connect to
[https://](https://) instead of [http://](http://), which wasn't enabled. I
think it said something in the error message about that, but who reads these
anyways.

------
toast0
This behavior will train users to believe that the www in domains isn't
important, when it actually serves a very important purpose.

You can't cname example.org, which makes it very hard to use a CDN to serve it
unless the CDN provides anycast ips or you delegate DNS to the CDN.

If they're intent on making the address bar useless, they may as well go full
hog, like Apple does in desktop Safari -- the address bar shows the domain
only, until you click.

~~~
y_molodtsov
But it’s definitely not important for an average user typing “facebook.com”
into the address bar. Safari proved that.

~~~
toast0
If the url isn't important enough to display, then they shouldn't display it.
They can display just the domain. They shouldn't display almost the url, but
they removed an important thing.

Edit to add: if you type in an almost url from the screen or a screenshot,
it's likely to not take you to the same page, and you'll be confused as to
why. If you type in the domain only and go to the home page, that's not that
confusing.

------
jakeogh
Google's business model ultimately revoves around deception. They need their
assets to not know or care where they really are or who they really are
talking to or who is reviewing thier words and movements.

I had to laugh when they started parading thier fake-human avatar "to call and
lie to people".

But really, their big value item is language engineering.

------
thrwwy4357
There's a user story that can be filled:

"As a ____, I want to get users to our []-controlled version of our site,
without alerting the user aware they are on our []-controlled version of our
site."

So in this sense there are points for filling it. It's still the correct
domain, so this is quite a niche user story.

------
zzo38computer
I absolutely do not want it to hide any URI schemes or subdomains at all. (I
am able to change these settings in Firefox, at least. I could also disable
Unicode rendering for the domain name, but to disable Unicode rendering for
the filename I had to write an extension.)

~~~
cpeterso
By default, Firefox's address bar hides the [http://](http://) scheme but
shows the [https://](https://) scheme (to emphasize that the connection is
secure). Firefox users that want to see the [http://](http://) scheme can set
the "browser.urlbar.trimURLs" about:config pref to false.

------
spondyl
I find this really annoying. We have an internal SPA with buggy routing where
it'll render for both http and https but the requests made by the client fail
because they mirror the protocol when hitting the backend.

It's a pretty trivial issue that has sat around for a while. While I run
Firefox, I would normally distinguish what version of the site a user is on by
the green lock.

While http does show a "Not secure" segment next to the URL, everything just
shows as black and white in dark mode, making it harder to distinguish at a
glance.

------
toast0
I guess the responsible thing to do is to redirect www to vvvvvv

~~~
hedora
https.llwww, you mean?

------
joe_hoyle
Only issue I have with this is it removes a bit of useful information when I'm
asking users for screenshots when reporting errors on websites!

~~~
Veedrac
http/https is already given by the lock/“Not secure” icon FWIW.

------
StefanoC
First "bug" raised this morning about naked domain not redirecting to www...

SEO departments in my experience still insists that the www subdomain is
necessary (e.g. they have no idea so better not touch it), yet Google instead
of publicly coming out saying that it's pointless goes as far as hiding it. I
don't get the point.

------
type0
If I have one webpage with different languages and want my visitors recognize
it from url, what are the options? Previously I could have www.example.com/en/
and www.example.com/fr/ etc If subdomains are not possible there's no hope
that visitors using Chrome would see it?

~~~
knd775
Subdomains in general still show, just not www. Also, in the case you
mentioned, the subdomains are the same. The path still shows.

~~~
type0
Thanks for correction, I confused that with technically handicapped Safari
Browser then.

------
Yizahi
We all know why they really did it - to hide AMP page prefix in the future, to
silo all internet (=Googlenet) users on their servers and won't raise much
suspicions from them.

------
noncoml
Google wants a world where eventually all internet is hosted and controlled by
Google.

To get there they have to disassociate what’s shown in the URL bar with how
and where the content comes from.

------
josteink
Google wants nobody to know URLs exist, and that everyone is forced to search
Google for everything, even sites they know, and there visit fake AMP-sites
portraying to be from a server they are not, all while Google tracks every
single keystroke you make.

This is just another tiny step in that overall plan, and it is 100% evil.

Don’t waste your time trying to talk the Chrome-team into reason. You are not
their customer, nor their employer. They will not listen.

If you don’t like what Google is doing, use other products. Firefox, DDG,
iPhones etc.

~~~
joshuamorton
Firefox and Safari already made similar changes. Safari made the exact same
change, and Firefox hides [http://](http://) already, but not
[https://](https://), chrome is just using a lock icon to represent the
[https://](https://) instead of the actual string.

~~~
zzo38computer
As mentioned, at least this setting can be disabled in Firefox. (I don't know
if this is possible in Chrome.)

~~~
wildrhythms
Since nobody replied, I mentioned this in another comment that you can revert
this in chrome://flags

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

------
AlchemistCamp
I'm not a Chrome user, but this seems like a good thing. Address bars have
been getting crowded the past few years.

------
JTbane
It's obvious that this is a dark pattern to increase the usage of Google
search versus just typing in an address.

------
RandomInteger4
This is so pointless. Why? To make the URLs prettier for the average user who
they assume is too stupid to function or something?

Meanwhile most URLs around the web have UUIDs or other garbage appended to the
end for the sake of tracking, which I doubt they intend to do anything about
any time soon, so what even is the point of hiding the protocol and a single
subdomain? Just leave the URL alone.

------
eridius
I don't understand why you have to click twice to show this info. That's just
bizarre.

~~~
Veedrac
Simple UX: don't move things around more than necessary. I honestly don't
understand why people think this second click is unreasonable; the power-user
shortcut (ctrl-l) already expands immediately anyway.

~~~
eridius
It's unreasonable because it violates user expectations. One click already
makes the field editable and selects the text, having a second click change
the text has no precedent whatsoever. It's also confusing because this means
that clicking to position the insertion point suddenly moves the text out from
under where you clicked (thankfully it does still place the insertion point at
the right location, but that location is no longer where you're looking and
pointing).

There's also just _no reason_ for this. It's unnecessary overhead to showing
the full URL and there's no benefit.

~~~
Veedrac
The point is that the most common thing people do when clicking the URL is
typing something else in the search bar, and the second most is copying the
URL. In both cases, having the URL change is a problem, because this includes
people who _don 't_ know what the [http://](http://) means or what a subdomain
is, and _don 't_ immediately understand when a URL is the same as another.
Your extra click saves my mother, and millions like her, much more confusion
than the click costs you.

You probably mostly know technically fluent people, and think ‘my mother’ is a
euphemism, but it's not. If we can get to a world where she can see an
unfakeable padlock and read ‘facebook.com’, rather than remember whether it
was ‘https:’ or ‘https.’ in the URL bar, and which parts of the string of
letters to skip, we've made her life less hostile.

The corresponding problem you're complaining about is incredibly trivial in
comparison. If you're actually editing the URL, you see the whole URL. If you
need to know these implementation details, they're _vastly easier_ to find
than, say, HTTP headers.

~~~
eridius
If you type something in the bar it doesn't matter what it shows.

If you copy the URL, the fact that what you copy is literally different than
what you're looking at is confusing. You copied "example.com", so why does the
clipboard now contain "[http://www.example.com/"](http://www.example.com/")?

> _If we can get to a world where she can see an unfakeable padlock and read
> ‘facebook.com’, rather than remember whether it was ‘https:’ or ‘https.’ in
> the URL bar, and which parts of the string of letters to skip, we 've made
> her life less hostile._

Whether the URL bar shows "https" or a padlock has nothing at all to do with
the unnecessary confusion inherent in Chrome requiring a second click on the
URL bar to reveal the full URL.

Nothing in your comment even begins to explain the benefit in presenting a
fully-editable text field that allegedly shows the URL, except it's still
hiding information that is only revealed once you try and perform another text
editing action. If someone looks at the URL bar and sees "example.com", and
they click on it and it immediately turns into
"[https://www.example.com"](https://www.example.com"), that doesn't harm them
in any way. In fact, that's exactly how mobile browsers such as iOS Safari
have worked for years and nobody's complained. Chrome is deliberately doing
something different than all precedent and there's no obvious reason for this
beyond their desire to be unique.

~~~
Veedrac
I gave a straightforward argument: it keeps these complexities away from
people who don't understand them as much as reasonably possible, while still
leaving them within trivial reach when they are necessary. If you don't like
the argument, whatever, but acting like Chrome is making this a double click
instead of a single click because of some kind of differentiation strategy or
ego or whatever is just silly.

------
emilfihlman
This is absolutely stupid. The www subdomain and the bare domain are not
equivalent and should not be treated as such.

Hiding the protocol is also stupid if it's still shown for other protocols,
like ftp or http.

------
adultSwim
Good riddance to www

------
fkhatri
Hiding the subdomains doesnt make any sense!!

------
mr_puzzled
Off topic : there seems to be a disconnect between the chrome devs and users.
Another instance was the automatic signing in to chrome incident. I've lost
trust in the chrome team and have switched to Firefox full time and honestly
there's nothing that I miss. The firefox devs seem to better understand their
users, frequently blog about changes that positively impact users. I have a
lot more faith in firefox even though it's not perfect (mr. robot incident and
others).

~~~
EpicEng
Have they though? How many of their users understand what "www" or "https"
mean? For those that have a vague idea, how many ever look?

I don't like the change either, for a variety of reasons, but I don't think
I'm their average user either. For the average user, seeing the domain and
nothing else likely improves security.

~~~
RobertRoberts
This isn't about users, it's about a scam to trick people into thinking that
something is being served from their site, but it's not, it will be from
Google. (ie, AMP)

~~~
EpicEng
Like I said, I'm against it for several reasons, but I replied to this:

>there seems to be a disconnect between the chrome devs and users

------
keymone
I just opened this page on safari and I see just “bleepingcomputer.com” with a
lock icon.

Its great chrome will do the same. Every browser should. Low level technical
details and historical artifacts should go die in fire.

