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 292 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
link

Issue 881410: 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:
 

Comment 1 by hunterra...@gmail.com, Sep 6

"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

Comment 2 by earl.thu...@gmail.com, Sep 6

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.

Comment 3 by arielshk...@gmail.com, Sep 6

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.

Comment 4 by craigtumblison@chromium.org, Sep 6

Labels: Hotlist-ConOps

Comment 5 by hunterra...@gmail.com, Sep 6

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.

Comment 6 by t.deleni...@gmail.com, Sep 6

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.

Comment 7 by drelabra...@gmail.com, Sep 6

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

Comment 8 by drewhall...@gmail.com, Sep 6

Another case I ran into:

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

Completely wrong.

Comment 9 by copp....@gmail.com, Sep 6

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.

Comment 10 by cst...@gmail.com, Sep 6

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.

Comment 11 by meh...@chromium.org, Sep 6

Components: -UI UI>Browser>Omnibox

Comment 12 by meh...@chromium.org, Sep 6

Labels: OS-Chrome OS-Linux OS-Windows

Comment 13 by meh...@chromium.org, Sep 6

Cc: pkasting@chromium.org jdonnelly@chromium.org
--> Userfeedback

Dupe:  Issue 881335 .

Comment 14 by f...@clift.org, Sep 6

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.

Comment 15 by emeraldd...@gmail.com, Sep 6

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.

Comment 16 by sgtfrank...@gmail.com, Sep 6

The domain m.tumblr.com is shown as tumblr.com, two totally different sites.

Comment 17 by f...@clift.org, Sep 6

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.

Comment 18 by pkasting@chromium.org, Sep 6

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.

Comment 19 by jeffreyc...@gmail.com, Sep 6

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.

Comment 20 by pkasting@chromium.org, Sep 6

Cc: -jdonnelly@chromium.org
Owner: jdonnelly@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 21 by pkasting@chromium.org, Sep 6

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

Comment 22 by kwfin...@gmail.com, Sep 6

Is there a list anywhere of what mighty Google considers trivial?

Comment 23 by phillipp...@googlemail.com, Sep 6

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?

Comment 24 by hugues.a...@gmail.com, Sep 6

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

Comment 25 by he...@wyatt.engineer, Sep 6

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?

Comment 26 by montog...@gmail.com, Sep 6

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.

Comment 27 by he...@wyatt.engineer, Sep 6

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?

Comment 28 by combus...@gmail.com, Sep 6

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?

Comment 29 by sven.sve...@gmail.com, Sep 6

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.

Comment 30 by combus...@gmail.com, Sep 6

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

Comment 31 by cpress.s...@gmail.com, Sep 6

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.

Comment 32 by alf...@nurd.nu, Sep 6

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.

Comment 33 by combus...@gmail.com, Sep 6

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

Comment 34 by jeffreyc...@gmail.com, Sep 6

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.

Comment 35 by jeffreyc...@gmail.com, Sep 6

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

Comment 36 by geerling...@gmail.com, Sep 6

@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

Comment 37 by naftoli...@gmail.com, Sep 6

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?

Comment 38 by diabl...@gmail.com, Sep 6

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.

Comment 39 by martinve...@gmail.com, Sep 6

This is a complete mess, please revert to the old good and nice state.

Comment 40 by fer...@gmail.com, Sep 6

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.

Comment 41 by ghost...@gmail.com, Sep 6

@37 I tried to convince them to do that back in '08 https://bugs.chromium.org/p/chromium/issues/detail?id=1971

Comment 42 by mpear...@chromium.org, Sep 6

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.

Comment 43 by owenholl...@gmail.com, Sep 6

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.

Comment 44 by bensjob...@gmail.com, Sep 6

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

Comment 45 by palmer@chromium.org, Sep 6

Cc: emilyschechter@chromium.org f...@chromium.org
Labels: Team-Security-UX Restrict-AddIssueComment-EditIssue

Comment 46 by tommycli@chromium.org, Sep 6

 Issue 881206  has been merged into this issue.

Comment 47 by meh...@chromium.org, Sep 7

Cc: phanindra.mandapaka@chromium.org
 Issue 881662  has been merged into this issue.

Comment 48 by meh...@chromium.org, Sep 7

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"

Comment 49 by elawrence@chromium.org, Sep 7

Cc: tommycli@chromium.org
 Issue 838166  has been merged into this issue.

Comment 50 by f...@chromium.org, Sep 7

Mergedinto: 881694
Status: Duplicate (was: Assigned)
this discussion ended up veering, let's have the security discussion about elision at 881694

Comment 51 by mpear...@chromium.org, Sep 7

Issue 881979 has been merged into this issue.

Comment 52 by mpear...@chromium.org, Sep 8

Issue 881950 has been merged into this issue.

Comment 53 by mpear...@chromium.org, Sep 10

 Issue 882309  has been merged into this issue.

Comment 54 by mpear...@chromium.org, Sep 10

 Issue 882306  has been merged into this issue.

Sign in to add a comment