Browsers that don’t love their users

Misunderstandings on security, usability and user experience.

When you browse to a web whose domain starts with “www”, Safari and Chrome hide such “www” prefix at address bar. Why? They think it’s better for you. According to Google’s words [1]: Chrome “hides URL components that are irrelevant to most Chrome users”.

Let’s say you are using Chrome… if Google is your favorite search engine, you’ll use it multiple times a day. So you’ll see the address bar several times a day and you’ll learn, without a doubt, what the address of the service is, Chrome tells you: “google.com”:

Suppose you can talk to someone at Google (just kidding, we all know that’s Mission: Impossible). You could have a chat like this:

You: I like your search engine very much. Thank you for developing it… Let’s get started: give me “google.com”

Google: That’s not the right way for request it. Start again, using “www.google.com”

You: Wait a minute… you just told me that “www” prefix is irrelevant. I’m just a user, come on, give me that awesome “google.com”

Google: That’s not the right way for request it. Start again, using “www.google.com”

You: Really? If it’s irrelevant, why do you want it?

Google: (no response)

You: You don’t love me anymore?

This kind of dialogue (maybe not so personal) is happening all the time between your browser and the web server. We can look at it with cURL (a browser for the command line):

$ curl --silent --head https://google.com/
HTTP/2 301
location: https://www.google.com/
content-type: text/html; charset=UTF-8
date: Sun, 18 Aug 2019 09:51:37 GMT
expires: Tue, 17 Sep 2019 09:51:37 GMT
cache-control: public, max-age=2592000
server: gws
content-length: 220
x-xss-protection: 0
x-frame-options: SAMEORIGIN
alt-svc: quic=":443"; ma=2592000; v="46,43,39"

When you request “google.com”, server’s response has a 301 HTTP status. This code (301) is defined at the HTTP standard [2] with this meaning: “the target resource has been assigned a new permanent URI… a Location header field in the response contains a preferred URI reference”. That is: you ask for https://google.com/ and the server redirects you to https://www.google.com. You can’t talk to Google if you don’t use the “www” prefix.

You can check this same dialogue with Chrome, via the Network panel of the Developer Tools:

Your browser, automatically, starts again (adding the “www” prefix) after the redirection and finally you get to the web page.

Apple has the same attitude: Safari hides the prefix “www”… because it’s better for you. So you think Apple’s website is published (you learn fast thanks to Safari’s address bar) on “apple.com”:

But Apple’s web server negates any response if you don’t use the “www” prefix:

$ curl --silent --head https://apple.com/
HTTP/1.1 301 MOVED PERMANENTLY
Server: Apache
Date: Sun, 18 Aug 2019 10:13:03 GMT
Location: https://www.apple.com/
Content-type: text/html
Connection: close

“www” prefix is irrelevant and mandatory for the same company. Unbelievable!

But things can get worse…

Based on Alexa’s ranking [3] the 6th most visited website in the world is Qq.com: China’s largest and most used Internet service portal.

The millions of people who visit this site with Chrome or Safari, will see (will internalize) that the site is published on “qq.com”:

Have you tried to load https://qq.com/ directly? Neither Safari nor Chrome (nor any other browser) can contact the server (because qq.com and www.qq.com are different things) and they show you an error:

Check the address bar of both browsers with and without error. They are the same, they contain the same information (nothing relevant is missing, Apple and Google say). How can you know the error was not using the “www” prefix?

We can also try with our text browser (cURL) to check the error:

$ curl https://qq.com/
curl: (7) Failed to connect to qq.com port 443: Connection refused

Thus, hiding the prefix “www” could promote a self-DoS (Denial of Service), as we just checked.

Surely you want to be up to date with the evolution of this issue and you will frequently check Google’s security blog … by the way, now you know why sometimes (with the same browser and on the same network) I get the first result (OK) and sometimes the second result (security error) when I try to enter the blog, right?

Since the address bar gives you all the relevant information, you must have found the previous question too easy… 😏

This last example shows that hiding part of the domain can also cause security problems.

If you use one/two of these browsers and don’t like this feature, the best thing you can do is report an issue to Chrome [4] or/and Apple [5] trying to change their minds. Meanwhile, you can configure the browser to avoid this problem. In Chrome it’s possible via chrome://flags [6]. For Safari I haven’t been able to find out if it’s possible.

Firefox doesn’t hide “trivial subdomains” yet. At least in desktop version. Unfortunately, it wouldn’t be surprising if Mozilla followed this latest Google’s move soon.

To WWW or not to WWW?

Notes

1. The screenshots and data on this post are accurate as of 08/18/2019. Software used: Chrome 76.0.3809.100 on Windows, Safari on iOS 12.4, cURL 7.58.0 on Linux.
2. All browser screenshots had taken using private mode (aka incognito mode)
3. Spanish versions of Chrome and Safari have been used. I hope that the language of the screenshots does not interfere with the reading and comprehension of the article.

References

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=883038#c114

[2] https://tools.ietf.org/html/rfc7231#section-6.4.2

[3] https://www.alexa.com/topsites

[4] https://support.google.com/chrome/answer/95315

[5] https://support.apple.com/safari

[6] https://support.google.com/chrome/thread/11357103?hl=en