New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 70 users

Issue metadata

Status: Assigned
Last visit 23 days ago
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 883038: Feedback: Eliding www/m subdomains

Reported by, Sep 11 Project Member

Issue description

In Chrome M69, we rolled out a change to hide special-case subdomains “www” and “m” in the Chrome omnibox. After receiving community feedback about these changes, we have decided to roll back these changes in M69 on Chrome for Desktop and Android. 

In M70, we plan to re-ship an adjusted version: we will elide “www” but not “m.” We are not going to elide “m” in M70 because we found large sites that have a user-controlled “m” subdomain. There is more community consensus that sites should not allow the “www” subdomain to be user controlled.

We plan to initiate a public standardization discussion with the appropriate standards bodies to explicitly reserve “www” or m” as special case subdomains under-the-hood. We do not plan to standardize how browsers should treat these special cases in their UI. We plan to revisit the 'm' subdomain at a later date, after having an opportunity to discuss further with the community. Please leave feedback, or let us know about sites that have user-controlled subdomains at “www” or “m” in this bug.
Showing comments 7 - 106 of 106 Older

Comment 7 by, Sep 12

What is the reasoning behind the decision not to wait for the standardization discussions? As the majority market share holder, it's incumbent on Chrome and Chromium to be cautious when making arbitrary decisions about how connection information should be displayed- or in this case, deliberately transformed and obscured. The urgency with which this change is being pushed is baffling.

I strongly disagree with the idea that we should be connecting to one host name while displaying another in the address bar. Absent legitimate discussions with the appropriate standards bodies, this decision feels myopic at best, and wrong-headed at worst.

Comment 8 by, Sep 13

Standardization discussions aside, no changes to the look and function of sub-domains should happen, unless this is an opt-in setting. SaaS, ESP and ISP providers take great care to manage their domains and use 301 redirects to bring users to the right location.  A browser should not determine this function unless it is completely a user choice.

Perhaps Google/Chromium would like to respond as to the exact end game and reason for such a change.  Dictating a change which is controlled through DNS, but shows up differently on a browser is just plain confusing and wrong.  I don't agree with what Safari and Windows have done either.

Comment 9 by, Sep 13

We were told by the chromium project team to copy this feedback here, so my apologies for the extra email and duplicate comment from another ticket.

Per the chromium documentation:

"Furthermore, Chrome can only guarantee that it is correctly representing URLs and their origins at the end of all navigation. Quirks of URL parsing, HTTP redirection, and so on are not security concerns unless Chrome is misrepresenting a URL or origin after navigation has completed."

Why is this feature designed to "misrepresent a URL or origin after navigation has completed" then? Lying about the hostname to novices and power users alike in the name of simplifying the UI seems imprudent from a security perspective.

The identity of a page is not just contained its topmost levels of the domain name. This concept of eliding any part of an origin, not just its current implementation, is a serious issue that violates the trust a user expects to place in their user agent and the pages it navigates to.

The chrome area is sacred, intended to be implicitly trusted and not easily tampered with, and the browser should not erode the confidence users have been taught to place in it.

Comment 10 by, Sep 13

If you are going to push through with this "feature", regardless of how much the "community" resists, please make sure that a Policy exists to easily disable this "feature" enterprise-wide instead of just a feature Flag.

Comment 11 by, Sep 13

I remain firmly convinced that some "solutions" are worse than the "problems" they address, and that hiding bits of the URL is one of them.

As others have stated previously both here and in other discussions about this, it will not help users learn about URLs if browsers like Chrom(e|ium) simplify them to remove "complexity" at the expense of clarity.

Feel free to dim the unimportant parts of the domain name, or make whatever visual tweaks you think will be helpful to *emphasize* the main component(s) that all users should be aware of, but do not *hide* anything. Encourage users to learn, rather than taking away any incentive they might have to do so.

Comment 12 by, Sep 13

> We do not plan to standardize how browsers should treat these special cases in their UI.

I actually think we should do this, to some extent. URL Standard already defines how URLs should be rendered:

(Pretty vaguely.) It's already out-of-sync with reality, as it doesn't permit dropping the scheme when rendering a URL. I intend to push this closer to reality (with that, and the percent decoding logic). I think it would also be appropriate to outline optional rules about what browsers can and can't hide. It would be helpful if it were backed by standardization at the DNS level that special-cases "www" and "m".

Comment 13 by, Sep 13

> We plan to initiate a public standardization discussion with the appropriate standards bodies to explicitly reserve “www” or m” as special case subdomains under-the-hood.

Please explain why would you first ship a feature in a stable version of the browser to the general public, that conflicts with current standards, without first initiating a discussion about it. What is so time-sensitive about this whole issue? It is more of a regression by definition than any security measure. 

