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.
Goals
- 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
Optional Goal
- Find a way of presenting information from EV certificates
Suggested Changes
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:
www. /foo/bar/baz?q=x
Or maybe
/foo/bar/baz?q=x
(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:
/Program Files/Firefox/
on Windows, and
home/gerv/test/
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
/home/gerv/test
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:
/foo/bar/baz?q=x
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.
Example:
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.
You want to really make this a good standard/implementation? – don’t just limit it to firefox – get SeaMonkey and Camino to sign up to it too.
I like most of the proposal.
My biggest fear is with replacing the host with business name and country. Most companies own different hosts, in completely different domain names. I think there can be cases where it matters to the user to know which host they are connected to, not just which company.
My second fear is with not displaying the scheme. Suppose I type in bugzilla.osafoundation.org. I know it should try http first, which will redirect it to https. That host will not have an EV cert, and might in fact have self signed cert (but it is fine, I know about that). I do want to be sure that I am using SSL, though, to protect my username and password.
Another improvement which is in one extension is to make the path components in the URL be clickable. That way you can easily navigate upwards in the website hierarchy, without needing to type in the URLbar.
I also have a question about the port number. Currently mozilla security model considers scheme + host + port to identify a website. Theoretically you can have a different entity controlling example.com:80 and example.com:90.
What about copying Nautilus’ behaviour? (If you use Gnome, you can check it out by putting Nautilus in browser mode). Here’s an example:
Regular lookage (those are buttons you can click on): http://www.lynucs.org/index.php?screen_type=1&screen_id=52093475445c1e3e3d99fc&m=screen
In text mode (you can get here by pressing Control-L or clicking on the button to the left): http://www.lynucs.org/index.php?screen_type=1&screen_id=105312691545bf7751173ef&m=screen
Woops, I just realised in the second example, it’s not Nautilus, but the File Chooser dialog. It uses the same widgets that Nautilus uses though.
Looks like a great idea; it kind of does the same thing that has now been implemented in Vista’s explorer windows. Cool stuff! Of course, it would be easy to put a switch somewhere, so that the more technical people can turn this feature off. But, even as ‘technical guy’ myself I’d say this could be great if implemented correctly :)
I strongly agree with every word you say here :-)
Indeed, URL bar selection has been discussed for example in bug 190615:
make stop_at_punctuation=true the default on unix (double-clicking shouldn’t select punctuation)
https://bugzilla.mozilla.org/show_bug.cgi?id=190615
I have a couple use cases that I don’t see immediately covered:
1. Will every Google service be showing “(flag) Google, Inc”? While good for security, it’d be harder to distinguish the services without knowing the service icon (if the service has one).
2. I’m on a site (e.g. gmail) that offers both http and https but defaults to http. How do I switch to https?
3. How does copying/pasting a URL work?
Comments:
I’m skeptical on much utility the button provides versus the confusion it will cause (mistyped url correction, anyone?). The adoption of the ‘click the site logo to go to the site root’ pattern usually covers the need to get to the root more intelligently than a location bar button would.
I appreciate the thought that went into this and I definitely support the pure security changes (2,4,5,8). I’m unsure about some interaction changes (1,7) and against the button related stuff (3,6).
As a first stab, I would suggest a fast (roughly 200ms) animated transition from a url to the cert info of 5. Hover reverses animation and shows cert info, focus instantly transitions back to text.
Remember to bear in mind the story of the man who got convicted for visiting the root address of a website: http://it.slashdot.org/article.pl?sid=05/10/07/1532241&tid=172 (I kid ye not)
hmmm, the most important thing is obviously domain highlighting, but buttons would still be nice.
As Karl G notes, the main problem with buttons is how they interfere with click-to-edit. Especially if you then add buttons to the subpaths, as Alan Trick notes Nautilus does.
What if the URL bar were divided into a top part (click-to-edit) and a highlighted bottom part (click-to-load). The hotspots could be quite big too, since there’s nothing above or below the text in the url bar except space. Click-to-edit should be much bigger, because it’s the less ‘dangerous’ action.
Here’s a mockup: http://voracity.org/images/testurlbar2.png (My artistic skills aren’t the best, but you get the idea.)
It all looks good, more research needed obviously, and user testing. But The presense or absence of #6 is a dealbreaker obviously. Without #6 this is right up there with the JS/Error Console and View Source things. Anyone recommending these go away is crazy, and should be isolated for their own protection.
And when I say dealbreaker, I mean as in I shall take my planned implementation of Mozilla on 500 enterprise grade servers ELSEWHERE, GOOD SIR. ;)
I worry that if the schemes become hidden from view and they start to become one of those invisible things of the internet which no regular user ever sees, then we’ll have a lot of people writing comments on blogs with dud links in them, after forgetting to put the http:// prefix on.
Gerv,
Totally excellent ideas.
My only concern would be that you are using buttons when URLs are usually blue underlined text, but I guess if it is part of the chrome it make sense.
I think animation could help you a lot, as you mouse over the button fades and the text is editable. Mouse-out of the text box and the button fades back.
How about using the space above the URL text box? The http://www.ebay.com could be shown above the button. Or the button and flag could be shown above the http://www.ebay.com and the text box blue border encompasses both bits of info.
The URL text box already holds the RSS icon, the Fav icon, and now this new ‘icon’ or button. Why not change the shape of this URL text box to show this ‘meta’ information about the web page better? Make a separation between [chrome] & [URL + meta] and [web page]. At the moment chrome, URL + web page meta (RSS feeds, Fav Icon, SSL, Certificate info) are intermingled into the chrome.
Cheers,
monk.e.boy
I’m sure this is done for the advantage of normal users, but I sincerely hope this is a feature that, if decided to be implemented, can be turned off.
Cutesy flags for a company do nothing to put trust to a site in my opinion. Especially not if it is a company with presence in various countries and using centralised certificates, thus causing a non-match between flag of the parent for a TLD you entered.
Also, replacing the text with a company is totally distracting from the URL that’s currently in the location bar, which is more confusing in my opinion than seeing the domain name. You loose the overview of the matching domain. Of course, for IDN domains it might make more sense, but then the point below comes into play.
Using bold might be cute for latin-based/derived languages, it totally messes up fonts for Asian languages and possibly others due to strokes becoming thicker and in some cases omitted to preserve the form. This is especially problematic at small point sizes, and even moreso when not working with fonts with proper hinting. General UI design guidelines for using hanzi/kanji state that emphasis should almost never be accomplished with bold or italic, especially since a user can change their system fonts to whatever she or he wants to.
Just to add what I do like:
the domain part getting a pastel background is something that is a good addition, nice and not annoying.
It’s important to me that I can switch between http and https sites easily. Please ensure that any change makes it easy to do this.
Sounds a lot like Locationbar2:
https://addons.mozilla.org/firefox/4014/
Could I ask that, if at all possible, people post their comments and continue discussions in the newsgroup mozilla.dev.apps.firefox (Google Group)? It helps keep everything in one place. I’ll post this message there so you can all comment further on it.
Several people have mentioned making all the path components clickable buttons, instead of just the domain. I’m wary of such an approach, for the following reasons:
Heikki: Can you give an example of where the user would care about which host they were connected to, as long as it were one owned by the correct company? I know I certainly don’t care if my Google search results are served by http://www.l.google.com or http://www.q.google.com.
I’m not completely sure what to do about the port number. I agree that it’s theoretically possible that two entirely different entities could control port 80 and port 90; but it is certainly unusual.
Karl: Surely you distinguish between Google services by, er, looking at the content area? :-) Copy/pasting should work as now; when you focus the URL bar, it turns back to a text box.
voracity: I’m not sure how we could implement your proposal without terminally confusing people. While it’s nice to be able to have your cake and eat it, I’m not sure we can in this case.
Cyrris: Maybe. But lots of link detection algorithms don’t require a scheme anyway. I don’t think it’s a big concern in the grand scheme of things.
J. Ruigrok van der Werven: The flags are not supposed to inspire trust; they are supposed to part of the representation of the underlying reality that the website identity is more strongly known than with normal certificates (and that the company concerned has the name displayed, and lives in that country). Which flag they get depends on where they applied for the cert; if they feel having all the certs have the same flag will cause confusion, they can apply for certs in different countries.
I agree that the method of domain emphasis may have to vary based on locale. Which is not ideal. We may just drop the bold entirely, and rely on the button surround to pick out the name. How do you do emphasis in Kanji? Underlining?
MaierMan: Did you check the bug link I gave? :-) It’s all about Locationbar2.
Locationbar2 is indeed a prototype for this.
But what I don’t like about Locationbar2, is the green arrow that was added in version 0.7, which is your point 7 (selection-behavior). you can see it in the image on http://en.design-noir.de/mozilla/locationbar2/
I liked the original version (0.3 ???) where only the hostname was separated form the rest of the url (and set in bold), and where the original url appeared when you hovered over the locationbar. I think the extension lost it when they started to mess with the different segments, adding spaces, icons, colors, etc … I don’t recognize the locationbar anymore.
nice idea but i think for advanced users.. this would suck. I personally would not like it .. The whole url button idea, and would defiantly want to see the protocol used.