IncrementURL
Tags: browsers, security, urls, phishing
Published: 2020-02-20 16:08:11

---
title: IncrementURL
published: true
date: 2020-02-07 17:33:04 UTC
tags: browsers,security,urls,phishing
canonical_url: https://adactio.com/journal/16411
---

Last month I wrote some musings on [default browser behaviours](https://adactio.com/journal/16295). When it comes to all the tasks that browsers do for us, the most fundamental is taking a URL, fetching its contents and giving us the results. As part of that process, browsers also _show_ us the URL of the page currently loaded in a tab or window.

But even at this fundamental level, there are some differences from browser to browser.

Safari only shows you the domain name—and any subdomain names—by default. It looks like nice and tidy, but it obfuscates what _page_ you’re on (until you click on the domain name). This is bad.

Chrome shows you the full URL, nice and straightforward. This is neutral.

Firefox, like Chrome, shows you the full URL, but with a subtle difference. The important part of the URL—usually the domain name—is subtly highlighted in a darker shade of grey. This is good.

The reason I say that what it highlights is _usually_ the domain name is because what it actually highlights is eTLD+1.

The what now?

Well, if you’re looking at a page on `adactio.com`, that’s the important bit. But what if you’re looking at a page on `adactio.github.io`? The domain name is important, but so is the subdomain.

It turns out there’s [a list](https://en.wikipedia.org/wiki/Public_Suffix_List) out there of which sites and top level domains allow registrations like this. This is the list that Firefox is using for its shading behaviour in displaying URLs.

Safari, by the way, does not use this list. These URLs are displayed identically in Safari, the phisherman’s friend:

- example.com
- example.github.io
- github.example.com

Whereas Firefox displays them as:

- **example.com**
- **example.github.io**
- github. **example.com**

I learned all this from [Jake](https://jakearchibald.com/) on [a recent edition of HTTP 203](https://www.youtube.com/watch?v=0-wB1VY3Nrc). Nicolas Hoizey has writen [a nice little summary](https://nicolas-hoizey.com/links/2020/01/29/humans-can-t-read-urls-how-can-we-fix-it/).

<iframe loading="lazy" title="Humans can't read URLs. How can we fix it? - HTTP 203" src="https://www.youtube-nocookie.com/embed/0-wB1VY3Nrc" width="480" height="270"></iframe>

Jake acknowledges that what Apple is doing is ~~shi~~ … <ins>suboptimal</ins>, what Firefox is doing is good, and then puts forward an idea for what Chrome could do. (But please note that this is Jake’s _personal_ opinion; not an official proposal from the Chrome team.)

There’s some prior art here. It used to be that, if your SSL certificate included extended validation, the name would be shown in green next to the padlock symbol. So while my website—which uses regular SSL from Let’s Encrypt—would just have a padlock, [Medium](https://medium.com/)—which uses EV SSL—would have a padlock _and_ the text “A Medium Corporation”.

Extended validation wasn’t quite the bulletproof verification it was cracked up to be. So browsers don’t use that interface pattern any more.

Jake suggests repurposing this pattern for all URLs. Pull out the important bit—eTLD+1—and show it next to the padlock.

[<picture>
<source media="all and (min-width: 46em)" srcset="https://adactio.com/images/uploaded/16393-1/large.png">
<source media="all and (min-width: 27em)" srcset="https://adactio.com/images/uploaded/16393-1/medium.jpg,
https://adactio.com/images/uploaded/16393-1/large.jpg 1.25x">
<img style="width: 100%" loading="lazy" src="https://adactio.com/images/uploaded/16393-1/small.png" srcset="https://adactio.com/images/uploaded/16393-1/medium.png 1.5x,
/images/uploaded/16393-1/large.png 2.5x" alt="Screenshots of @JaffaTheCake’s idea for separating out the eTLD+1 part of a URL in a browser’s address bar.">
</source></source></picture>](https://adactio.com/notes/16393)[<picture>
<source media="all and (min-width: 46em)" srcset="https://adactio.com/images/uploaded/16393-2/large.png">
<source media="all and (min-width: 27em)" srcset="https://adactio.com/images/uploaded/16393-2/medium.jpg,
/images/uploaded/16393-2/large.jpg 1.25x">
<img style="width: 100%" loading="lazy" src="https://adactio.com/images/uploaded/16393-2/small.png" srcset="https://adactio.com/images/uploaded/16393-2/medium.png 1.5x,
https://adactio.com/images/uploaded/16393-2/large.png 2.5x" alt="Screenshots of @JaffaTheCake’s idea for separating out the eTLD+1 part of a URL in a browser’s address bar.">
</source></source></picture>](/notes/16393)

I like this. The full URL is still displayed. This proposal is more of an incremental change. An enhancement that is applied progressively, if you will.

I also like that it builds on existing interface patterns—Firefox’s URL treatment and the deprecated treatment of EV certs. In fact, I think the first step for Chrome should be to match Firefox’s current behaviour, and _then_ go further with something like Jake’s proposal.

This kind of gradual change was exactly [what Chrome did with displaying `https` and `http` domains](https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html).

[![Chrome treatment for HTTPS pages.](https://adactio.s3.amazonaws.com/images/chrome-https-transition.png)](https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html)

Jake mentions this [in the video](https://youtu.be/0-wB1VY3Nrc?t=1106)

> We’ve already seen that you have to take small steps here, like we did with the `https` change.

There’s a fascinating episode of the Freakonomics podcast called [<cite>In Praise of Incrementalism</cite>](http://freakonomics.com/podcast/in-praise-of-incrementalism/). [I’ve huffduffed it](https://huffduffer.com/adactio/564584).

<audio src="https://traffic.omny.fm/d/clips/aaea4e69-af51-495e-afc9-a9760146922b/14a43378-edb2-49be-8511-ab0d000a7030/d334e340-b34f-4cf5-a0e8-ab0d0011f658/audio.mp3" controls preload="none"><a href="https://huffduffer.com/adactio/564584">In Praise of Incrementalism (Ep. 264) - Freakonomics Freakonomics on Huffduffer</a></audio>

I’m a great believer in the HTML design principle, [Evolution Not Revolution](https://www.w3.org/TR/html-design-principles/#evolution-not-revolution):

> It is better to evolve an existing design rather than throwing it away.

I’d love to see Chrome take the first steps to Jake’s proposal by following Firefox’s lead.

Then again, I’d love it if Chrome followed Firefox’s lead in [implementing subgrid](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/71).