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

Issue 881410 link

Starred by 291 users

Issue metadata

Status: Duplicate
Merged: issue 881694
Owner:
Closed: Sep 7
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug-Regression

Restricted
  • Only users with EditIssue permission may comment.


Show other hotlists

Hotlists containing this issue:
Chromium-Security
ZapList


Sign in to add a comment

Incorrect transforms when stripping subdomains

Reported by hugues.a...@gmail.com, Sep 6

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36

Steps to reproduce the problem:
1. Enter any URL starting with "www.", for example, www.google.com

What is the expected behavior?
The URL Bar should show "www.google.com"

What went wrong?
The URL Bar shows "google.com"

Did this work before? Yes 68

Chrome version: 69.0.3497.81  Channel: stable
OS Version: OS X 10.13.6
Flash Version:
 
"www" is now considered a "trivial" subdomain, and hiding trivial subdomains can be disabled in flags (will also disable hiding the URL scheme)

chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains
This is a dumb change. No part of a domain should be considered "trivial". As an ISP, we often have to go to great lengths to teach users that "www.domain.com" and "domain.com" are two different domains, and that they may not necessarily go to the same destination. The marketing world has done a lot of damage convincing people that "www" is both ubiquitous and non-essential, when in fact, for some domains, the use or lack of it can be quite important to getting to the correct location.
How will you distinguish http://www.pool.ntp.org vs http://pool.ntp.org ?

One takes you to the website about the project, the other goes to a random ntp server.
Labels: Hotlist-ConOps
This does appear to be inconsistent/improperly implemented. Why is www hidden twice if the domain is "www.www.2ld.tld"? I feel like the logic could be worked out better, eg
If the root zone is a 301 to the "www" version, removing "www" from the omnibox would be acceptable since the server indicated the root zone isn't intended for use. 

This isn't the behavior, though. If example.com returns a 403 status, and www.example.com returns a 404 status, the www version is still hidden from the user. The www and the root are very obviously different pages and serve different purposes, so I believe the should be some logic regarding whether or not www should be hidden.
Same behavior in Win 10, as expected...

Very Very bad decision! Exactly which authority considers it "trivial"? Every part of a domain is as critical as the rest, it's not exactly your responsibility to regulate names.
+1 for having a switch for this behavior, but -10 for special-casing 'www' in the default display. To be fair, I also hate pretty much all other forms of 'simplified' URL presentation. I think we should be arming people with knowledge and encouraging discerning behavior, and we should not be trying to gain the minimal benefit of a slightly shorter display string in exchange for compromising the correctness of something as fundamental as a phone number.
Another case I ran into:

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

Completely wrong.
An example of bad results from this in the wild: https://citibank.com.sg and https://www.citibank.com.sg are not the same site, and the first doesn't redirect to the second.
This is Google making subdomain usage decisions for other entities outside of Google. My domains and how subdomains are assigned and delegated are not Google's business to decide.
Components: -UI UI>Browser>Omnibox
Labels: OS-Chrome OS-Linux OS-Windows
Cc: pkasting@chromium.org jdonnelly@chromium.org
--> Userfeedback

Dupe:  Issue 881335 .
re: Dupe:   Issue 881335  

Doesn't look like a dupe to me - looks like "same root cause" but not a dupe.  That bug, and all the google announcements linked in that bug have no mention of 'trivial subdomain' hiding.
While the cause of this issue and 881335 may be similar marking this as a duplicate does not make sense. (Especially if that implies that this issue will be marked as "Won't fix") Hiding portions of the domain name is about as hostile to the user as you can get. It means users cannot trust what they see in the address bar as truth and opens people up to the possibility of phishing attacks as well as extremely frustrating and hard to reproduce behaviors.
The domain m.tumblr.com is shown as tumblr.com, two totally different sites.
This will be a subdomain hacker/takeover dream.  It will be much easier to masquarade as a parent domain now.

