New issue
Advanced search Search tips

Issue 883038 link

Starred by 59 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Feedback: Eliding www/m subdomains

Project Member Reported by emilyschechter@chromium.org, Sep 11

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.
 
Components: UI>Browser>Omnibox
Labels: -Pri-3 Pri-2
Labels: OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Adding OS-labels per c#0
Please do not elide any components of URLs because all parts of a URL are user-controlled.  Information hiding discourages literacy.
Labels: Hotlist-ConOps-CrOS
Labels: Hotlist-ConOps
What problem does this solve exactly? I haven't seen a good reason for any of this.
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.
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.
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: https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#where-are-the-security-indicators-located-in-the-browser-window

"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.
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.
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.
> 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:
https://url.spec.whatwg.org/#url-rendering

(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".
> 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. 
>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 (free.fr), that, while not allowing "www" as a user-controlled domain, does allow "www.(whatever)" but also "(whatever)", so you can have both :
- http://www.whatever.the.user.wants.free.fr
- http://whatever.the.user.wants.free.fr
(- http://m.whatever.the.user.wants.free.fr 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.
Stop striping anything. URLs without www are not "easier" or "complexer" as URLs with www. It's just a unnecessary bug - not a feature. 
The future display `www.domain.name` or `domain.name` 
Let the domain owner decide.
If They want just set their `www.domain.name` redirect to `domain.name`.

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

I would suggest the following:
* Hide https:// (again) and http://, replacing them with no and red indicator, accordingly (continue your current plan at https://sites.google.com/a/chromium.org/dev/Home/chromium-security/marking-http-as-non-secure)
* 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
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 https://www.example.com, and that yields a cert with a SAN list of only www.example.com and nothing else. Eliding www to produce example.com when the SAN list of the Cert does not contain example.com is likely wrong and confusing in any case.
Please leave URLs as they are. Not always example.com is equivalent to www.example.com, 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.

At least make it a toggleable option, I dont mind if URLs are elided by default. But please have an option to disable this.
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"?

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.
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 :(
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

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


Regarding the eliding of schema:

Enter http://www.blacksburg.gov

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

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.
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. example.com) 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 https://chromium.org -vo/dev/null 2>&1 | grep Location
< Location: https://www.chromium.org/
$ curl https://google.com -vo/dev/null 2>&1 | grep Location
< Location: https://www.google.com/


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.
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. 
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.
Don't do it. It makes life hell for developers when the user reports stuff that doesn't match reality.
Hiding www is a very bad idea.

Please stop doing this.
repeat see 
https://bugs.chromium.org/p/chromium/issues/detail?id=881694#c104

If you insist on doing this, then I have no words.
Give me an Option just black Host and hide scheme & queryString .Thanks
Don‘t do it. It's not a good change

Comment 40 Deleted

Do not hide www!! If it ain't broke don't fix it.
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 www.domain.com and domain.com 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!
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 #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.
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 mydomain.com to www.mydomain.com 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.
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.
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!
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 www.goodsite.com.badsite.com. 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.
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.
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?
Nothing should be elided, please stop this madness.
If websites want a shorter url they should redirect from www.example.com to example.com
Cc: jdonnelly@chromium.org
Owner: emilyschechter@chromium.org
Status: Assigned (was: Untriaged)
emilyschechter: assigning to you to gather the feedback collected over the past week.
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:
http://chiark.greenend.org.uk/ tells the user they are on the wrong address, and that the correct address is http://www.chiark.greenend.org.uk/ . 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.
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 google.com 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.

[1] https://en.wikipedia.org/wiki/Gopher_(protocol)
[2] https://hacks.mozilla.org/2018/08/dweb-serving-the-web-from-the-browser-with-beaker/
[3] https://css-tricks.com/killing-the-url/
[4] https://www.wired.com/story/google-wants-to-kill-the-url/
[5] https://twitter.com/__apf__/status/1037181065423515648
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.
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.


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. 
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.
@ #60 Thanks for the update Emily.

I trust by "before launching the feature" you meant "before deciding whether to launch the feature" :-)
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. 
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?
@63 Flags are always temporary, whether they become settings is another question though.
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

My preference is to take the Firefox approach and grey out parts of the url considered less important / trivial rather than hiding them entirely
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.
Hi,

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 www.xy.com in the browser bar, not xy.com!
After all, they got told to enter stuff only into "www.xy.com", and not anywhere else.

There will be lots of bug reports ("why do you redirect www.xy.com to xy.com?") 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!
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.
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.
Indeed. It looks almost as if Google had changed its corporate CoC from "don't be evil" to something else...
This Function is even more broken than you guys thought.

Visit "www.pool.ntp.org", everythign is normal
Now visit "pool.ntp.org", you are redirected to "www.pool.ntp.org"

you can't access "pool.ntp.org" anymore unless you explicit use "http://pool.ntp.org" (once)


As seen in the example of comment 73. the www.pool.ntp.org is what you expect: the website for the time servers.
the pool.ntp.org 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.
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 74: it isn't

When I explicit enter "pool.ntp.org" , "www.pool.ntp.org" is not the address I would expect

It is like redirecting the user to exploit.domain.tld instead of domain.tld 
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 www.google.com to google.com, rather than the opposite as they do now ;-)
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.
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
The definition of a domain is pretty simple. You try to implement an exception. Exceptions are evil. Don't be evil!

Forget it!

Wolf
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.
It is hard for me to believe that the Chromium team is indeed planning to elide parts of the origin. domain.com and www.domain.com 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.
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 "www.example.www.example.com" 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 kanno...@gmail.com, Oct 13 (5 days ago)

> 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 anowlcal...@gmail.com, Oct 13 (5 days ago)

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 robotk...@gmail.com, Oct 16 (3 days ago)

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 voj...@gmail.com, Oct 16 (3 days ago)

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

Sign in to add a comment