Chrome hides www and https:// in the address bar again

I would have no trouble with hiding &quot;<a href="https:&#x2F;&#x2F;&quot;" rel="nofollow">https:&#x2F;&#x2F;&quot;</a> 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.<p>I still prefer Firefox: protocol, subdomains and path are greyed out but still clearly legible. This way I can eyeball &quot;on which site am I?&quot; 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.

This reminds me of how Windows frustratingly hides file extensions by default. This sounds low-upside&#x2F;high-downside to me, but it&#x27;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).

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&#x27;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).

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.<p>Identity and payment are extremely important to any ordered system of social interaction. More than content itself,controlling them helps one control everything else.<p>I am trying hard to avoid believing conspiracy theoris about Google.<p>Maybe a legal requirement for intetnet standards compliance makes sense?

I&#x27;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&#x27;m not convinced said change is a net-negative for the average consumer.<p>Safari added the setting &quot;Show full website address&quot;, which does just that. I wouldn&#x27;t have a problem if Chrome followed suit and defaulted to the new scheme, but gave us the option to show the full URI.

This is a giant AMP scam.<p>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&#x2F;example.com.<p>But chrome will remove google.com just like http&#x2F;s.

To place this in context -- Safari <i>already</i> does this and even more, hiding the path after the domain as well.<p>Firefox does something in the middle where it makes the &quot;<a href="https:&#x2F;&#x2F;www.&quot;" rel="nofollow">https:&#x2F;&#x2F;www.&quot;</a> and path lighter gray, while the domain name is black.<p>I think this is just about ease of use and displaying the most relevant information. Regular users think of it as &quot;google.com&quot;, not as &quot;<a href="https:&#x2F;&#x2F;www.google.com&quot;" rel="nofollow">https:&#x2F;&#x2F;www.google.com&quot;</a>. And the full URL is still there whenever you click through to select or copy.

This is &quot;mobile-first&quot; 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.<p>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 &quot;desktop-first&quot; point of view—and display the full URL with the abundant space available. See Firefox&#x27;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.<p>Mobile-first is frequently damaging to new desktop software projects, but in my experience it&#x27;s atypical for mobile limitations to be back-ported to established desktop software.

It&#x27;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&#x27;s not. Combined with the fact that their explanation is dubious at best (i.e. www is not a technically a &quot;special case&quot;), I find it very hard to believe they do not have additional, confidential reasoning for making this change.

&quot;The Chrome team values the simplicity, usability, and security of UI surfaces.<p>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&#x27;re viewing.

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&#x27;ve just updated Chrome, it would now be unclear whether you typed the site name right.<p>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.

Ah yes, this fun bug: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;mholt6&#x2F;status&#x2F;1037810122603421696" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;mholt6&#x2F;status&#x2F;1037810122603421696</a>

This is extremely annoying for a project I&#x27;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.

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

This is great and all until you (like me) need to be able to differentiate www.example.com from example.com and <a href="https:&#x2F;&#x2F;" rel="nofollow">https:&#x2F;&#x2F;</a> example.com versus <a href="http:&#x2F;&#x2F;" rel="nofollow">http:&#x2F;&#x2F;</a> example.com. My website doesn&#x27;t forward example.com to www.example.com (due to errors on my part that I don&#x27;t know how to fix, my email is in my profile and if you can help I&#x27;d greatly appreciate it).<p>I don&#x27;t know if there are any scenarios in which a properly-configured website (mine isn&#x27;t) needs to differentiate example.com from www.example.com. But I liked the ability to do so easily.

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&#x27;re trying to do with AMP[0]. Some sites <i>only</i> work with WWW prefixed as the APEX DNS record is misconfigured and points to nothing. I&#x27;ve even seen some sites point to `0.0.0.0&#x27; but had a CNAME record for WWW and I could then view the site.<p>[0] <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;amp&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;amp&#x2F;</a>

A coworker and me got bit by this just today.<p>I introduced him to a new tool I built for internal development, and wanted him to access the locally running instance of our codebase.<p>Took us some time to figure out that chrome was trying to connect to <a href="https:&#x2F;&#x2F;" rel="nofollow">https:&#x2F;&#x2F;</a> instead of <a href="http:&#x2F;&#x2F;" rel="nofollow">http:&#x2F;&#x2F;</a>, which wasn&#x27;t enabled. I think it said something in the error message about that, but who reads these anyways.

This behavior will train users to believe that the www in domains isn&#x27;t important, when it actually serves a very important purpose.<p>You can&#x27;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.<p>If they&#x27;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.

Google&#x27;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.<p>I had to laugh when they started parading thier fake-human avatar &quot;to call and lie to people&quot;.<p>But really, their big value item is language engineering.

There&#x27;s a user story that can be filled:<p>&quot;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.&quot;<p>So in this sense there are points for filling it. It&#x27;s still the correct domain, so this is quite a niche user story.

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

I find this really annoying. We have an internal SPA with buggy routing where it&#x27;ll render for both http and https but the requests made by the client fail because they mirror the protocol when hitting the backend.<p>It&#x27;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.<p>While http does show a &quot;Not secure&quot; segment next to the URL, everything just shows as black and white in dark mode, making it harder to distinguish at a glance.

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

Only issue I have with this is it removes a bit of useful information when I&#x27;m asking users for screenshots when reporting errors on websites!

First &quot;bug&quot; raised this morning about naked domain not redirecting to www...<p>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&#x27;s pointless goes as far as hiding it. I don&#x27;t get the point.

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&#x2F;en&#x2F; and www.example.com&#x2F;fr&#x2F; etc If subdomains are not possible there&#x27;s no hope that visitors using Chrome would see it?

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&#x27;t raise much suspicions from them.

Google wants a world where eventually all internet is hosted and controlled by Google.<p>To get there they have to disassociate what’s shown in the URL bar with how and where the content comes from.

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.<p>This is just another tiny step in that overall plan, and it is 100% evil.<p>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.<p>If you don’t like what Google is doing, use other products. Firefox, DDG, iPhones etc.

I&#x27;m not a Chrome user, but this seems like a good thing. Address bars have been getting crowded the past few years.

It&#x27;s obvious that this is a dark pattern to increase the usage of Google search versus just typing in an address.

This is so pointless. Why? To make the URLs prettier for the average user who they assume is too stupid to function or something?<p>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.

I don&#x27;t understand why you have to click twice to show this info. That&#x27;s just bizarre.

This is absolutely stupid. The www subdomain and the bare domain are not equivalent and should not be treated as such.<p>Hiding the protocol is also stupid if it&#x27;s still shown for other protocols, like ftp or http.

Good riddance to www

Hiding the subdomains doesnt make any sense!!

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&#x27;ve lost trust in the chrome team and have switched to Firefox full time and honestly there&#x27;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&#x27;s not perfect (mr. robot incident and others).

I just opened this page on safari and I see just “bleepingcomputer.com” with a lock icon.<p>Its great chrome will do the same. Every browser should. Low level technical details and historical artifacts should go die in fire.