Oh, and also hiding the trivial 'm.<domain>' is irritating - I often avoid (and in once case seek out) the m.<domain> due to the difference in content for the so-called mobile site.
Cc: -jdonnelly@chromium.org
Owner: jdonnelly@chromium.org
The subdomains reappear when editing the URL so people type the correct one.  They disappear in the steady-state display case because this isn't information that most users need to concern themselves with in most cases.  I think this is an OK tradeoff even in the rare case when www.foo.com is not actually the same as foo.com.  (Side note: like it or not, almost no real-world users will use such a thing correctly; configuring your server like this seems like a Bad Move even if it's technically legal, because people are going to access the wrong thing, and that has been true for some time and irrespective of Chrome's UI changes.)

There are multiple real bugs here though:

www.www.2ld.tld should become www.2ld.tld, not 2ld.tld (we should strip at most one m. and www.)
subdomain.www.domain.com should be left as-is, not subdomain.domain.com (should only strip prefixes)

->jdonnelly to assign.
Also, on 69.0.3497.81 Mac, I have to click the omnibox *twice* for the https:// and www. prefixes to show up. At the very least I feel it should only require one click for the prefixes to show up.
Cc: -jdonnelly@chromium.org
Owner: jdonnelly@chromium.org
Status: Assigned (was: Unconfirmed)
Summary: Incorrect transforms when stripping subdomains (was: "www." subdomain missing from URL)
@19: Changing things on focus turns out to feel much more frustrating in a lot of use cases (we tried both, plus a lot of other behaviors).
Is there a list anywhere of what mighty Google considers trivial?
Re: security, hacker/takeover

We have a domain that is on the Public Suffix List. We control the Public Suffix root (like .com, .dyndns.org). When someone registers the www-subdomain (like www.com or www.dyndns.org or www.blogger.com), will that be shown as the PSL root domain (like .com, dyndns.org, blogger.com)?

How will people see that they are NOT on our site, but on a subdomain that is controlled by a third party?
@18:

> this isn't information that most users need to concern themselves with in most cases.
According to who? This is simply an opinion stated as a fact.

> I think this is an OK tradeoff even in the rare case when www.foo.com is not actually the same as foo.com.
How rare is this case? Comment #9 shows that citybank has 2 different websites hosted at both those URLs. Comment #16 shows the same issue with tumblr.com. Clearly, this case isn't as rare as expected.

> (Side note: like it or not, almost no real-world users will use such a thing correctly;)
That's unfortunately, just another opinion stated as fact.
I actually thought Chrome was malfunctioning. This decision seems totally arbitrary. Was there any research done to justify this decision, or was it the whimsy of a PM who thought it would be a cool UX thing?
Please revert this change, this is an alienation to every Web user, they need and have the right to know which URL are they visiting.
Enter into the address bar:

http://www.example.www.example.com

It shortens it:

example.example.com

WTF? How does www.example.www.example.com === example.example.com?
I just don't understand why. On my clock, if it's 12:00, I see 12:00 not 12. When I get a receipt and it's a dollar value, I see $2.00 not $2, when I enter phone numbers to call, the number I entered is what I see displayed: it doesn't reduce it by removing the country code, or the area code if unneeded, etc.

Everyone loses clarity and some users will lose time due to this, but we gain what? What is the benefit in hiding 4 characters?
As a web developer I am a little horrified that the decision was made to hide a portion of a URL that could potentially be pointing to a completely different server. Please revert.
(Edit for @28, after seeing @27 I notice it's not just 4 characters at the beginning of the url it's a lot more and at a much more serious loss of clarity. This is crazy the paths are not shortened they are completely changed).
Arbitrary half-cocked changes like this and the recent AMP stuff are really pushing me away from all of Google's services. This change has not been thought out well.
I believe this Wired article gives some perspective to this change: https://www.wired.com/story/google-wants-to-kill-the-url

They use altruistic arguments, but of course we can all see their business objectives as a search engine to get rid of the URL. This is probably just a first small step to reduce the importance/trust of the URLs.
@18

> They disappear in the steady-state display case because this isn't information that most users need to concern themselves with in most cases.

