New issue
Advanced search Search tips

Issue 621157 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: 2020-01-07
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Investigate navigations to hostnames which are also eTLDs

Project Member Reported by thomasanderson@chromium.org, Jun 17 2016

Issue description

Version: 51.0.2704.84 (Official Build) (64-bit)
OS: Ubuntu 14.04

What steps will reproduce the problem?
Type "tomsk.ru" in the omnibox, and press enter.

What is the expected output?
Chrome navigates to the site.

What do you see instead?
Chrome searches the URL instead.

 
After some digging, it looks like "tomsk.ru" and many other domains are listed as "effective tld names" here https://cs.chromium.org/chromium/src/net/base/registry_controlled_domains/effective_tld_names.dat?l=5768

In autocomplete_input.cc, when we call net::registry_controlled_domains::GetRegistryLength, it (correctly) returns 0 as per https://cs.chromium.org/chromium/src/net/base/registry_controlled_domains/registry_controlled_domain.h?cl=GROK&gsn=GURL&q=net::registry_controlled_domains::getregis&sq=package:chromium&rcl=1466162237&l=223

However, we determine if the tld is valid by checking if registry_length != 0.  So, we incorrectly think we don't have a valid tld.

So, is this just a simple software integration issue, or ... correct behavior?
Status: WontFix (was: Available)
Yes, this is Working As Intended.  Either the PSL is wrong and tomsk.ru is not an eTLD (please fix) or the registrar is letting people navigate to a "TLD", which is IMO a bug with the registrar.
Mozilla doesn't recommend this case https://www.publicsuffix.org/learn/

"Some people use the PSL to determine what is a valid domain name and what isn't. This is dangerous, particularly in these days where new gTLDs are arriving at a rapid pace, if your software does not regularly receive PSL updates, because it will erroneously think new gTLDs are not valid. The DNS is the proper source for this information. If you must use it for this purpose, please do not bake static copies of the PSL into your software with no update mechanism."

It also looks like Chrome is the only browser that uses the PSL in this way.  On Opera, Firefox, Edge, and Safari, I can type "tomsk.ru" directly into the address bar.

There are many more domains that are (for some reason) classified as eTLDs, but have web pages.  I tried some of the ones after "tomsk.ru" in the list, for example

tomsk.ru
tsaritsyn.ru
tsk.ru
tula.ru
tuva.ru
tver.ru
tyumen.ru
udm.ru
udmurtia.ru
Yes, we've discussed our differing positions on this with Mozilla before.

And I'm aware that a number of TLDs are directly navigable today; that's a side effect I'm OK living with.  Firefox doesn't have an omnibox proper, and Edge and Safari's implementations aren't as sophisticated in general as ours, so it doesn't surprise me they don't use things in this way.

The only thing we could do would be to allow navigation to an eTLD if it would be considered a valid URL under some other PSL rule.  For example, if we have:

co.jp
ru
tomsk.ru

Then co.jp would not be navigable, but tomsk.ru would be because it would be a URL under the .ru TLD.

This is potentially dangerous.  We'd need to make sure x.tomsk.ru cannot read or write cookies for tomsk.ru, because the two have different TLDs.  In general having www.tomsk.ru not be a subdomain of tomsk.ru is scary and I'd be worried about bugs here.

Comment 5 by sh...@chromium.org, Jun 17 2016

If you enter "tomsk.ru" we default to a search but give you a "did you mean" infobar because the site exists, so we aren't really enforcing any sorts of protection, here.  Your navigation suggestion would just clean that up, but it wouldn't affect cookie resolution at all.
Labels: -Pri-2 Pri-3
Status: Available (was: WontFix)
Summary: Investigate navigations to hostnames which are also eTLDs (was: Omnibox sometimes searches for URLs instead of navigating to the URL directly)
I was giving downsides based on an implementation that modified the eTLD code so that "tomsk.ru" was in general reported as having a TLD of ".ru".  That's different than forcing a navigation to this today.  That said, part of the issue here is that if you do force a navigation today, I don't know whether we always do the right thing or not.  So that would need investigating too.

We could modify the eTLD code so that it only reported this as having a .ru TLD under a switch that said "ignore if a rule says this is a direct eTLD", which would leave the rest of the behavior roughly the same as today, with the attendant question marks about downsides.

I'm going to reopen because it seems like there are at least possibilities worth exploring here, but leaving as P3.
Components: Enterprise
Labels: Enterprise-Triaged
NextAction: 2018-01-09
I have a sense that eTLDs are not yet common enough that this is much of a problem.  Tagging to reassess early next year.

Tagging as Enterprise because it largely affects intranet users.

thomasanderson@: do you remain the right owner for this?
Cc: thomasanderson@chromium.org
Owner: ----
Probably not the right owner
The NextAction date has arrived: 2018-01-09
NextAction: 2019-01-08
The tld landscape is still evolving, and it's not yet clear if there will be many eTLDs that are meant to be navigable.  Punting for another year.
 Issue 695193  suggests that there may be problems with certificate validation in this scenario.
The NextAction date has arrived: 2019-01-08
Cc: emilyschechter@chromium.org
NextAction: 2020-01-07
I'm tentatively punting this for another year.  The open question is whether there will be many eTLDs that are meant to be navigable.  I'm not sure we have a sense of that yet.  Anyone on this thread is welcome to comment.  CCing emilyschechter in case she knows the best point of contact on the Chrome team who knows about adoption of eTLDs.

Sign in to add a comment