Creates more problems than it solves, since all subdomains are user-controlled.

Comment 14 by, Sep 13

>Please leave feedback, or let us know about sites that have user-controlled subdomains at “www” or “m” in this bug.

I know at least one ISP (, that, while not allowing "www" as a user-controlled domain, does allow "www.(whatever)" but also "(whatever)", so you can have both :
(- too)
But these subdomains are not guaranteed to be controlled by the same person, because they're completely independent. Granted, these are free hosting offers not to intended to be used by professionals but still.

Also, I'm not in favor of eliding any part of the URL, it's difficult enough to trust it as it is without hiding parts of it. As #11 said, it's entirely possible to just highlight the important parts without hiding/deleting any. Firefox does it for instance.

Comment 15 by, Sep 13

Stop striping anything. URLs without www are not "easier" or "complexer" as URLs with www. It's just a unnecessary bug - not a feature.

Comment 16 by, Sep 13

The future display `` or `` 
Let the domain owner decide.
If They want just set their `` redirect to ``.

if we do, People will think `` is ``,
however domain ower did't set `` as a service ,then people will got DNS ERROR or service ERrror

Comment 17 by, Sep 13

I would suggest the following:
* Hide https:// (again) and http://, replacing them with no and red indicator, accordingly (continue your current plan at
* Gray out *all* subdomains like Firefox, to highlight the main domain
* Be an example of your own intent - remove www. and m. (if any) from all Google domains by configuring your server accordingly
* *Suggest*, but never assume or enforce developers to do the same by proposing server-side fixes (e.g "We noticed that you are using an m subdomain. For best user experience, consider making the website use responsive design instead." and "We noticed that you are redirecting users to www subdomain. To make addresses more clear to users, we recommend you to redirect them to subdomain-less version in the server. Here's how.")
* Never hide www. and m. in Chromium if it exists in the URL

Comment 18 by, Sep 13

I suggest that you do not elide anything on https connection, if the result would produce a name that is not part of the list of Subject Alternative Names of certificate.

That is, you access, and that yields a cert with a SAN list of only and nothing else. Eliding www to produce when the SAN list of the Cert does not contain is likely wrong and confusing in any case.

Comment 19 by, Sep 13

Please leave URLs as they are. Not always is equivalent to, so leave the freedom to the user to see what they typed in the address bar.
At the same time I agree with color-coding http, https and broken https, but please leave the address as is.

Comment 20 by, Sep 13

At least make it a toggleable option, I dont mind if URLs are elided by default. But please have an option to disable this.

Comment 21 by, Sep 13

If the goal is to de-emphasize "trivial" subdomains why not just make them a lighter gray instead of hiding them altogether?

Also, in what sense are they "trivial"?

Comment 22 by, Sep 13

I, for one, agree with the proposed plan. In 99% of cases "www" is just boilerplate. Hiding it in the address bar makes URLs look significantly cleaner. The situations where it might cause confusion are rare, and are generally the result of what I'd consider to be poor practice on the part of the domain owners. (Though yes, it would be even better if there were a standard that formalized this.)

"m" is similar in mobile, but not to quite the same extent. Usually "m" is just noise, but occasionally I do find it helpful to see in the address bar that I'm on the mobile version of a site; as that lets me switch to desktop mode more easily if I find the mobile UI to be unsatisfactory.

Comment 23 by, Sep 13

It breaks "double-click to select word-like fragment of text" UI functionality which is standard in Windows, MacOS and most Linux desktops. For example, I'm trying to copy issue number on this page and double-click on "883038" in address input to select just number. After first click, URL enlarges and mouse cursor is now over "detail" and not "883038".

In previous versions this was always causing "detail" to be selected instead of "883038". In 69.0.3497.81 which I'm using now, it *usually* correctly selects "883038", but it shifts to the right and that's still frustrating. And *sometimes* it selects wrong part, "detail" or "detail?id=883038" or even "bugs" from the starts of URL (I suspect that it even change vertical position when jumps). It depends on speed of double-clicking, try double-clicking slower.

It's very frustrating, I want familiar desktop experience in desktop browser. This new address bar is like something from mobile OSes where everything jumps and moves all the time :(

Comment 24 by, Sep 13

I'll say again what I've already said on the Google Groups post. No. Hard no from me. Stop this. 

By allowing the omission of subdomains, you allow for malicious actors that have control over a domain to be able to craft any URL that, when the subdomains are omitted, will appear to be legitimate. 

The only legitimate reason that there would be interest in the omission of the subdomains in URLs is if the browser itself wants to hide critical information from the user (like say... that they are using the AMP version of their website instead of the actual website).

Comment 25 Deleted

Comment 26 by, Sep 13

Google, you don't own the internet.

Stop cutting subdomains, protocols and other parts of an URL NOW

look at the RFCs and DON'T BE EVIL

your words, a long time ago...

Comment 27 by, Sep 13

If a company would like to have their URL cleaner, they would redirect the www subdomain to the domain name. 

A browser eliding the subdomain is crazy and complete nonsense.

You can't do that. Stop this and DON'T BE EVIL

Comment 28 by, Sep 14

Regarding the eliding of schema:


Watch the http:// evaporate.

Click on the 'not secure', which now gives *zero* information as to the cause of the problem - http vs https, or an expired certificate, or SSL crypto strength/algorithm mismatch, or.....

I understand there's good reason to dumb it down for Joe Sixpack, but some of us have been around since before http was invented and are able to do some debugging and problem repair *if we are able to get actionable information*.

(Personally, I showed up way back when support for subnets and DNS were still iffy, and the RFC for HTTP/1.0 was a decade in the future.)

Comment 29 by, Sep 15

A URL might be hard to understand semantically for someone new to it, but the concept that what you see in the URL fiel is exactly what you need to enter to get back to the same place is a very simple concept.

By hiding parts of some (but not all) URLs, this simple concept is no longer true. The URL field is no longer reliably telling you where you are and how you can get back to it. If you copy it to somewhere else, e.g. a mail, what you get there is different to what you see in the browser. I'd argue hiding things along arbitrary rules therefore actually adds complexity to the user experience, instead of reducing it. In the end the user is even more confused. Please don't do this!

Comment 30 by, Sep 15

I find this change atrocious!

As a web developer I work with URLs all the time and it drives me crazy that the cursor does not end up where I click on the address bar, because some part of the URL was invisible.

I support the person that suggested using visual cues instead, highlighting, dimming, graying out, whatever, everything EXCEPT hiding!

Comment 31 by, Sep 15

Hiding the www is a bad idea: - verbal copy-and-pasting

If you need to tell someone what page you are looking at - reading the url out aloud to someone else (rather than copy-and-pasting, where you have a cludge to fix it up), there's no technical opportunity to step in and say "oh, you need to know the true URL right now, you'll need the www subdomain too"

And then if the www and non-www are not aliased and providing the same content, everyone is inconvenienced, and they lose trust in the browser.

Comment 32 by, Sep 15

Hiding the www is a bad idea: - empowering malicious activity

As mentioned in #14, there is no general requirement for different subdomains to be under the same ownership and control, so this opens up the opportunity for malicious actors on some domain environments to trick users into believing they are at one url when they are actually on another. Granted, this is a narrow case, but the browser should not be complicit in supporting this activity. I am surprised this change passed any security review.

Comment 33 by, Sep 15

I agree with those who suggest just greying the www instead.

Eliding www means the browser's chrome can no longer be trusted to be giving a true representation of the address you're on. Hiding such basic information from the user can only lead to issues

The idea that 'www' is trivial is a nonsense in the first place. For example, if a domain is being CNAME'd out to a CDN, it's fairly common that the www subdomain will have a CNAME, whilst the 2nd level domain (e.g. won't be - due to the fact that any label with a CNAME may have only a CNAME (so you can't then add MX records for the domain, for example). The alternative involves having to create all those records with your CDN provider (and there may be good reasons why you don't want to).

It also has some problematic results for anyone who has to help remote users troubleshoot - particularly those who insist on sending screenshots through. Even if you're lucky enough to get the address bar, it now cannot be trusted.

Whilst you might consider www to be 'just boilerplate', the simple fact is it is a distinct subdomain, and must be treated as such.

Also worth noting that neither Chromium nor Google seem to consider 'www' unimportant when delivering content

$ curl -vo/dev/null 2>&1 | grep Location
< Location:
$ curl -vo/dev/null 2>&1 | grep Location
< Location:

Subdomains, including www *are* user-controlled. The correct source of authority for these is that domains Authoritative name servers and the user-agent should honour that.

In my opinion, this change should be backed out now. Have a standardisation discussion by all means, but don't simply introduce what might very well be a breaking change into the most-used browser on the net.

Comment 34 by, Sep 15

We don't want to say any dirty words here, but it is you that left us no choice.

You must conduct this experiment like the SPDY that you make this change only within your own services(domain) that chrome can Only hide the "www" in Google's own sites and it never applies to any other site.

To elide it in all sites, you Must make this Experiment into a standard first.

Comment 35 by, Sep 15

So, Google is trying to kidnap the standard of URL and Chrome is the most powerful weapon they have.

Everyone knows that hiding www just bring more security problem to user.

Comment 36 by, Sep 15

Don't do it. It makes life hell for developers when the user reports stuff that doesn't match reality.

Comment 37 by, Sep 16

Hiding www is a very bad idea.

Please stop doing this.

Comment 38 by, Sep 16

repeat see

If you insist on doing this, then I have no words.
Give me an Option just black Host and hide scheme & queryString .Thanks

Comment 39 by, Sep 16

Don‘t do it. It's not a good change

Comment 40 Deleted

Comment 41 by, Sep 17

Do not hide www!! If it ain't broke don't fix it.

Comment 43 by, Sep 17

Please do NOT mess with URLs. Many developers use variations of the subdomain for development sites or differentiation of features and a/b testing. Not everyone's DNS settings for and are the same server! In fact, instead of clearing up the URL bar, make it more informative. The first mistake Chrome made was to omit the ability to easily read the certificate. If I get a cert mismatch or other cert error, and even sometimes when cert comes up legit - I want to check it and read it. To do so now in Chrome is a HUGE PITA. Bring that back too please and again, don't mess with the URL. If you want safety, prevent the ability to use DOM or other methods to change what is displayed in the URL bar, prevent iframed sites where the container is invisible and on one domain (the one showing in the URL bar) and the content is coming from another. Do things like that instead!

Comment 44 by, Sep 17

1. As has been mentioned a few times, it is very possible for a domain to be configured so that it leads to different places with and without the www. Speaking from firsthand experience, for several years I could access my company's website from outside our offices with or without the www, but internal to our offices, omitting the www would bring me to our intranet, thanks to our network's DNS settings. This and behaviors like it aren't common, but they do exist, and this change would make it more confusing for people in such situations where they end up on different sites depending if it's there.

2. Many registrars won't automatically ensure that both versions go to the same place. While it's not difficult to configure manually, new site owners might overlook this, especially if it's their first time purchasing a domain separately from their hosting. Hiding the www in all cases makes it substantially more difficult to diagnose DNS misconfigurations like this.

3. Hiding parts of the URL diminishes the user's ability to trust that the information the browser is giving them is complete and accurate. Nobody wants to think their computer is lying to them, but that is exactly how many users will see this.

While it is absolutely true that www and non-www should and in most cases do bring users to the same destination, it is not safe to assume that this will actually be implemented correctly on all sites, and it likely never will be unless there is a fundamental change to DNS. And unless that assumption can be guaranteed to be accurate in 100% of cases (which it can't), hiding this information from the user is a change for the worse.

Comment 45 Deleted

Comment 46 by, Sep 17

Comment #23 sumed the issue I have with the URL being partially hidden but aside from that, I do have all corresponding flags in Chrome Beta 70 to hide HTTP/S, WWW, 
and M.

Comment 47 by, Sep 17

In reference to comment 44 where the domain without www pulled up a different site internally on the LAN than the internet this is most likely a "split domain" used with Microsoft Active Directory. Companies with this configuration cannot easily point to for internal users even if they want to. Hiding the www portion of the domain will lead to a lot of confusion on corporate networks. I work with a large companies including governments and large institutions and a few do not point the base domain name and www subdomain to the same website. Normally without the www you get no site at all. They are also the ones where getting in touch with the DNS admin to make changes is like pulling teeth. I still have not heard anything close to a legitimate reason for this change, all I can think of are downsides. Is there any documentation such as a proposed standard available as to why this change is beneficial? Maybe something that could be distributed to DNS contacts that would make them heed the change.

Comment 48 by, Sep 17

I want to see www because I grew up typing www every time since Windows 95. I am a power user thats why I use Vivaldi now, it even shows http:// I know you dont even show that, but I want to see full url.

Comment 49 by, Sep 18

This is a VERY bad idea for a lot of reasons, Emily, and you and Google should absolutely NOT go ahead with this. You are actively breaking the internet.

Show full URL's by default!

Comment 50 by, Sep 18

I've been trying to get used to this in Canary, but so far I haven't been able to. I still find it jarring, and my eye keeps thinking there's something wrong. I think "www" is so ingrained in people's brains now that they expect it to be there.

That said, I _can_ see the rationale behind hiding the less relevant parts of a URL in favour of the most important part (ie the domain), as this could help combat phishing attacks that use things like But _just_ stripping the "www" prefix doesn't actually help with that. So you could make an argument for going all-in and stripping everything but the eTLD. That, of course, brings about issues with Tumblr etc.

One other comment on the feature: Please make it show the full URL when the omnibox has focus, rather than requiring two clicks.

Comment 51 by, Sep 18

I agree that the 'www' subdomain is essentially pointless at this point in the internet's life. I've very few people who come to my sites actually use the prefix. 'm' needs to stay as users often need to get out of mobile sites by deleting the subdomain even after toggling the desktop view setting.

Comment 52 by, Sep 18

This is a support nightmare for businesses with technophobe customers. Explaining to them exactly what to type over the phone will just confuse them more when they don't see what they typed in the address bar. Also, many websites do not have an auto-redirect set up for the non-www URI and thus when people write (yes, with a pen or pencil *gasp*) down the URL it will be wrong in those cases. Not everyone in the world is as facile with using computers as you are Google...please explain why the big push to do this when there are much higher priority things to deal with in the browser code?

Comment 53 by, Sep 18

Nothing should be elided, please stop this madness.
If websites want a shorter url they should redirect from to

Comment 54 by, Sep 18

Status: Assigned (was: Untriaged)
emilyschechter: assigning to you to gather the feedback collected over the past week.

Comment 55 by, Sep 18

Sometimes habits stick around for long after what to an outsider whom is new to a situation would see as necessary. For example, in the UK, mandatory car tests are still called "MOT" Tests despite the fact the "MOT" initials stand for Ministry Of Transport, a long-defunct government department. But for everyone else, the name is entrenched in everyday language and it does not make sense to fix something that is not broken. Especially since the tests still serve a purpose. The name also reflects the tests' heritage.

With regards to "www" in URLs, it seems a similar situation. The purpose being: have a separate subdomain refer to different servers for different content. This is still true to this day. Having the "www" as a separate addition to a bare domain is still very useful because it means one can use a CNAME to an external CDN source, preventing one having to delegate their entire DNS to their CDN provider (since it is impossible to create a CNAME for a bare domain). It is therefore, in my opinion, important that the full URL is displayed, as it is entirely possible that a website owner could forget to update an A record on their bare domain and end up with it not redirecting to the www equivalent. Hiding the www addition in this case causes confusion because it means people writing down URLs would not notice the need to have www in front, would type in the address on another machine, and get either a timeout error or even be directed to a totally different site that now uses the stale IP. Telephoning support staff, whom could well be using a browser that hides the www as well, might well end up confused too!
I think the best compromise is to highlight, or bold, the bare domain, but leave the other elements grey. Eliminating any part of the URL from view is not a good idea in my opinion. WWW still has a meaning to this day and it's use as a subdomain is still useful, and it's heritage should be protected.
One last example of www vs bare domain: tells the user they are on the wrong address, and that the correct address is . This is entirely a website owner's choice what URL they want their website to be presented as to the end user, and this should remain so.

Comment 56 by, Sep 18

I too think nothing should be elided.

1. Protocol

Yes, everything should be HTTPS, but isn't yet and it will never truly reach 100%. Thus it would useful to be able to check without having to rely on some lock icon or absence of such. Imho the more important point is though, there are just different protocols than HTTP(S)! For example ftp://, file:/// or even the obsolete gopher://[1]. More importantly there might be new ones coming, such as dat://[2]. And even if only HTTP(S) would be elided and not e.g. dat://, it would be inconsistent. Therefore the protocol should never be hidden.

2. Arbitrary parts like www/m

Another inconsistenty. Why random parts of an URL? Either do it like Safari, afaik only showing the top part like until you click once(!) in the address bar, while normal behavior is restorable[3], or elide nothing. I prefer eliding nothing.

Adrienne Porter Felt of Google claimed[4][5] that the URL is, in short, bad. Please provide public verifiable science years ahead of such a change to such a fundamental part of the Internet.


Comment 57 by, Sep 19

Does that make the phishing attack do easier? I don't understand why you remove www/m domain out. I don't feel annoy about it.

Comment 58 by, Sep 19

Nothing should be removed/hidden/omitted from a URL as shown to the user, the URL should be presented as typed/entered by the user. 

Claiming this is being done for security is plain wrong, it doesn't help prevent phishing attacks, in my experience it will create more confusion and make it more likely for a user to connect to the wrong site.

More importantly this is also non-standard, it goes against a number of RFCs for URI handling. You are making a non-standard change.

Comment 59 by, Sep 19

The user should have complete transparency on what the actual URL used is.  I recommend this for all users.  The minimal acceptable is to have a browser setting allowing users to see the real URL.

Comment 60 by, Sep 19

Thanks for the feedback so far. We plan to collect additional feedback, particularly about the enterprise use case, before launching the feature. We will not be launching the "www" elision in M70.

Comment 61 by, Sep 19

@ #60 Thanks for the update Emily.

I trust by "before launching the feature" you meant "before deciding whether to launch the feature" :-)

Comment 62 by, Sep 19

I only find acceptable to Eliding the URL's on mobile devices. 
And even on mobile devices I would prefer that only https:// || http:// would be elided. 

Google is sadly trying to push his own agenda over the greater good.

Comment 63 by, Sep 20

Is this just currently disabled by making the default for chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains be "Disabled"? As in, when it's enabled again, the default for the flag will be "enabled" and you'll still be able to set it to "disabled" if you don't like it?

Comment 64 by, Sep 20

@63 Flags are always temporary, whether they become settings is another question though.

Comment 65 by, Sep 20

As many others have said, much better than I could, hiding any part of the URL is a bad idea. Among many other reasons, this is why I now recommend not using Google Chrome and personal switched (back) to Firefox several months ago.

This is basically forcing all sites to conform to what Google thinks is best despite what sites owners may want and is done by abusing the power they now have as a market leader.

Comment 66 Deleted

Comment 67 by, Sep 20

My preference is to take the Firefox approach and grey out parts of the url considered less important / trivial rather than hiding them entirely

Comment 68 by, Sep 21

My employer outsources WWW to a third party - we don't want to use '@' for our domain and point it to a third party, which Chrome is wanting to force us to do. This is what DNS is for, to allow US to make this decision. If we want to use www, which we have for years, you should not modify it.

Comment 69 by, Sep 24


a lot of our customers, e.g. the Ministry of Foreign Affairs will get really confused by this, they expect to see "www." in front of their domain. They will be wondering what's wrong and actually want in the browser bar, not!
After all, they got told to enter stuff only into "", and not anywhere else.

There will be lots of bug reports ("why do you redirect to") and it will cause an awful lot of discussion and work for us.

Please don't do this. If you want better readability, please grey out parts of the url!

Comment 70 by, Sep 24

To enable this by default makes no sense whatsoever for the end user. The confusion and security risks associated are not worth the effort as there is no clear "benefit". If you want to add this as a "feature" that a user can enable that's one thing. DO NOT enable it by default thinking that end users want this because you are wrong. Simple.

Comment 71 by, Sep 26

This change is not comprehensible from any perspective. Just like the other changes of version 69. After years changed to a "not so evil" browser.

Comment 72 by, Sep 26

Indeed. It looks almost as if Google had changed its corporate CoC from "don't be evil" to something else...

Comment 73 by, Sep 26

This Function is even more broken than you guys thought.

Visit "", everythign is normal
Now visit "", you are redirected to ""

you can't access "" anymore unless you explicit use "" (once)

Comment 74 by, Sep 26

As seen in the example of comment 73. the is what you expect: the website for the time servers.
the is something different (from my place it redirect to an esport site). Now that will confuse a lot of people.
I assume this is already doing geo based dns magic and the redirect to the esport site pops up on their servers as a default vhost.

I vote for leave the hands off the url, I prefer every bit shown as black on white, including protocol, (sub)-domains and file parts.

Comment 75 by, Sep 26

For years, Chrome has made efforts to attract web developers by adding more development features and debugging capabilities.

Mangling the URL in the way it is planned is stupid by design and confusing for regular users. But it it OFFENDING to web developers. If this gets implemented for good, I guess the majority of developers and "technical" people in general will move away from Chromium based browsers over time. And who guess recommends or installs browsers for non-technical people? Right...

This is how the decline started for IE, and it is how it will start for Chrome.

Comment 76 by, Sep 26

Comment 74: it isn't

When I explicit enter "" , "" is not the address I would expect

It is like redirecting the user to exploit.domain.tld instead of domain.tld

Comment 77 by, Sep 26

I can see the desire to 'simplify' the browsing experience in order to make web browsing more accessible to a new wider audience of people who might not even realise they are browsing. The prize of a massive new audience of technically illiterate people (and their money) will be attractive to the advertisers who fund Google. I get that.

However, I don't think this is a good way of doing that.

The omnibox is now used both for entering URLs and for performing searches. It is only the web prefixes and suffixes that distinguish between the two uses.

Hiding that discriminator is bound to lead to confusion. A cynic might think that would be to the advantage of large enterprises buying up a dictionary's worth of TLDs, and to the disadvantage of everyone else.

It might be argued that we don't generally display the TCP port number at the end of the URL, because it is implicit in the protocol. And that on the same basis www should similarly be hidden. However this comparison is only valid if the web has the concept of a 'default' subdomain. Which we do not. www is a common subdomain for sure, but it has never been standardised as the default, and pretending it has been is deceptive and disingenuous.

Now Google may wish to nudge the world towards making bare domains more popular, but messing with the address display is not the way to do it. 

Instead of messing with the browser, a possible way of nudging would be to adjust Google search results to reward sites where www is not used, or where www is redirected to the bare domain at the server, in the same way that they have used search results manipulation to encourage the use of https. People might object to that too, but Google would be on much stronger ground to argue they can display whatever search results they like on their own website.

Oh, and we won't mind if they redirect to, rather than the opposite as they do now ;-)

Comment 78 by, Sep 26

No, please. What is the reason for adding this confusing feature? (apart its pros for GA) Any subdomain is infact a unique domain according to the definition, hence handle them accordingly please and do not make assumptions on them.

Elsewise, I'd appreciate to use a "www" chromium fork in the future.

Comment 79 by, Sep 26

Dear Devs,

a URL is and will be a technical thing. It's no design thing. It's not meant to be. There are a lot of things people can do to deuglify their URLs for the most part, but you still need to keep URLs structurally intact. We're talking about fundamental internet technology here. 

People need to be able to verify what they do and where they are. You're breaking the possibility. 

You're breaking rules of correctness. 

You're going to make your browser unreliable and untrustworthy.

You will confuse people.

You're going to break the internet. No small design and UX win will be able outrule the cost of this.
Wilken Haase
Gambio GmbH, Bremen, Germany

Comment 80 by, Sep 27

The definition of a domain is pretty simple. You try to implement an exception. Exceptions are evil. Don't be evil!

Forget it!


Comment 81 by, Sep 27

This ist not a feature but a bug and it does not simplify anything. Doing this is a similar mistake as Google did when they decided to redirect toplevel domains like ".test" to google-search instead of trying to resolve them first. This makes Chrome unusable and this and a lot of other - privacy issues - are a reason for me to finally switch to something else. Apparently the marketing guys took over Google, because i can't believe a technical guy would come up with such stupid decisions.

Comment 82 by, Sep 27

It is hard for me to believe that the Chromium team is indeed planning to elide parts of the origin. and is simply not the same, and users should not be made to believe that.

However, I fully support greying out the URL while keeping the main domain highlighted.

Comment 83 by, Oct 2

Simply don’t elide anything. You’re really causing more security problems than solving.

I can’t believe engineering resources are being wasted on this instead of more grave issues, such as your subpar font rendering.
Do not display the location to be anything other than exactly what it is.  The browser and browser maker have no authority to opine concerning which parts of a domain name are important.  Google is overstepping.  BACK OFF.

My fellow security practitioners and I have worked for years to impress upon end-users that they must vigilantly ensure that they are browsing the exact correct site that they intend.  Failing to faithfully report the actual URL of the page is deceptive and is a Dark Pattern.  Eliding subdomains creates complexity, confusion, and is a support/troubleshooting burden.  Chrome's own foul-up regarding "" was instant proof of that.

I cautiously support Google when they use Chrome's dominance to promote generic security objectives such as increasing HTTPS adoption.  However, ELIDING SUBDOMAINS IS A TERRIBLE IDEA, and is an offensive indication that Google has become too comfortable with using its dominance to shape the Internet to match its tastes.

Comment 85 by, Oct 13

> We do not plan to standardize how browsers should treat these special cases in their UI.

The subdomain is a part of URL.
URL is uniform.
Then, do not elide any subdomains. Do not touch anything about URL.

Comment 86 by, Oct 13

A point I don't think anyone else has brought up yet: if there's a security error because the domain is www.whatever.tld but the cert is for whatever.tld, the result is very confusing. The certificate is for whatever.tld, and the omnibox says I'm on whatever.tld; it's only the actual text of the error that gives the true domain, and since that same text appears for almost all security errors, it's doubtful in my opinion that anyone actually reads it once they've seen it a few times.
Screenshot from 2018-10-14 00-07-14.png
50.3 KB View Download

Comment 87 by, Oct 16

I noticed that as of Chromium 72.0.3581.0 the flags have been split in two: #omnibox-ui-hide-steady-state-url-scheme and #omnibox-ui-hide-steady-state-url-trivial-subdomains.

I think this is great as Google can hide the https:// again without any harm, even if the subdomain discussion needs more testing.

Comment 88 by, Oct 16

Please, please, pretty please, do not use a flag and make it a Policy so that we can manage this setting with GPO!!!

Comment 89 by, Oct 22

Please do not elide any part of the URL, there are no irrelevant parts in the context of security, usability, or troubleshooting.

Comment 90 by, Oct 23

The change personally is annoying and over time its going to make peoples lives in security much harder, while the average user won't really see any difference whatsoever. 

My main issue is that this opens up a potential loophole for attackers to exploit, by slamming a www. in front of any other subdomain/domain a malicious attacker can impersonate any subdomain on a website while making it look like the legitimate address.  Admittedly if a malicious attacker has control of the DNS handling then they can most likely do much more damage than this, however its still an issue and it'll be be only a matter of time till this comes to light if it gets pushed.

I would almost agree that if this does get pushed through to assign a CVE number to this change, as it creates a security vulnerability within the application.

Best Regards


Comment 91 by, Oct 23

Some points:
- This is freaking ridiculous.
-- Why?. It adds up when we think of Google's ability (and contribution) to steer the experience which the world is going to have. Now, why do you think a normal user even care about this?. Do you think the weakest link is going to behave any better?.

- This guarantees security benefits under specific conditions only
-- Why wouldn't I have a better system in place (proactivity at OS-level) to fix this without increasing cross-team friction?.

- A healthy majority of people in the world might be still using "" over "" in their day to day experiences.
-- Why do you want to contribute code that would be necessary?.

Comment 92 by, Oct 23


Comment 93 by, Oct 23

I agree with the majority of the feedback to this point.  Hiding "www" adds to use confusion.  We experienced a number of "issues" reported to us during the short time where "www" was elided in Chrome 69. For many (most?) sites, "www" is different than without "www", even if this difference is as trivial as a redirect to the canonical URL.

Eliding "www" will do nothing more than cause additional user confusion, make it more difficult to troubleshoot issues, and open potential security risks for services that allow user-generated subdomains.

I would be in support of a change to highlight part of the domain.  For example in the URLs and, "" and "" could be highlighted in some manner to clarify the "important" part of the domain.  This might be everything but "m/www", or maybe just the public suffix plus one level.

Comment 94 by, Oct 23

I also support *not* eliding www - as a web host, this has already caused me much grief with customers wondering why their canonicalization aren't working any more (they are, just the 'www' is elided so they believe their redirects are broken!).

This causes much confusion for all parties!

Comment 95 by, Oct 23

Please ALWAYS show everything of the URL. People who don't care about the URL will not look at it anyway, so it's unimportant for them how the URL looks, and people who rely on the URL and take a look, want to see the full URL. Always.

Comment 96 by, Oct 23

Do not elide any domain whatsoever. Doing so is bad for usability, security, and supporting users.

Comment 97 by, Oct 23

Please stop hiding any parts of the URL in the address bar. This is bad for many reasons including security and supporting of any user base. And yes there can be differences between and

Comment 98 by, Oct 23

Do not hide any information in the URL.

Comment 99 by, Oct 23


12 frivolous characters.  I agree with Comment #17.

strip out http(s)://
gray out everything but base domain + TLD and color-code them as green for secure and red for not.

would be
and would be green while all other text is grayed. Or perhaps preceding subdomain stuff could be black, red/green & everything following the TLD would be grayed.

Comment 100 by, Oct 24

Yeah please don't go hiding the m/www components of the URL, just because you can't see a use case for having the zone apex A record different to the www/m resource records doesn't mean there isn't one.

Zone apex records cannot have CNAMEs, so they can't be directed to a CDN or GTM.  A common solution for this is to add a bunch of A records that host 301 redirects to www which will resolve to a CNAME and then end up at the CDN.  If a customer comes to me with a browser screenshot without the www the assumption is my 301 redirect is broken, not that Chrome devs are deliberately making life difficult.

Comment 101 by, Oct 26

In the latest update, if the feature flag #omnibox-ui-hide-steady-state-url-trivial-subdomains is Default, https:// and www. prefixes are hidden. When set to Enabled, https:// is visible but www. is hidden. When set to Disabled, both https:// and www. are both visible. I don't think this is the right behaviour?

Comment 102 by, Oct 28

please stop messing with the visibility of sub domains. There are no pro arguments for it. 

if you want to mess with this, leave it to the site administrators/developers with a flag within the dns/robots.txt or whatever

Comment 103 by, Nov 7 and (porn site, I HAVE WARNED YOU) are different sites, although controlled by the same person.
Please consider backward-compatibility seriously.
Anyway, I have abandoned Chrome permanently.

Comment 104 by, Nov 8

Chrome 71 still hiding `www.` subdomain

Stop this shit RIGHT NOW. Showing subdomain is a must even just `m.`. And it make ambiguity for a site that has no subdomain

Comment 105 by, Nov 20

 Issue 906471  has been merged into this issue.

Comment 106 Deleted

Showing comments 7 - 106 of 106 Older

Sign in to add a comment