If most users don't care (which I think is what this is getting to) and power users do care, what's the concern on keeping the subdomains then? This is just adding corner-cases where none are necessary, and means that if I want to know what URL I'm viewing, I won't be able to at a glance, I'll have to click to check.
Related to @27:

I also noticed, if you double click the omnibox while on http://www.example.www.example.com, the cursor is at the wrong position. If you double click the omnibox to the right of the URL, it focuses the cursor here: http://www.example.www.exa|mple.com but it should be at the end of the .com.

I think the offset calculation for the cursor is wrong. Similarly if you double click the omnibox on top of the URL, then it also inserts the cursor at the wrong position.
Just to add, Safari also hides http(s) and www. From their address bar as well. Heck, they only show the domain name and hide the rest of the url unless you click to edit it.

On HTTP sites, Safari doesn't even show 'http://' when you edit the address bar. It is still copied to the clipboard though. Try it on http://neverssl.com


@jeffreyc / 35: Safari for desktop (at least) does not hide the www. It does hide the protocol though. I think you might be thinking of Safari for iOS.
safari-www-address-bar.png
114 KB View Download
If the objective is to make URLs less confusing an emphasize the main domain name, why not just render parts in gray or make the main part bold. Wouldn't that achieve the same goal without essentially breaking the internet?
Since this is essentially a security vulnerability, is Google going to get a CVE assigned for it? It would make it easier to help effected users make sure this is patched on their end.
This is a complete mess, please revert to the old good and nice state. 
Here's another example where it goes very wrong. The site "www.m.www.m.example.com" should not show up as "example.com".

Very disappointed with this change.
@37 I tried to convince them to do that back in '08 https://bugs.chromium.org/p/chromium/issues/detail?id=1971
Cc: jdonnelly@chromium.org
Owner: tommycli@chromium.org
-> tommycli@
some examples of bad stripping of subdomains on this thread

By the way, the stripping of the "m." host/subdomain on desktop platforms was confusing and problematic, I agree.  It was reported in  bug 875669  and fixed for Chrome 70.
Another 'me too'.  I can just see tech support screaming, there could be 2 completely dfferent websites that show as the same in the URL.  I'm also dreading the SQL certificate issue - not everyone uses wildcard certificates for good reason, www.domain.com may be separate infrastructure from support.domain.com.
This is going to cause troubleshooting issues. For example, if a site is slow you might open up terminal and do a traceroute/ping/etc. Many sites use redirect services provided by their CDN, DNS provider, registrar, etc. to redirect company.com to www.company.com, so you definitely need to know which one.

Of course, someone technical enough to do that sort of troubleshooting will quickly learn to view the full URL, but imagine if you're helping a non-technical person over the phone: "What's the URL?" "foo.com/whatever" "Are you sure it's foo.com and not www.foo.com?" "Yes." "Are you using Chrome?" "I think so." "Double-click the address bar and tell me if it changes." "It didn't." "Are you sure you double clicked? Do you see an http:// or https:// in front?" "Oh, wait, nevermind. Now it says www.foo.com" "Ok, great."

Hiding "noise" like the protocol and www from users is a good idea, but I hope you find a way to do it without obscuring important information. (I like the idea of just using really light text.)
Cc: emilyschechter@chromium.org f...@chromium.org
Labels: Team-Security-UX Restrict-AddIssueComment-EditIssue
 Issue 881206  has been merged into this issue.
Cc: phanindra.mandapaka@chromium.org
 Issue 881662  has been merged into this issue.
FYI from recently merged  issue 881662 :
**************************************

Steps to reproduce the problem:
1. Attempt to visit: https://concourse.m.example.com

What is the expected behavior?
Host is shown as "concourse.m.example.com"

What went wrong?
Host is shown as "concourse.example.com"
Cc: tommycli@chromium.org
 Issue 838166  has been merged into this issue.
Mergedinto: 881694
Status: Duplicate (was: Assigned)
this discussion ended up veering, let's have the security discussion about elision at 881694
Issue 881979 has been merged into this issue.
Issue 881950 has been merged into this issue.
 Issue 882309  has been merged into this issue.
 Issue 882306  has been merged into this issue.

Sign in to add a comment