Improving the URL bar

iOS has hidden the pathname of URLs for some time now, but recently Chrome Canary introduced something similar behind a flag.

I'm not involved in the development of Chrome experiment at all, but I've got more than 140 characters worth of opinion on it…

We have a real security problem

I recently received an email from my domain name registrar telling me was soon to expire. I followed the link, entered my username and was about to enter my password. I glanced up at the URL, it was HTTPS, great, had the registrar's URL in it, fine. Then I looked closer and realised it wasn't the registrar's URL at all. I was very nearly phished.

I get phishing emails all the time, but this one nearly got me. It was well written, it used all the same logos. When I followed the link my URL bar filled up, which is expected, the domain registrar I use doesn't have fantastic URLs. It did the usual trick of front-loading the URL. If I nearly got caught out, surely less savvy users are pretty screwed.

Real URL vs phishing URL

On top, a page from my bank's website, on the bottom, a phishing equivalent.

Part of this is my bank's fault. It's taught me not to expect HTTPS on all of its pages (thankfully the online-banking bits are), and to expect terrible URLs, but the browser could be doing a better job to save me.

Find someone who doesn't work in tech, show them their bank's website, and ask them what about the URL tells them they're on their bank's site. In my experience, most users don't understand which parts of the URL are the security signals. Browsers have started to make those parts of the URL bolder, but as you can see from the above screenshot, that isn't enough.

Hiding the cruft

iOS7 Safari introduced something interesting:

Real URL vs phishing URL in iOS7

…and Chrome Canary does something similar behind the flag chrome://flags/#origin-chip-in-omnibox:

Real URL vs phishing URL in Chrome Canary

Edit: I want to point out that this is an experiment. It's behind a flag in Canary, that's as experimental-yet-public as it gets. It's by no means the final design, and existing in Canary behind a flag does not mean it's certain to appear in stable releases.

For me, this is much more obvious (as long as this bug is fixed) and becomes more obvious still with extended validation certificates.

HTTPS vs HTTPS + extended validation certificates

Browsers stopped showing the username/password part of URLs because it made phishing too easy. This is a natural progression.

The death of URLs?

No, this isn't URL death. The URL is the share button of the web, and it does that better than any other platform. Linkability and shareability is key to the web, we must never lose that, and these changes do not lose that.

The URL is still accessible in iOS by tapping the URL bar, or in the Canary experiment by clicking the origin chip or hitting ⌘-L. Well-designed URLs are more aesthetically pleasing to share, so the requirement for meaningful URLs doesn't go away.

To the average user, the URL is noise. It's a mix of protocol, origin, and path. It's a terminal command, echoing it back to the user is weak UI. We should focus on the security of the URL, without harming shareability.

View this page on GitHub

Comments powered by Disqus

Jake Archibald in a garden with a black cat

Hello, I'm Jake and that's me there. The one that isn't a cat. I'm a developer of sorts.



Feel free to throw me an email, unless you're a recruiter, or someone trying to offer me 'sponsored content' for this site, in which case write your request on a piece of paper, and fling it out the window.