Rethinking URL bars as primary browser UI

This post consists of my notes on why web browser vendors show our users the URL at the top of every screen. It exists to capture the security and usability constraints that affect URL bars and examine what alternatives may also satisfy those constraints.

Why do we show URLs at the top of every page?

A URL is made up of an origin and a path. These strings are the very foundation of the Web, allowing us to seamlessly link content together.

Let’s now put on our inquisitive hat and ask ourselves: why do we show users the URL at the very top of every page? Is that the UI we would design if web browsers were invented today?

I’d say we do it for 3 main reasons (beyond the historical reason that “we’ve always done it that way”, which shouldn’t be underestimated).

We do it:

1. So users understand who they’re talking to
2. So users can know where on a site they are, and navigate by modifying the URL
3. So users can share a link to what they’re currently looking at

In this post I will unpack these one at a time, attempting to capture the underlying constraints implied by these use cases, and thus what other potential approaches could satisfy them

Reason we show URLs #1: so users understand who they’re talking to

Let’s start with a thought exercise. Off hand, can you confidently state the origin used by Bank of America?

bofa.com? bankofamerica.com? bankofamerica.bank?

Considering this question led to me to the following conclusion:

When we want to find an entity online for the first time we don’t just magically know the correct origin — we use a search engine.

We start by searching for an entity, and subconsciously trust that the top result is actually the entity we were looking for.

If we can’t reasonably assume that the top result is who we’re looking for then for all intents and purposes the battle for security is already lost.

Thus we reach our first, important conclusion of search-engine-dependence:

Our ability to understand who we’re talking to on the web is underpinned by search engines.

When you revisit the origin later

The next time we want to access the same site we just type its name into the URL bar and trust either autocomplete or returning to the original search engine will do the rest.

If we somehow end up on a site via a link and wonder who it is, we now have a look at the URL bar and attempt to recall whether the origin is the same as it was when we landed on the site originally via a search engine.

This approach is theoretically secure, but assumes and requires that our users are technical, paying full attention and have a good memory. But most of our users — the billions of people that use web browsers — are not, they are just trying to get something done online.

So who are our users?

Billions of users are coming online for the first time via mobile devices in emerging markets. Their first experience is one of a grid of logos labeled with the words “Facebook” and “WhatsApp”.

If we’re lucky these new users venture to the browser. At this point they’re suddenly presented with a distinctly confusing box containing runs of characters like “https://”, “www.”, “.co.in”. The simple world of logos and app names is gone.

To new users of the web, the URL bar is about as meaningful as this**

Many users manage to fumble through using search, and features like Safe Browsing save them from some phishing attacks, but the UI is not very user friendly.

Can we better serve our users needs to understand who they’re talking to?

Suspending implementation questions for one moment, let's consider a hypothetical question about how we could improve the UX that conveys the origin’s “content”.

When a user is on Facebook, why doesn’t the URL bar just say “Facebook”, with a small Facebook logo? Would that not more clearly help the user understand the literal “origin” of the content?

You may now reasonably think: “sure, build that. Then I’ll immediately make a fake site named Facebook with the same logo and how foolish you will look!”

Clearly we would need a way for browsers to determine the locally known brand name and logo of all sites*. Let’s call such a hypothetical system an origin-to-local-brand-mapping.

Now recall how earlier in this post we established search-engine-dependence: the fact that our ability to understand who we’re talking to on the web is already underpinned by search engines.

Therefore, I think it’s worth exploring whether we can use search engines to build such an origin-to-local-brand-mapping system.

Now it’s time to move on from helping our users understand who they’re talking to. Let’s talk about navigation.

Reason we show URLs #2: So users can know where on a site they are, and navigate by modifying the URL

Billions of users are currently in the process of coming online on mobile devices for the first time.

If you personally manually modify URLs to browse around a site and parse the parameters to determine where you are, then you are likely not in the majority of our users.

You do deserve the right to this ability, but I’d argue we should optimize for the 99%, rather than the 1% of URL-hackers.

Reason we show URLs #3: So users can share what they’re looking at

The ability to share what we’re looking at is extremely important. Sharing and navigating is at the core of the web and is fundamentally enabled by URLs and the web’s principles of Security, Linkability, Indexability, Composability and Ephemerality, collectively known as SLICE.

But let’s think for a moment of reasons #1 and #2 that we show URLs. If #1 is — at least theoretically — better served by rendering the locally known brand and we can agree that #2 shouldn’t be a top priority for the precious pixels that we have on mobile, then it makes me wonder:

Is the current UX of an editable text box persistently containing a URL the best approach to help people share what they’re looking at?

Could we instead build a persistent “share” or “get link” button? Would that work too?

My personal conclusions

• Users need a way to share a link to what they’re currently looking at, but that doesn’t necessarily need to be in the form of a text box already containing the link
• Origins are not very user-friendly, especially for users coming online for the first time on mobile
• Search engines are already implicitly trusted when it comes to web security as they tell us what the origin should be
• If we could determine the locally known brand name and logo for a subset of sites we may be able to build a more user-friendly, and hence safer, browsing experience

Given the above, I think there’s a real and exciting possibility to revolutionize browser UI.

That said, this idea is all underpinned by being able to build an origin-to-local-brand-mapping system for at least some subset of the web. Is that even remotely possible? Assuming you had full access to the knowledge of search engines, or otherwise, how would you design such a system?

Responses or Tweets (I’m @owencm) much appreciated. Let’s explore these constraints and opportunities together!

Thanks to Emily Schechter, Alex Ainslie, Alex Komoroske, Elizabeth Harwood, and the many awesome folk on Chrome’s Enamel and Fizz teams for the insightful discussions and feedback on this post.

Footnotes*

*To some extent EV certificates aimed to solve this problem, but company legal names rarely correspond to known brands. Last I checked the mint.com EV cert read “Intiuit USA Corp”. Not exactly user-friendly.

**This line of questioning also begs the question of why we ever show “www.” or “m.” in origins. Are there any cases where that meaningfully aids users in identifying that they are talking with who they mean to be talking with? They are additional confusing syntax and have a real cost. Are they delivering sufficient value to remain?