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.

The blog version of this proposal takes advantage of HTML formatting and
has some crude mockups, so might be easier to read:
http://weblogs.mozillazine.org/gerv/archives/2007/02/location_bar_pro...

However, please put all comments in this newsgroup.

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. [EXAMPLE.COM] /foo/bar/baz?q=x

Or maybe

[www.EXAMPLE.COM] /foo/bar/baz?q=x

where capital letters indicate some sort of styling such as bold. (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:

[C:] /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

[My Computer] /home/gerv/test

would be horrible, particularly on Unix.

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:

[* Paypal, Inc.] /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.

The * represents a flag. 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.

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.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.

Gerv

On Feb 15, 12:19 pm, Gervase Markham <g...@mozilla.org> wrote:

I agree that the hostname should be the primary focus, but why limit
the "button" aspect to just the root? Vista has an interesting take on
path/breadcrumbs [1] where you can click individual components to jump
to that location.

[[www.EXAMPLE.COM]] / [foo] / [bar] / [baz]?q=x

Clicking www.EXAMPLE.COM takes you to http://www.example.com/
Clicking on foo takes you to http://www.example.com/foo/
Clicking on baz takes you to http://www.example.com/foo/bar/baz

Another feature that Vista provides is the ability to switch to an
ancestor's sibling [2] of the current location. It's slightly
different for a file explorer where you know exactly what's available,
but the possible choices would be populated from history (and links on
the current page.)

[[weblogs.mozillazine.org]] [/] [gerv] [/] [archives] [/] [2007] [/]
[02] [/] [location_bar_proposal.html]

Clicking on the rightmost [/] could show "perspective.html".
Clicking the leftmost [/] could show "asa", "roadmap", etc.

The examples I've given in text and from Vista probably aren't the
best UI solutions for these features. Some simple modifications for
the web could be to only show the "button" if the user has previously
visited that non-root-ancestor.

The main idea is letting the user easily jump to related pages from
the current URL.

[1] http://www.winsupersite.com/images/reviews/winvista_rtm_5_32.jpg
[2] http://www.winsupersite.com/images/reviews/winvista_rtm_5_33.jpg

--
Ed

Gerv,

I have been using the Locationbar^2 extension, which appears to be
tracking bug 366797. Here's some feedback based on using it and from
your proposal:

* I agree with all of your stated goals, except the "Make common
operations easier" should be optional IMO. I believe typical web users
do very little operations on the URL. The rest of your goals are
important to me as well and will benefit users.

* After installing the extension, it was weird to see the URL address
change from the familiar plaintext string to the slightly-formatted
style. It didn't take long before I was quite comfortable with it and I
have come to use it when scanning URLs.

* I do not believe the button-style is required and I feel it creates
too much "noise" in the URL bar.

* I know that Linux (and now Vista) use the button metaphor when
browsing files and folders. That might make sense for situations where
jumping between folders is the typical action, but I don't believe that
is the typical action for URLs. Navigation is more commonly done through
links on the page not in the URL bar.

Some of your other points are good to discuss, but are less critical to
the stated goals. Displaying EV business name and country is probably
too much for me, but I'd be fine with dropping the favicon. Special
selection is nice, but not critical and may be a pain to get right.

Through my use of various versions of the Locationbar extension, I'd say
my ranked preferred styles are:

1. Format URL (hide scheme + highlight hostname), except when URL bar
has focus or on mouseover. The mouseover condition makes it easy to
click into the URL and start editing. (version 0.5 I think)

2. Format URL (hide scheme + highlight hostname), except when URL bar
has focus. The hostname is a link that goes to the root of the site. The
link approach minimizes the visual clutter. (version 0.6 I think)

Any approach with buttons, as you propose or as seen in Locationbar
0.7+), just adds too much clutter for too little payoff.

I guess I should also say that there should be an option to revert to
the current style as well.

Thanks,
Mark

[...]

I'm not so sure of that. It is true that
http://ftp.mozilla.org/pub/mozilla.org/ and
ftp://ftp.mozilla.org/pub/mozilla.org/ (with anonymous FTP) access exactly the
same folder on the same machine, but that is not true in all cases: for
instance, my user site is either http://users.skynet.be/antoine.mechelynck/
(read-only, and when giving a directory name you get the index.htm if it
exists, otherwise an error page) or ftp://users.skynet.be/ (read-write, with
username and password, no "username" directory, and when giving a directory
name I get a directory listing).

In addition, I like the possibility of copying the URI from the Location Bar
to the clipboard in order to access the same page in a different browser (be
it another Mozilla browser or a non-Mozilla browser such as IE or Konqueror),
or to paste the URI in an email.

[...]

Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
36. You miss more than five meals a week downloading the latest games from
     Apogee.

For file:// only if it's a directory listening, as a document can have
its own icon.

That should already be the case.

Why?

I think that goes too far away from the URL semantics. Domains are still
quite important to users. Even though you can type "paypal inc." into
the location bar for getting to paypal.com, that might fail in other cases.

Regards, Dao

