I’ve been following bug 366797, and discussions in mozilla.dev.security, with great interest, and I’ve been thinking about this for some time now. Here’s my (slightly long) attempt at a unified and consistent proposal for changing the way the location bar works for Firefox 3.
In the original design of the web, the URL was supposed to be an implementation detail. That hasn’t turned out to be the case, for better or for worse. Still, the URL bar itself has changed very little since Netscape 1. I believe there’s scope for changing the way it works to improve the user experience.
- Don’t break stuff people use
- Make the hostname stand out more to reduce spoofing
- Reduce the risk of spoofing in other ways
- Make the contents of the URL bar more understandable
- Make common operations easier
- Find a way of presenting information from EV certificates
1) Hide the scheme
The scheme (e.g. “http://”, “ftp://”) should be hidden permanently for HTTP, HTTPS, FTP and file URLs. The differences between HTTP and FTP have long since ceased to matter to the average web user. The difference between HTTP and HTTPS is, of course, important, but we have other UI to indicate that. (And if it sucks, we need to fix it.) Eliminating the scheme also means we could do things like show some HTTPS connections as if they were HTTP – e.g. for self-signed certificates, which people just use when they want eavesdropping protection – without our UI being inconsistent. This is an improvement on the current behaviour, which is just to throw an error.
FTP could have a special favicon, as could file://.
2) Hide username and password
If present. Usernames and passwords over unencrypted channels, embedded in GET requests (which are cached) and links, are fundamentally insecure and their most common use is for spoofing (although we already have some protection against that). If people type them in, we’ll use them to try and log in, but we won’t show them in the location bar.
Yes, this makes them less useful – if you make a typo, you need to retype everything. I don’t think this is a bad trade-off.
3) Highlight hostname
Take either the entire hostname or the Effective TLD + 1 and highlight it in a button-like style. So either:
(We need to be careful with bold; with some fonts, it reduces the difference between letters such as l and i, which is bad from a spoofing perspective. Further research required.) There is some space (perhaps half an em) either side of the button.
Clicking the hostname “button” takes you back to the root of the site – and this would affect which of these two options we actually choose. Consider george.blogspot.com/archive/… – do we want to go back to george.blogspot.com or blogspot.com? Probably the former. But then that would mean that microsoft.com.foo.bar.baz.evil.com would be all on the button, including the microsoft.com part. Difficult.
For file URLs, you’d get:
on Windows, and
on Unix. Yes, these two are inconsistent with respect to the placement of the initial slash. I’m not sure how to deal with that. I think a prefix like
would be horrible, particularly on Unix.
Example of what I mean, so far:
4) Display EV business name and country
For HTTPS connections with EV certificates, replace the hostname with the O (Organisation) and C (Country) fields from the certificate. So:
Replacing the hostname rather than just adding to it means there’s a really big difference between the real site and an attempted spoof, which would have a domain name in that space rather than a textual name.
We need to include information about the country (there can be businesses of the same name in different jurisdictions), and the question is, do we use letters (US, UK, CM) or a flag? A flag is safe because we are actually talking about countries, not languages, and it might be more recognisable and differentiable. IE and Opera are using letters.
Example (ignore the unlikelihood of the URL):
The flag is next to where the favicon should be, which raises a risk of confusing of spoofing, but leads on to:
5) Remove the favicon from the URL bar entirely
We would keep it on tabs, of course. I realise this is controversial; here’s my rationale. Favicons in the URL bar are dangerous, because they represent the website having some control over what’s in the chrome. This is why we turned off website access to the status bar. We already have spoof websites having a little lock as their favicon, to try and persuade users they are over SSL. Let’s put the websites back into the content area box.
This would probably imply making the tab bar always visible – i.e. setting browser.tabs.autoHide to false – so that the favicon was always visible. I think this is good because it improves the discoverability of tabs and stops the content area jumping around when you go from one to two tabs or vice versa. I don’t know if the default setting of this preference is a controversial issue.
I believe that the only other function of the page-proxy-icon (where the favicon appears) is to be draggable to create e.g. bookmarks toolbar entries; that role could be taken over by the domain name button, perhaps. I admit there’s further thinking to do here.
6) Focus turns bar back to a text box
On focus, move back towards being a text box. People have important behaviours to do with URL bar hand-editing that we don’t want to break. Therefore, clicking anywhere in the URL bar (except on the domain button) or pressing Ctrl-L, focusses the URL bar and makes the following changes.
The 3D-ness of the domain button becomes faded and 2-D – so the separation is still visible, but the URL now looks flat. The URL bar acts as much like a single text box as possible. The spaces between different parts remain (to keep the text stable; the text must absolutely not move on focus, otherwise the caret appears somewhere different from where you clicked) but if you select and copy, the spaces don’t appear.
7) Change selection behaviour
People edit individual URL components. So, we should make it easier to select individual components. Like in a word-processor, a single-click focusses, a double-click selects a component (“word”) – hostname, path segment, URL parameter key+value or fragment identifier, and a triple-click selects the entire URL (equivalent to “select line”).
Again, I don’t know if this is a can of worms – I suspect URL bar selection behaviour has been discussed before.
8) Analyse font choice carefully
If we are emboldening some parts of the URL (e.g. the domain), we need to be very careful about choosing fonts where the bold version provides enough differentiation between visually close letters like i and l. For example, the font that my copy of Firefox uses for my example bold URLs (see mockups) has very bad i/l differentiation. Perhaps we might consider a fixed-width font in the URL bar? This would also make selection easier; at the moment, putting the caret in the right place in million.com is nearly impossible for those with less than perfect motor skills, and tricky even for those with.
Not all of these suggestions are interrelated; some could be removed without affecting others. This is not supposed to be a tightly-bound take-it-or-leave-it package.
Please comment on this proposal in the newsgroup mozilla.dev.apps.firefox.