Gervase Markham, 15-02-2007 15:19:

It's a great point.

Another one.

It's superfluous and usable only when don't breaking anything else.

I would like it. As another user mentioned, the content for ftp/http
might be different. I would like to quickly know where I am (from your
fully proposal it's very hard).
Well... maybe both http and ftp are directory listings and only the
content changes.

 > [snip]

The bold issue is something we should pay a lot of attention. Colors
alone are not a good thing also.

That's confusing. including microsoft.com on the button is agains one of
the main goals, it will make spoofing easier.
But probably the user would want to go to the subdomain, not the main
one. Maybe changing something on mouseover (since the user only will
mouseover when he's going to click).

"My Computer" is windows-ish, argh. I wouldn't complain about "root
filesystem" (it's what most file managers use).

I don't think it's really needed by default. A "Micros Soft Cooporation"
on Jamaica could confuse someone, anyway.

Would be good to use the area of the favicon for another useful info and
they really allow spoofing.

I don't think you loose too much setting it to false.

We could have a icon representing a web-page, another one for a secure
web-page, another for remote files, another for local files (maybe one
for each protocol or to stick with a default one).

Please, I wanna my protocol.
I complained about it before testing the extension and I've seen you saw
it on mouseover. Is every time worse to get it and your way it's impossible.
So we would loose the ability to copy the whole URL, including the protocol.

I understand the issue with moving the focus, but we have another ways
of treating it.
Well... the protocol could be very, very, very transparent, but visible,
for instance. It wouldn't be confused with the URL but the change to a
plain view would sucks less.

I'm strongly against to not showing the protocol while editing the URL.
The user could want to copy'n'past the URL to the friend and that
wouldn't work! (assuming some servers and their ftp configuration, for
instance)

How do you select the hostname clicking it while it's a button that will
execute some action when clicked :D? (Changing from "clearly a button"
to "is it a button?" on mouseover is bad)

Well... I liked a lot this way. It would be easy to still working the
way the people do today, if desired.
Mark Finkle made me discover today I'm not an average user (the kind of
user never uses the mouse to edit URLs, so most of the things here don't
apply to me, anyway), but we shouldn't break features that work for a
lot of people, even if it's only 3 or 5%. Even if someone almost never
do something while using the browser, but the UI looks like a ordinary
edit box, it should do what is expected from it.
For instance:
  - the user should be able to click and drag to select a portion of the
URL, instead of click and release and click again later and drag
  - the user should be able to select a part of the hostname to modify
(he couldn't achieve this if it's linkified)

And we arrived where?
Correct me if wrong, but from your proposal, if I typed
aVeryLongLongLongImenseUrl.aGreatDomain.com with a little mistake I
would have to type it all over again (and I could make another mistake).

The user should be able to choose the font he wants.
At Linux, for instance, with gtk2, every user expects the gtk2 programs
to use their gtk2 fonts on the interface, except he stated otherwise.
Why should FX to be different?
So fixed-width/monospace font looks like a good option (OK, it looks not
so pretty, but...).

Neither are my comments ;).
Don't take me much serious.

Let me quote the related part our IRC conversation, so that everybody
knows about it:

<asrail> Clickin on a token and selecting it is nice, but that shouldn't
broke click and drag selection, for instance
<dao> the idea is that you don't have to drag that often
<asrail> Should the user to receive a penalty of two clicks for this?
<asrail> Something we should remember is that the our average user does
not read pmo, neither our wiki or look at bugzilla
<asrail> A good browser for us might to be a geeky one for them
<dao> he'll just notice when clicking
<dao> and the penalty is worthwhile when it saves clicks for more other
cases

I don't think we can evolve the location bar as aggressively as Gerv
proposed or as I've implemented it and still have 100% parity with a
legacy textbox. We will have to make trade-offs. And we shouldn't be
scared of 3% complaining about an extra click if 30% applaud.

In article <u9ydnR5N2tHTr0jYnZ2dnUVZ_vein...@mozilla.org>,
Mark Finkle  <mark.fin...@gmail.com> wrote:

I think I am going to have to second this; Reading the posts, I thought
it sounded like a horrible idea but, about five minutes after installing
0.7.2 I was already quite liking it [*].

It will take a bit more experimentation as I have an undiagnosed issue with
Firefox 2 not always showing a site as secure [I think it is some combination
of Frames, Cache, bfcache and possibly caching secure pages] that I will need
to check doesn't occur in Firefox 3.

        John

[*] After all it is very similar to the breadcrumbs that I put on our sites:

    University home > News > News from around the Uni. > The past fortnight's news from .

    www.bris.ac.uk > news > university > recent.html
--
John P Baker

Dao Gottwald schrieb:

Maybe because
[My Computer] /mnt/srv/software/
would be on a server elsewhere and not actually my computer here on my
system?
Additionally, it takes away space and is of no practical use.

The root of the file system is just "/" in unix-ish systems, and I don't
think inventing words for that makes a lot of use. "file://" is as good
or bad as "My computer".

Robert Kaiser