Location Bar Proposal

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

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
0
Gervase
2/15/2007 6:19:34 PM
mozilla.dev.apps.firefox 3660 articles. 0 followers. Post Follow

209 Replies
1618 Views

Similar Articles

[PageSpeed] 28
Get it on Google Play
Get it on Apple App Store

On Feb 15, 12:19 pm, Gervase Markham <g...@mozilla.org> wrote:
> 3) Highlight hostname
> Clicking the hostname "button" takes you back to the root of the site -

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


> 7) Change selection behaviour
> People edit individual URL components. So, we should make it easier to
> select individual components.

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

0
Mardak
2/16/2007 3:57:31 AM
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

Gervase Markham wrote:
> 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
> 
> 2) Hide username and password
> 
> 3) Highlight hostname
> 
> 4) Display EV business name and country
> 
> 5) Remove the favicon from the URL bar entirely
> 
> 6) Focus turns bar back to a text box
> 
> 7) Change selection behaviour
> 
> 8) Analyse font choice carefully
> 
0
Mark
2/16/2007 4:25:47 AM
Gervase Markham wrote:
[...]
> - Don't break stuff people use
[...]
> 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 

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.

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



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.
0
Tony
2/16/2007 4:39:58 AM
> FTP could have a special favicon, as could file://.

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

> 2) Hide username and password

That should already be the case.

> I think a prefix like
> 
> [My Computer] /home/gerv/test
> 
> would be horrible, particularly on Unix.

Why?

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

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
0
Dao
2/16/2007 5:16:55 AM
Gervase Markham, 15-02-2007 15:19:
> 
> Goals:
> 
> - Don't break stuff people use

It's a great point.

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

Another one.

> - Make common operations easier

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

> 
> 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.
> [snip]
> FTP could have a special favicon, as could file://.

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

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

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

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

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

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

> 4) Display EV business name and country
> [snip]

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

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

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

> 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 don't think you loose too much setting it to false.

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

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

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

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)


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

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)

> Again, I don't know if this is a can of worms - I suspect URL bar 
> selection behaviour has been discussed before.

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

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

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

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

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

0
Asrail
2/16/2007 6:34:34 AM
Asrail wrote:
> 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)

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.
0
Dao
2/16/2007 1:09:06 PM
In article <u9ydnR5N2tHTr0jYnZ2dnUVZ_veinZ2d@mozilla.org>,
Mark Finkle  <mark.finkle@gmail.com> wrote:
>* 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 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
0
ccjpb
2/16/2007 2:34:56 PM
Dao Gottwald schrieb:
>> I think a prefix like
>>
>> [My Computer] /home/gerv/test
>>
>> would be horrible, particularly on Unix.
> 
> Why?

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
0
Robert
2/16/2007 2:53:23 PM
On 2007-02-15, Gervase Markham <gerv@mozilla.org> wrote:
[snip]
> 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.) 

That UI though, whether it sucks or not, isn't something that people
usually use to distinguish between different sites.  I guess that could be
changed, but it seems like you'd have to educate the user in weird ways
that would actually take away from efforts to make people understand
security.

Take your own host for example - I could have "www.gerv.net" in the URL
bar, and either be at your webpage, or at a blackcatnetworks page, or
being given a login prompt for FTP.  If you take that away from the URL
bar, you are effectively going to force everyone to have 1 service per
hostname, or to ensure that FTP, HTTP and HTTPS are all pointing to the
same content.

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

What happens when there is a host called wibble.example.com, and it runs
an intranet on http and a webmail service on https, with a self-signed
cert.  The UI would be consistent (indeed, identical), but the content
would be completely different.

I don't imagine this matters in terms of Paypal, Ebay, as they will have
everything on different host names.  But in smaller settings, there may
well be 1 host name with a bunch of different services, and they would be
confusing and spoofable.  For example, I could set up some HTML pages on
an FTP server on a host which was running the organisation's intranet, and
make it look like I'd replaced the intranet with my web pages.

[snip]
> [* 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.

But it could mean for a radically different hostname, you have a similar
textual name.  If someone gets an EV certificate for Manybank Inc, they
can host their site at https://kjasdffdsfjewf.evil.com and the URL bar
will be almost identical to the genuine site of Anybank Inc.

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

I guess that would have to be examined, but I think I'd be more easily
able to recognise and distinguish countries by letters than by a 16-pixel
or so wide version of a flag.  I guess for this purpose I only really need
to recognise my own country flag and the flag of a country I'm likely to
be doing a lot of business with, and recognise any other flag as
"something else".

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

How would this fit together with replacing the hostname with the
certificate name?  Would it switch back to showing the hostname when
focused?  Or would we be happy to completely break the stuff you discuss
here for sites with EV?

-- 
Michael
0
Michael
2/16/2007 2:58:25 PM
Robert Kaiser wrote:
> Maybe because
> [My Computer] /mnt/srv/software/
> would be on a server elsewhere and not actually my computer here on my 
> system?

There's nothing wrong with that. The starting point is still your file 
system ("/" alias "my computer").

> "file://" is as good or bad as "My computer".

For geeks, yes.
0
Dao
2/16/2007 3:08:12 PM
Gervase Markham wrote:
> 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_proposal.html

Several people commented on the blog version; here's my response to the
first set of comments, so hopefully they can continue the discussion here.

Several people, both on the blog and here, have mentioned making all the 
path components clickable buttons, instead of just the domain. This is a 
common question, so I've posted my response as a separate message.

Heikki said:
> 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.

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 www.l.google.com or www.q.google.com.

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

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 said:
> 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).

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 suggested:
> Why can't you divide the URL bar, like this? 
> http://voracity.org/images/testurlbar2.png

I'm not sure how we could implement this 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.

J. Ruigrok van der Werven said:
> 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.

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.

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

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?

Gerv
0
Gervase
2/16/2007 3:32:36 PM
Gervase Markham wrote:
> 3) Highlight hostname
> 
> Take either the entire hostname or the Effective TLD + 1 and highlight 
> it in a button-like style. So either:

Several people, both on the blog and here in the newsgroup, have 
mentioned making all the path components clickable buttons, instead of 
just the domain. This is a fairly common suggestion, and I almost 
addressed it in the original post. I'm doing so now, in a new thread part.

I'm wary of such an approach, for the following reasons:

* You don't know if moving up directories will actually produce a
   meaningful page. On good websites it does, but not all websites are
   good. More research may be needed, but adding a load of buttons to the
   interface which take people to a 404 or a 500 probably isn't good UI
   design.

* If all the path components are buttoned, then there's nowhere you can
   click to focus the URL bar and turn it into a text box.

* One reason this works well in e.g. file managers is that they know all
   the possible options for a path component, and can present them in a
   dropdown. We don't in most cases.

Gerv
0
Gervase
2/16/2007 3:32:39 PM
Mardak wrote:
> On Feb 15, 12:19 pm, Gervase Markham <g...@mozilla.org> wrote:
>> 3) Highlight hostname
>> Clicking the hostname "button" takes you back to the root of the site -
> 
> I agree that the hostname should be the primary focus, but why limit
> the "button" aspect to just the root? 

Good question. I've posted a separate message in this thread addressing 
this exact issue.

>> 7) Change selection behaviour
>> People edit individual URL components. So, we should make it easier to
>> select individual components.
> 
> 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.)

But how would you avoid giving the impression that these are the only 
choices available?

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

I'm not sure that users would easily understand why sometimes they got a 
button and sometimes they didn't.

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

Isn't that what in-page navigation is supposed to do? :-)

Gerv
0
Gervase
2/16/2007 3:34:11 PM
Gervase Markham schrieb:
> - Make common operations easier

A common operation for me is to edit the domain name and look at the 
same URL on a different domain, as I'm maintaining a bunch of sites 
using the same system and using the same path/querystring parts of their 
URLs on different domains.

It's clear such a restructuring can't (easily) satisfy everyone, but I'd 
be happy to e.g. be able to correct a mistyped URL fast, even if I 
mistyped the domain part. And, from your proposal, I couldn't yet find 
out how to get to an empty location bar in which I can type a new URL, 
or search query.

Ah, yes, that leads me to the next idea/problem: I love typing a bunch 
of words in the location bar and have SeaMonkey automatically search 
Google (my default search engine) for those, not needing a special 
"search" textbox in the toolbar. It's not that hard to detect if what 
the user entered is a URL or not :)

I'd hope that we could get to some stage where we have one place in the 
UI where a user would enter "what he wants to see/find" and we would 
perform the right action based on circumstances. That action could be 
"request the entered URL", "search the web for this expression" or even 
"search the currently viewed page for this expression". I believe that 
could be done from one central place in the UI, the location bar being 
the obvious candidate for that in my eyes. Maybe the bar would need to 
visibly enter different modes of operation or so for that, but I think 
it should be tried, as it really would ease user interaction with the 
browser, IMO.

That said, icons are nice for many things, but please take into account 
that there are people who have a hard time seeing different colors, 
seeing details in small icons or even seeing graphics at all (and even 
people with full eyesight might need to deal with low-color displays or 
small resolutions). We need to provide meaningful text for those. A 
yellow color of the bar or a small lock icon in some unrelated part of 
UI are really hard to see in some cases.

That and the difference between HTTP and FTP in some common cases makes 
me think instead of removing the protocol, we should just display it 
differently, e.g. replace "http://" with something that says "Web:" or 
so, "https://" could get "Web (secure):", "ftp://" could be converted to 
"FTP:" or "Remote file:", then "file://" could be "Local file:" - in 
this case, we could even leave favicons in (and use some nice favicons 
for ftp/file), as "[file icon] Local file: /home/robert/" is far enough 
from a spoofed "[file icon] Web: fakehome.com /robert/" or such.

Along with all that, a new vision begins to form in my mind: this could 
allow simple path editing as in your proposal, and for many use cases 
that would work fine.
With some user action (edit icon or such?) to start editing the full 
URL, we could switch the bar into edit mode, displaying a dropdown with 
a current value of "URL:" instead of the protocol identifier string I 
proposed in the last paragraph, and the full URL for simple editing as 
in the current location bar. The dropdown would be changeable to "Search 
the Web" or "Find in page", each of which would clear the space for 
editing and allow the user to either enter a web search or do a FAYT 
operation on the current page. Of course, any current way of invocation 
of those functions currently would switch into the respective edit mode 
(Ctrl+F, Ctrl+L, etc.) - and ESC or small cancel icon in the bar would 
leave edit/search mode and go back to normal display.

I think there's clearly some room for improvement of the location bar, 
and that open discussion might lead us to a really powerful widget after 
all :)

Robert Kaiser
0
Robert
2/16/2007 3:36:03 PM
Mark Finkle wrote:
  > * 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. 

I'd be interested if anyone has any hard figures here. My gut tells me 
that clearing out the URL and replacing it with something else would be 
pretty common, but most other operations would be advanced.

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

You feel the bolding is sufficient? The problem with bolding is that it 
doesn't work well for some scripts (e.g. Chinese).

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

Changing the styling on mouseover might mean we couldn't do the 
clickable button. Unless it only changed on mouseover of the rest of the 
URL.

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

I agree for the non-domain-name buttons, FWIW.

Gerv
0
Gervase
2/16/2007 3:37:02 PM
Tony Mechelynck wrote:
> 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).

I'm not arguing that there is no difference between a machine accessed 
over HTTP and FTP; I'm arguing that a web user doesn't really care which 
one he's using when he clicks a link to go there. The readable vs. 
writable thing doesn't matter for a browser, which doesn't offer FTP 
writing facilities.

The differences in behaviour (WRT, for example, index.html) are, I 
suggest, understood by those who understand them, and not really noticed 
by those who don't.

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

Absolutely. We wouldn't want to break that. See point 6.

Gerv
0
Gervase
2/16/2007 3:40:26 PM
Dao Gottwald wrote:
>> FTP could have a special favicon, as could file://.
> 
> For file:// only if it's a directory listening, as a document can have 
> its own icon.

Hmm. Yes, we might well be able to do that.

>> 2) Hide username and password
> 
> That should already be the case.

Do we do this already? Cool.

>> I think a prefix like
>>
>> [My Computer] /home/gerv/test
>>
>> would be horrible, particularly on Unix.
> 
> Why?

"My Computer" or similar words are such a Windows-ism. They certainly 
make me recoil in horror. I might buy "Root", but that might be a bit 
techie.

>> 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.
> 
> I think that goes too far away from the URL semantics. Domains are still 
> quite important to users. 

That's a very big generalisation. Domains are important in the sense 
that you want to be able to type one in, and they are important for 
knowing where you are - but the idea of EV is that it provides a more 
sure way of telling where you are. After all, anyone can register 
www.paypal-payments.com, but the idea is that no-one apart from Paypal, 
Inc. in the US can get an EV cert saying Paypal, Inc. (US).

> Even though you can type "paypal inc." into 
> the location bar for getting to paypal.com, that might fail in other cases.

I'm not suggesting we do anything extra to enable this sort of thing.

Gerv
0
Gervase
2/16/2007 3:46:52 PM
Asrail wrote:
> I don't think it's really needed by default. A "Micros Soft Cooporation" 
> on Jamaica could confuse someone, anyway.

No more, and hopefully a lot less, than www.micros0ft.com.

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

http://wwwnew.towson.edu/ows/lose_lose.htm :-)

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

What, where the favicon now is? I'm not sure this icon would add much 
value. Those protocols that don't provide a favicon can have a standard 
icon in the same place (on the tabs), but I don't see much value in an 
icon telling you "this is a web page". And of course we have other UI to 
tell you "this is a secure web page".

>> 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.
> 
> Please, I wanna my protocol.

Why? Just so you can copy it, or for some other reason also?

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

Hmm. It is going to be hard to square the circle of "hide some stuff", 
"allow copying of everything" and "don't make stuff move when you focus 
the URL bar"...

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

Good point.

>> Again, I don't know if this is a can of worms - I suspect URL bar 
>> selection behaviour has been discussed before.
> 
> 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).

No; once the URL bar is focussed, you can edit the domain name.

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

Because perhaps, for example, the default GTK font produces a security 
risk by not differentiating enough between certain characters? Or 
perhaps it doesn't have glyphs for certain characters?

Gerv
0
Gervase
2/16/2007 3:55:32 PM
Gervase Markham wrote:
>> For file:// only if it's a directory listening, as a document can have 
>> its own icon.
> 
> Hmm. Yes, we might well be able to do that.

Definitely, since directory listing is already a special case anyway.

> That's a very big generalisation. Domains are important in the sense 
> that you want to be able to type one in, and they are important for 
> knowing where you are - but the idea of EV is that it provides a more 
> sure way of telling where you are. After all, anyone can register 
> www.paypal-payments.com, but the idea is that no-one apart from Paypal, 
> Inc. in the US can get an EV cert saying Paypal, Inc. (US).

I got your point about security.

>> Even though you can type "paypal inc." into the location bar for 
>> getting to paypal.com, that might fail in other cases.
> 
> I'm not suggesting we do anything extra to enable this sort of thing.

What I meant is, if we occasionally replace the domain, a user could 
think that the EV business name is an equivalent, which it isn't.
0
Dao
2/16/2007 4:00:43 PM
Michael Lefevre wrote:
> Take your own host for example - I could have "www.gerv.net" in the URL
> bar, and either be at your webpage, or at a blackcatnetworks page, or
> being given a login prompt for FTP.  If you take that away from the URL
> bar, you are effectively going to force everyone to have 1 service per
> hostname, or to ensure that FTP, HTTP and HTTPS are all pointing to the
> same content.

I don't think that follows. I'm not saying people aren't allowed to type 
or link to URLs which have a scheme!

It's true that you could have two windows where the URL bar looks the 
same but the content displayed is different (because you are using a 
different protocol). I don't think that's necessarily a showstopper; 
there's not a security risk because they are all on the same host.

>> 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. 
> 
> What happens when there is a host called wibble.example.com, and it runs
> an intranet on http and a webmail service on https, with a self-signed
> cert.  The UI would be consistent (indeed, identical), but the content
> would be completely different.

Who actually runs two different websites on the same URL, one http and 
one https? Given that it's easy to use DNS to give the machine two names...

(Yes, I know about SSL and the lack of vhosting. That's different.)

> I don't imagine this matters in terms of Paypal, Ebay, as they will have
> everything on different host names.  But in smaller settings, there may
> well be 1 host name with a bunch of different services, and they would be
> confusing and spoofable.  For example, I could set up some HTML pages on
> an FTP server on a host which was running the organisation's intranet, and
> make it look like I'd replaced the intranet with my web pages.

But surely if you have access to do that, you could just replace the 
pages anyway?

> But it could mean for a radically different hostname, you have a similar
> textual name.  If someone gets an EV certificate for Manybank Inc, they
> can host their site at https://kjasdffdsfjewf.evil.com and the URL bar
> will be almost identical to the genuine site of Anybank Inc.

If you can get an EV cert for the same or a similar name, getting a 
similar domain name would be the easy bit. I'm not sure what extra 
protection showing both would actually afford.

>> 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.
> 
> I guess that would have to be examined, but I think I'd be more easily
> able to recognise and distinguish countries by letters than by a 16-pixel
> or so wide version of a flag.  I guess for this purpose I only really need
> to recognise my own country flag and the flag of a country I'm likely to
> be doing a lot of business with, and recognise any other flag as
> "something else".

Indeed.

>> 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. 
> 
> How would this fit together with replacing the hostname with the
> certificate name?  Would it switch back to showing the hostname when
> focused?  Or would we be happy to completely break the stuff you discuss
> here for sites with EV?

Good question. I guess it would switch back.

The whole "don't have things jump around on focus" thing is looking 
harder and harder to do...

Gerv
0
Gervase
2/16/2007 4:03:44 PM
Robert Kaiser wrote:
> Gervase Markham schrieb:
>> - Make common operations easier
> 
> A common operation for me is to edit the domain name and look at the 
> same URL on a different domain, as I'm maintaining a bunch of sites 
> using the same system and using the same path/querystring parts of their 
> URLs on different domains.

The Locationbar� extension for Firefox (as in bug 366797) allows to 
select the domain name with a single click.

> That and the difference between HTTP and FTP in some common cases makes 
> me think instead of removing the protocol, we should just display it 
> differently, e.g. replace "http://" with something that says "Web:" or 
> so, "https://" could get "Web (secure):", "ftp://" could be converted to 
> "FTP:" or "Remote file:", then "file://" could be "Local file:" - in 
> this case, we could even leave favicons in (and use some nice favicons 
> for ftp/file), as "[file icon] Local file: /home/robert/" is far enough 
> from a spoofed "[file icon] Web: fakehome.com /robert/" or such.

I like the semantics, but it also takes away space. People will complain 
and call it clutter.
0
Dao
2/16/2007 4:17:28 PM
Gervase Markham wrote:
> Hmm. It is going to be hard to square the circle of "hide some stuff", 
> "allow copying of everything" and "don't make stuff move when you focus 
> the URL bar"...

In editable documents, the content of hidden nodes gets copied, if they 
are inside of the selection.
0
Dao
2/16/2007 4:23:46 PM
Dao Gottwald schrieb:
> Robert Kaiser wrote:
>> Gervase Markham schrieb:
>>> - Make common operations easier
>>
>> A common operation for me is to edit the domain name and look at the=20
>> same URL on a different domain, as I'm maintaining a bunch of sites=20
>> using the same system and using the same path/querystring parts of=20
>> their URLs on different domains.
>=20
> The Locationbar=B2 extension for Firefox (as in bug 366797) allows to=20
> select the domain name with a single click.

Well, I neither use Firefox nor extensions, I merely commented on Gerv's =

proposal here, not on any already-done try to improve the location bar=20
(though I know and see how much hard work you've been putting into one=20
possible path of improvements).

>> That and the difference between HTTP and FTP in some common cases=20
>> makes me think instead of removing the protocol, we should just=20
>> display it differently, e.g. replace "http://" with something that=20
>> says "Web:" or so, "https://" could get "Web (secure):", "ftp://"=20
>> could be converted to "FTP:" or "Remote file:", then "file://" could=20
>> be "Local file:" - in this case, we could even leave favicons in (and =

>> use some nice favicons for ftp/file), as "[file icon] Local file:=20
>> /home/robert/" is far enough from a spoofed "[file icon] Web:=20
>> fakehome.com /robert/" or such.
>=20
> I like the semantics, but it also takes away space. People will complai=
n=20
> and call it clutter.

Those that complain should get a pref to turn back to the simple-URL=20
display. Every other extension to the location bar could be called=20
"clutter" in the same way.

Robert Kaiser
0
Robert
2/16/2007 4:39:03 PM
Gervase Markham schrieb:
> I'm not arguing that there is no difference between a machine accessed 
> over HTTP and FTP; I'm arguing that a web user doesn't really care which 
> one he's using when he clicks a link to go there. The readable vs. 
> writable thing doesn't matter for a browser, which doesn't offer FTP 
> writing facilities.

Umm, I actually though we did. And btw, why shouldn't we?

Robert Kaiser
0
Robert
2/16/2007 4:48:10 PM
On Feb 15, 12:19 pm, Gervase Markham <g...@mozilla.org> wrote:
> - Make the hostname stand out more to reduce spoofing

How extensive should this be to keep the interface consistent?

Examples of other places to recplicate the hostname emphasis.
- History entries in autocomplete dropdown
- Status bar (setting the status bar to be some text would not trigger
the emphasis)
- URL bar (as you type - instant notification if you mistyped)
- Bookmarks

0
Mardak
2/16/2007 5:51:53 PM
Michael Lefevre wrote:

> I don't imagine this matters in terms of Paypal, Ebay, as they will have
> everything on different host names.  But in smaller settings, there may
> well be 1 host name with a bunch of different services, and they would be
> confusing and spoofable.  For example, I could set up some HTML pages on
> an FTP server on a host which was running the organisation's intranet, 
> and
> make it look like I'd replaced the intranet with my web pages.

Why not add a system of Whitelist. Just like blacklist as done currently 
by  FF. We can make a list of pages for the frequently used sites 
online. That would provide best protection. At least in case of better 
known sites. The research also shows that its usually the big cos that 
are put under the phishing attack generally..

0
Saurabh
2/16/2007 5:51:58 PM
Robert Kaiser wrote:
> Gervase Markham schrieb:
>> I'm not arguing that there is no difference between a machine accessed 
>> over HTTP and FTP; I'm arguing that a web user doesn't really care 
>> which one he's using when he clicks a link to go there. The readable 
>> vs. writable thing doesn't matter for a browser, which doesn't offer 
>> FTP writing facilities.
> 
> Umm, I actually though we did. And btw, why shouldn't we?
> 
> Robert Kaiser

I know at least one browser (admittedly not a Mozilla one) which does it: 
Konqueror, where I can upload or download multiple files over FTP by drag&drop 
from one tab to another (I have done it in either direction between a file:/// 
URL and an ftp:// URL; I guess it might even work between two ftp:// URLs but 
I haven't tested the latter.) (The last time I tried the FireFTP extension, it 
was too buggy for everyday use.)

Now I'm not saying that Mozilla should blindly imitate its competitors; but 
neither should it blind itself to nice features which the competition might offer.


Best regards,
Tony.
-- 
Never tell a lie unless it is absolutely convenient.
0
Tony
2/16/2007 7:20:36 PM
Gervase Markham wrote:
> Mark Finkle wrote:
[...]
>> * I do not believe the button-style is required and I feel it creates 
>> too much "noise" in the URL bar.
> 
> You feel the bolding is sufficient? The problem with bolding is that it 
> doesn't work well for some scripts (e.g. Chinese).
[...]

Bolding, underlining, changing text or background colour... Maybe it would be 
enough to define a class or classes for the highlighted text, probably a 
default style too, and let themes and/or userChrome.css change it at will.


Best regards,
Tony.
-- 
"Plaese porrf raed."
		-- Prof. Michael O'Longhlin, S.U.N.Y. Purchase
0
Tony
2/16/2007 7:30:24 PM
On Feb 16, 10:32 am, Gervase Markham <g...@mozilla.org> wrote:
> > 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).
>
> Surely you distinguish between Google services by, er, looking at the
> content area? :-)
Reasonable answer. I recognize that most people probably don't look at
the domain/site icon when they're flipping between tabs like I do. I
will say that content area doesn't show up in history/bookmarks/
statusbar/etc. Without seeing the domain in the statusbar, there's
less reinforcement of site identity.

> Copy/pasting should work as now; when you focus the
> URL bar, it turns back to a text box.

I mostly mention the copy and paste due to the edge cases. I'm
assuming you're going to include the scheme in the copied text. Under
which conditions is the scheme added? When the full location is
selected? When the selection includes the full domain (my vote)? When
I have 'mozilla.org' selected and I'm on 'addons.mozilla.org'? I'm not
sure whether removing the scheme would be a net win or a net loss,
just trying to point out possible problems with removing the domain.

I do believe that making the domain a clickable button is a usability
loss. The 'click the mast head, go to site root' is pervasive enough
that a similar feature in chrome is largely redundant. It's the ghost
of <link rel=> nav bar past! I'm also fairly confident -- as confident
as I can be without an actual study -- that it will totally screw up
people trying to correct mistyped domain names. I think a button after
the domain _could_ work, but it still smacks of developer-geekiness
rather than end user desire.

The only other thing I have to say is that I suggest MoFo conduct some
actual usability studies on whatever the changes wind up being, as you
are changing a fundamental piece of the browser's UI. Good luck with
the changes, I'll be checking in on this thread but I'm retired from
arguing about chrome.

0
Karl
2/16/2007 7:31:36 PM
Robert Kaiser, 16-02-2007 13:48:
> Gervase Markham schrieb:
>> I'm not arguing that there is no difference between a machine accessed 
>> over HTTP and FTP; I'm arguing that a web user doesn't really care 
>> which one he's using when he clicks a link to go there. The readable 
>> vs. writable thing doesn't matter for a browser, which doesn't offer 
>> FTP writing facilities.
> 
> Umm, I actually though we did. And btw, why shouldn't we?
> 

SeaMonkey does this Robert, Firefox doesn't.

Maybe it's too confusing to the ordinary user :P.


0
Asrail
2/16/2007 7:38:56 PM
Gervase Markham, 16-02-2007 12:55:
> Asrail wrote:
>> I don't think it's really needed by default. A "Micros Soft 
>> Cooporation" on Jamaica could confuse someone, anyway.
> 
> No more, and hopefully a lot less, than www.micros0ft.com.

OK.

>> I don't think you loose too much setting it to false.
> 
> http://wwwnew.towson.edu/ows/lose_lose.htm :-)

Dam my keyboard, please be patient.

>> 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).
> 
> What, where the favicon now is? I'm not sure this icon would add much 
> value. Those protocols that don't provide a favicon can have a standard 
> icon in the same place (on the tabs), but I don't see much value in an 
> icon telling you "this is a web page". And of course we have other UI to 
> tell you "this is a secure web page".

What should you have to be able to drag the URL to the bookmarks or some 
tab? It was just an idea.

>>> 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.
>>
>> Please, I wanna my protocol.
> 
> Why? Just so you can copy it, or for some other reason also?

Copy and also to be able to change it quickly.
Some places on the web tell you to change "http" for "https", for instance.
Also you could change http for ftp if you do prefer using it to browse 
remote directories and the link on the page (and was linked to a http one).

>> 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.
> 
> Hmm. It is going to be hard to square the circle of "hide some stuff", 
> "allow copying of everything" and "don't make stuff move when you focus 
> the URL bar"...

It may be hard, but I hope we do it.

>>> 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").
>>
>> 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)
> 
> Good point.
> 
>>> Again, I don't know if this is a can of worms - I suspect URL bar 
>>> selection behaviour has been discussed before.
>>
>> 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).
> 
> No; once the URL bar is focussed, you can edit the domain name.

it's more natural to click in the place he did the mistake and that 
would lead the user to another page, instead of allowing him to edit it.
Why should he click on some white space or another place of the URL when 
the typo is in the domain?

>> 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?
> 
> Because perhaps, for example, the default GTK font produces a security 
> risk by not differentiating enough between certain characters? Or 
> perhaps it doesn't have glyphs for certain characters?
> 

OK. But I would prefer finding another way.


PS: I accept ideas also for changes in the http/https GUI ;)

0
Asrail
2/16/2007 7:54:24 PM
Gervase Markham wrote:
> Asrail wrote:
[...]
>> 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?
> 
> Because perhaps, for example, the default GTK font produces a security 
> risk by not differentiating enough between certain characters? Or 
> perhaps it doesn't have glyphs for certain characters?
> 
> Gerv

At the moment, every (advanced) user can, if he wants, select the URL bar 
font: here is, as an example, an extract from my userChrome.css:

/****************************************************************
  *                              FONTS                           *
  ****************************************************************/
/*
  * Give the Location (URL) Bar a fixed-width font
  */
#urlbar
   { font-family:
                         "SUSE Sans Mono",
                         "B&H LucidaTypewriter",
                         "Courier New",
                         Courier,
                         monospace       !important
   ; font-size:          8pt             !important
   }

Less advanced users can select default fonts in the Preferences UI; but I'm 
not sure whether this set of prefs applies to Content only, or also to Chrome.


Best regards,
Tony.
-- 
	Hug O' War

I will not play at tug o' war.
I'd rather play at hug o' war,
Where everyone hugs
Instead of tugs,
Where everyone giggles
And rolls on the rug,
Where everyone kisses,
And everyone grins,
And everyone cuddles,
And everyone wins.
		-- Shel Silverstein
0
Tony
2/16/2007 7:56:13 PM
Michael Lefevre wrote:
> On 2007-02-15, Gervase Markham <gerv@mozilla.org> wrote:
[...]
>> 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.
> 
> I guess that would have to be examined, but I think I'd be more easily
> able to recognise and distinguish countries by letters than by a 16-pixel
> or so wide version of a flag.  I guess for this purpose I only really need
> to recognise my own country flag and the flag of a country I'm likely to
> be doing a lot of business with, and recognise any other flag as
> "something else".
[...]

The Flags extension displays a flag (or a COM or ORG icon) on the status bar; 
IMHO this is enough for whoever wants a flag -- no need to duplicate it in the 
URL bar.


Best regards,
Tony.
-- 
hundred-and-one symptoms of being an internet addict:
38. You wake up at 3 a.m. to go to the bathroom and stop and check your e-mail
     on the way back to bed.
0
Tony
2/16/2007 8:02:20 PM
Gervase Markham wrote:
[...]
> Heikki said:
>> 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.
> 
> 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 www.l.google.com or www.q.google.com.

It may matter whether they are served by www.google.com or www.google.cn, 
because the Chinese Google is censored by the People's Republic. Try googling 
for "tienanmen": IIRC, in Google (China) you get a photo of a peaceful square 
with a statue of Chairman Mao, while in (let's say) Google (France) you get a 
photo of the "Peking Spring" uprising and its repression.

[...]
> J. Ruigrok van der Werven said:
[...]
>> 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.
> 
> 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?
> 
> Gerv

I think I've seen Hanzi/Kanji emphasis done by bracketing (using some CJK 
brackets, black with a squarish outside and a concave inside) in some CJK spam 
I've been getting. Which gets back to the "button" option, but with 
"localizable" brackets. Other options are bolding, underlining, or color 
(fg/bg) emphasis. IMHO (as I said elsewhere in this thread) any option we 
choose should be only a "default", changeable by themes and by userChrome.css 
-- which suggests any kind of CSS style should be possible, including e.g. 
surrounding with an outline.


Best regards,
Tony.
-- 
A lot of people I know believe in positive thinking, and so do I.  I
believe everything positively stinks.
		-- Lew Col
0
Tony
2/16/2007 8:23:12 PM
> - Make the contents of the URL bar more understandable

I haven't seen it mentioned yet - please display urlescaped characters
properly. Many languages just don't work with ascii very well... which
is more understandable
http://ja.wikipedia.org/wiki/=E3=83=A1=E3=82=A4=E3=83=B3=E3=83=9A=E3=83=BC=
=E3=82=B8
or
http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%=
E3%82%B8

This only applies to the "file" part of the URL, because the GET query
might well contain non-textual data, and un-escaping it might not
provide reasonable results.

> 1) Hide the scheme

Please keep it. While I understand that selecting the whole URL
(including scheme) will still be possible, you have to realize that
many "normal" users don't really use copy'n'paste, they look at the
adress and type it from memory (and sometimes, you even have to type
the adress on paper). Even today, you get a lot of people posting
broken links with the scheme missing, because somehow they think that
part isn't important. Try explain to your grandmother that if other UI
indicates a difference between http, https or ftp she has to correctly
infer the protocol scheme to write the adress correctly on a post-it
note (or focus the URL bar to turn it back into a textbox).

OK, maybe I'm overreacting a bit - in the majority of cases the scheme
really is irrelevant and doesn't need to be written on post-it notes
by anyone (because it's http, and if it's https you usually get
redirected to the secure version anyway). But if you type a ftp url
without the scheme into the adress bar, you could get into problems
(unless the browser tries the possible variants for you).

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

Actually, most of the time when I click on the domain, I want to
select it copy it to the clipboard (sans the rest of the URL). I'll
have to try the Locationbar extension, it looks cool enough, but I'm
not sure wether I'll like it... But I agree that it would be sometimes
handy if the adress would be "buttonized".

So, how about a hover menu? When you move the mouse over the location
bar, a hover menu fades in where you have buttons for each part of the
adress, while the actual adress is always clickable like a text field
(maybe plus some background coloring to separate the domain name.

Kim

0
ksulli
2/16/2007 8:27:41 PM
Gervase Markham wrote:
> Gervase Markham wrote:
>> 3) Highlight hostname
>>
>> Take either the entire hostname or the Effective TLD + 1 and highlight 
>> it in a button-like style. So either:
> 
> Several people, both on the blog and here in the newsgroup, have 
> mentioned making all the path components clickable buttons, instead of 
> just the domain. This is a fairly common suggestion, and I almost 
> addressed it in the original post. I'm doing so now, in a new thread part.
> 
> I'm wary of such an approach, for the following reasons:
> 
> * You don't know if moving up directories will actually produce a
>   meaningful page. On good websites it does, but not all websites are
>   good. More research may be needed, but adding a load of buttons to the
>   interface which take people to a 404 or a 500 probably isn't good UI
>   design.

There is already an extension which adds an "up-arrow" button for moving up 
one level in the directory tree. And indeed, "not all websites are good": user 
sites hosted by my ISP contain anything the owning user decides to upload, and 
a "bare" directory URL will produce an error page (ISP-specific) unless that 
directory includes at least one of index.htm, index.html, INDEX.HTM and 
INDEX.HTML.

> 
> * If all the path components are buttoned, then there's nowhere you can
>   click to focus the URL bar and turn it into a text box.

between buttons, or in the white space at the left or right ends.

> 
> * One reason this works well in e.g. file managers is that they know all
>   the possible options for a path component, and can present them in a
>   dropdown. We don't in most cases.
> 
> Gerv

- There is a dropdown for "complete from history" which is, IIRC, governed by 
some pref (about:config only or Prefs-UI I don't recall of the top of my 
head). Of course, it gives only all "currently known" completions, not all 
"possible" ones.
- For file:/// and ftp:// URLs it is possible to get the directory listing -- 
indeed, I guess it shouldn't be overly hard to browse directories of these 
protocols file-manager-wise.


Best regards,
Tony.
-- 
A person who has both feet planted firmly in the air can be safely
called a liberal.
0
Tony
2/16/2007 8:38:18 PM
Responding to your proposal. I may also post my own one here again.

Gervase Markham wrote:
> 1) Hide the scheme

Agreed.

> also means we could do things like show some HTTPS connections as if 
> they were HTTP ... This is an improvement on the current behaviour, 
> which is just to throw an error.

Totally Agreed

> 2) Hide username and password

Agreed.

> 3) Highlight hostname

Totally Agreed.

And always show it, truncate on beginning with "..." when absolutely 
necessary.

Important: Domain only, not hostname. Because of...

Also: I like your mockup on the blog with the real button vs. normal 
text, the domain is really totally taking over the eye. I think it is 
not prominent enough in your mockup of a whole urlbar.

> microsoft.com.foo.bar.baz.evil.com


> For file URLs, you'd get:
>
> [C:] /Program Files/Firefox/
>
> on Windows, and
>
> [/] home/gerv/test/

Agreed.

> 4) Display EV business name and country

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

Strongly DISagreed.

Reasons:

    * The domain is still the main trust root, the realname just
      additional trust root.
    * Uniqueness on domainnames is more strictly enforced and easier
      than real names.
    * We may be able to disable IDN (international domain names), but we
      can't cowards out of showing international characters in real
      names, reopening the whole homograph issue.
    * There's a whole new way to have phishing with similar or confusing
      names, e.g. eBay Helpers, Inc..
    * Many company may have a real name that is not easily recognizable,
      making people just accept anything even more than they do now!
      Right now, it's easy to protect yourself against phishing, only
      the most stupid or novice people fall for it. With real company
      names, even I am sometimes not sure whether that company is now
      the one I know or some other company.
    * There are actually cases where two or more companies have almost
      the same name. One of my father's companies is called "P&M
      Consulting" <http://www.pm-consulting.com>. Now, look at
      <http://www.google.com/search?q=P+M+consulting>.

Using the realname as *only* trust root is a really bad idea, IMHO. As 
additional one: great. So, show the realname to the left of the urlbar, 
shifting the URLbar to the right.  That means the realname will then 
appear where the hostname usually is, but the hostname is still there 
and just as prominent as button etc.

> 5) Remove the favicon from the URL bar entirely

Agreed.

> This would probably imply making the tab bar always visible ... so 
> that the favicon was always visible

Not good enough reason for a whole toolbar. It's just a tiny icon, after 
all. The tabbar looks quite ridiculous with only one tab. Do we want to 
encourage people to load more tabs, jumping around, not concentrating on 
one page? :) (OK, I'm a bit off.)

Also, favicons in tab headers are still in chrome.

I'd suggest to drop this change from the proposal, it's only vaguely 
related.

> page-proxy-icon ... that role could be taken over by the domain name 
> button, perhaps.

Agreed.

> Perhaps we might consider a fixed-width font in the URL bar?

No!!! I absolutely hate fixed fonts. I think they should remain at 
typewriters and mainframes, thank you.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/16/2007 8:38:20 PM
Gervase Markham wrote:

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

One option would be to display (and emphasize) the port if isn't the 
default port for the given protocol.  The port would almost never 
appear, and thus it wouldn't be in the way most of the time but might 
raise a red flag when it does show up.

-myk
0
Myk
2/16/2007 8:45:37 PM
Dao Gottwald wrote:
> Robert Kaiser wrote:
>> Gervase Markham schrieb:
>>> - Make common operations easier
>>
>> A common operation for me is to edit the domain name and look at the 
>> same URL on a different domain, as I'm maintaining a bunch of sites 
>> using the same system and using the same path/querystring parts of 
>> their URLs on different domains.
> 
> The Locationbar� extension for Firefox (as in bug 366797) allows to 
> select the domain name with a single click.
> 
>> That and the difference between HTTP and FTP in some common cases 
>> makes me think instead of removing the protocol, we should just 
>> display it differently, e.g. replace "http://" with something that 
>> says "Web:" or so, "https://" could get "Web (secure):", "ftp://" 
>> could be converted to "FTP:" or "Remote file:", then "file://" could 
>> be "Local file:" - in this case, we could even leave favicons in (and 
>> use some nice favicons for ftp/file), as "[file icon] Local file: 
>> /home/robert/" is far enough from a spoofed "[file icon] Web: 
>> fakehome.com /robert/" or such.
> 
> I like the semantics, but it also takes away space. People will complain 
> and call it clutter.

IMHO there ought to be a setting somewhere to revert to the current behaviour. 
So some people would be able to get the "more meaningful for newbies" display, 
while others could get the "tech" display (with http: ftp: etc. at the left) 
or even the "uncluttered" display (with no protocol, or only an icon).


Best regards,
Tony.
-- 
If I don't see you in the future, I'll see you in the pasture.
0
Tony
2/16/2007 8:46:27 PM
Gervase Markham, 16-02-2007 12:32:
> J. Ruigrok van der Werven said:
> [snip]
>> 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.
> 
> 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?
> 

Just to remember that using the button alone would trigger the full 
versus effective domain link issue (the user would like to go to 
wiki.mozilla.org or mozilla.org, probably wiki.mozilla.org, but covering 
the full domain would cover microsoft.somehacker.com and also some 
servers don't listen at the effective domain, ugh).


0
Asrail
2/16/2007 8:50:37 PM
Gervase Markham wrote:
> 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 www.l.google.com or www.q.google.com.

Oh, Google is a great example! google.de, google.fr and google.com give 
totally different results. And not just due to the default language 
(which changes basically all results and I don't know why until I see 
"google.fr", a clue which would then be gone), but also the 
government-induced filters. Not that you enter google.com and end up at 
google.fr automatically, redirection based on (bad) IP address location 
guessing.

I don't know whether google.de is run by a German company or Google in 
USA. The fact that I don't know it means it's arbitrary, and should not 
have effect on the UI. And in this case, one company setup would even 
break the UI (different results, but same URL display).


Stepping back from that, more generally: If you say I don't care about 
the hostname, why do I care about the path then? Why not drop the whole 
URL and have a domain only? Surely, the hostname is more significant 
than the path. And the second level domain more than the hostname.

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

Not at all! The whole *point* of serving on different ports is to have 
different sites on it. Day-to-day example: SSH port forwarding to an 
intranet which gave me SSH, but doesn't have OpenVPN.

The port, if not the default, is just as significant as the hostname. 
Treat it in UI similarly (i.e. don't emphasize it, but leave it in).

> [differentiate between www.google.com and groups.google.com]
>
> Surely you distinguish between Google services by, er, looking at the
> content area? :-)

I thought we wanted to move people *away* from using the content area to 
identify where they are?

> I agree that the method of domain emphasis may have to vary based on
> locale. Which is not ideal.

Wait. We're talking about domain names only. I thought we dropped IDN? 
If not, we can still find other ways to emphasize things for IDNs, or 
simply not bold at all in that case. Still, 99.9+% of all domains are 
a-z0-9.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/16/2007 9:17:03 PM
Robert Kaiser wrote:
> Dao Gottwald schrieb:
>>> I think a prefix like
>>> [My Computer] /home/gerv/test
>>> would be horrible, particularly on Unix.
>> Why?
> 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. 

So how about [root]?
-- 
Regards,

Peter Lairo

The browser you can trust:   www.GetFirefox.com
Reclaim Your Inbox:          www.GetThunderbird.com
0
Peter
2/16/2007 9:19:56 PM
Asrail wrote:
> Maybe it's too confusing to the ordinary user :P.

More likely it's not generally useful -- the set of users who need to upload files via FTP is small and is often better served by a real uploading application.  Also, exposing FTP uploading in UI will confuse some non-negligible portion of the people who don't need and wouldn't use it.

Jeff
0
Jeff
2/16/2007 9:20:42 PM
On 16 Feb 2007 12:27:41 -0800, ksulli@volny.cz <ksulli@volny.cz> wrote:
> > - Make the contents of the URL bar more understandable
>
> I haven't seen it mentioned yet - please display urlescaped characters
> properly. Many languages just don't work with ascii very well... which
> is more understandable
> http://ja.wikipedia.org/wiki/$B%a%$%s%Z!<%8(B
> or
> http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8
>
+1 from me.
Opera, Konqueror and IE (to a certain extent) display it URLs with
Unicode characters correctly without escaping. Firefox should follow
the same way.

Thanks
Saravanan
0
Saravanan
2/16/2007 9:22:40 PM
Saravanan, 16-02-2007 18:22:
> On 16 Feb 2007 12:27:41 -0800, ksulli@volny.cz <ksulli@volny.cz> wrote:
>> > - Make the contents of the URL bar more understandable
>>
>> I haven't seen it mentioned yet - please display urlescaped characters
>> properly. Many languages just don't work with ascii very well... which
>> is more understandable
>> http://ja.wikipedia.org/wiki/$B%a%$%s%Z!<%8(B
>> or
>> http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 
>>
>>
> +1 from me.
> Opera, Konqueror and IE (to a certain extent) display it URLs with
> Unicode characters correctly without escaping. Firefox should follow
> the same way.
> 

The locationbar2 extension already does this.
This is one of the main goals (side by side with avoid phishing).
0
Asrail
2/16/2007 9:52:11 PM
Gervase Markham wrote:
> My gut tells me that clearing out the URL and replacing it with 
> something else would be pretty common

Yes. It wasn't easy to explain my mom how to even enter a URL, because I 
had to explain her how to mark text - given that she's new to the 
computer, this is hard for her, and holding and moving the mouse right 
is not easy in the beginning either.

So, make it very easy to replace the whole URL with a new one. Very 
obvious, no additional screen space. It's probably be unrelated to your 
proposal, though. (It would be related to mine, though.)

>> (Mark Finkle) I do not believe the button-style is required
> You feel the bolding is sufficient?

No! It is not. Far too subtle. The domain should appear to be something 
completely *different* from the rest of the URL. Because it kind of is - 
it's the only part interesting to most people. That's one of the roots 
of the phishing problem: People ignore the URL, because they see it all 
as technical glibberish.

If your proposal ends up in practice as "Bold the domain", the proposal 
failed. It won't make much of a difference in practice.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/16/2007 10:04:47 PM
On Feb 16, 9:08 am, Dao Gottwald <d...@design-noir.de> wrote:
> Robert Kaiser wrote:
> > Maybe because
> > [My Computer] /mnt/srv/software/
> > would be on a server elsewhere and not actually my computer here on my
> > system?
>
> There's nothing wrong with that. The starting point is still your file
> system ("/" alias "my computer").

On Windows XP, servers on UNC paths are not considered a part of "My
Computer"; going "Up" from a UNC path will take your through a network
tree, to "My Network Places", and finally the Desktop, never "My
Computer". Mapped drives, on the other hand *are* displayed as part of
"My Computer".

I don't see any need to force one OS's terminology on the other - on
systems that call the file system "My Computer", we can put "My
Computer", for the file systems that call it "/", we can put "/".

0
Jason
2/16/2007 10:10:26 PM
Gervase Markham wrote:
> I'm not arguing that there is no difference between a machine accessed
> over HTTP and FTP; I'm arguing that a web user doesn't really care which
> one he's using when he clicks a link to go there. The readable vs.
> writable thing doesn't matter for a browser, which doesn't offer FTP
> writing facilities.

I am repeating my concern stated on your blog, and echoed by another
person about the concern in hiding parts of the URL.

Hiding scheme may make it hard to figure out if you are connected over
SSL or not (especially if the UI changes to not distinguish between
plain HTTP and self signed certs + SSL). And if there is additional
functionality like in the case of ftp it would be nice to know that too.

My concern about hiding the domain was about potential situations where
the same company controls multiple domains. Maybe you can tell the
difference from the content, maybe not (I have tried to search Google
myself several times, without realizing I was on Google News).

However, I think the point that really convinced me that hiding parts of
URLs is bad is that we'd then find bunch of broken links on the web. If
my mom sees the location bar say:

Example Business, Inc. / shopping / basket ? id=1

she would be likely to *type* that in an email to a friend to take a
look at the product, rather than copy and paste. Also, if I were to take
a screenshot of a browser window showing

Example Business Inc. / main.php

and make a bug report saying that web page does not lay out properly in
Firefox, you'd be pretty frustrated...

-- 
  Heikki Toivonen
0
Heikki
2/17/2007 12:36:55 AM
Gervase Markham wrote:
> * If all the path components are buttoned, then there's nowhere you can
>   click to focus the URL bar and turn it into a text box.

It can work, but is not as good usability wise, especially with long
urls: you click past the end of the last character in the URL.

But yes, I buy your argument. The most important piece IMO is
highlighting the host.

-- 
  Heikki Toivonen
0
Heikki
2/17/2007 12:46:51 AM
On 2/16/07, Asrail <asrail@gmail.com> wrote:
> Saravanan, 16-02-2007 18:22:
> > On 16 Feb 2007 12:27:41 -0800, ksulli@volny.cz <ksulli@volny.cz> wrote:
> >> > - Make the contents of the URL bar more understandable
> >>
> >> I haven't seen it mentioned yet - please display urlescaped characters
> >> properly. Many languages just don't work with ascii very well... which
> >> is more understandable
> >> http://ja.wikipedia.org/wiki/$B%a%$%s%Z!<%8(B
> >> or
> >> http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8
> >>
> >>
> > +1 from me.
> > Opera, Konqueror and IE (to a certain extent) display it URLs with
> > Unicode characters correctly without escaping. Firefox should follow
> > the same way.
> >
>
> The locationbar2 extension already does this.
> This is one of the main goals (side by side with avoid phishing).

I *knew* that. Locationbar2 extension correctly displays URL with
Unicode characters but it does not allow you to copy those URLs
without escaping.

Thanks
Saravanan
0
Saravanan
2/17/2007 2:34:25 AM
Heikki Toivonen wrote:
> Hiding scheme may make it hard to figure out if you are connected over
> SSL or not (especially if the UI changes to not distinguish between
> plain HTTP and self signed certs + SSL).

That is the *intent*. We want to allow people to connect to self-signed 
HTTPS sites, without warning dialogs, and let them make use of the tiny 
bit of extra protection (no passive sniffing), but we *don't* want them 
to think it's "secure" or "protected against sniffing and alteration", 
because it's not (MITM). If they see SSL / HTTPS, they'll think it is 
protected. Hiding the scheme has the *advantage*, not downside, to hide 
the fact that it's SSL. We'll show other indicators to show whether it's 
protected against sniffing or not.

This really is a critical part in significantly improving our SSL 
handling and UI.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/17/2007 4:39:01 AM
Gervase Markham wrote:

> Several people, both on the blog and here in the newsgroup, have 
> mentioned making all the path components clickable buttons, instead of 
> just the domain. This is a fairly common suggestion, and I almost 
> addressed it in the original post. I'm doing so now, in a new thread part.
> 
> I'm wary of such an approach, for the following reasons:

I completely agree.

In addition, I think it's safe to assume that most users don't navigate 
within a site by editing the URL bar. [Although entering an entirely new 
location wouldn't seem unusual.] As such, I'm not sure it's a feature we 
really want.

Locationbar^2 did a really great job with implementing most of the 
features in the list. The idea of displaying one format when not 
focused, but reverting to an editable text field when focused, is key.
Unfortunately the most recent version (which does this clickable-path 
thing) is a very disappointing step backwards. Since the URL bar has 
traditionally been a text field, I think doing anything to that alters 
text field semantics (when focused) isn't going to go over well with users.

This would also imply that the non-focused state shouldn't be too 
radically different (to retain discoverability), although the limits are 
indistinct. It's worth noting that a "perfect" design for the URL bar 
might need a halfway-compromise for Firefox 3, so that users can start 
to adjust to the changes.

Justin
0
Justin
2/17/2007 6:09:29 AM
Gervase Markham wrote:
> Several people, both on the blog and here in the newsgroup, have 
> mentioned making all the path components clickable buttons, instead of 
> just the domain. This is a fairly common suggestion, and I almost 
> addressed it in the original post. I'm doing so now, in a new thread part.
> 
> I'm wary of such an approach, for the following reasons:
> 
> * You don't know if moving up directories will actually produce a
>   meaningful page. On good websites it does, but not all websites are
>   good. More research may be needed, but adding a load of buttons to the
>   interface which take people to a 404 or a 500 probably isn't good UI
>   design.
> 
> * If all the path components are buttoned, then there's nowhere you can
>   click to focus the URL bar and turn it into a text box.
> 
> * One reason this works well in e.g. file managers is that they know all
>   the possible options for a path component, and can present them in a
>   dropdown. We don't in most cases.

I'm going to remove buttons for path segments in the next Lb� release, 
but turn the segments into links when the user presses Alt/Option.
0
Dao
2/17/2007 9:55:25 AM
Robert Kaiser wrote:
> Gervase Markham schrieb:
>> I'm not arguing that there is no difference between a machine 
>> accessed over HTTP and FTP; I'm arguing that a web user doesn't 
>> really care which one he's using when he clicks a link to go there. 
>> The readable vs. writable thing doesn't matter for a browser, which 
>> doesn't offer FTP writing facilities.
>
> Umm, I actually though we did. And btw, why shouldn't we?

You can also write to HTTP (HTTP PUT etc.). We support both in necko 
(network library).

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/17/2007 2:07:18 PM
On Feb 16, 3:37 pm, Gervase Markham <g...@mozilla.org> wrote:

> > * I do not believe the button-style is required and I feel it creates
> > too much "noise" in the URL bar.
>
> You feel the bolding is sufficient? The problem with bolding is that it
> doesn't work well for some scripts (e.g. Chinese).

We could use colour, in fact we could make it blue and underlined like
a link.
(each directory in the URL could also be a link, styled similarly that
leads to that directory).

Jon

0
jonquark
2/17/2007 7:25:59 PM
On 2007-02-16, Tony Mechelynck <antoine.mechelynck@belgacom.net> wrote:
> Gervase Markham wrote:
[snip]
>> 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 www.l.google.com or www.q.google.com.
>
> It may matter whether they are served by www.google.com or www.google.cn, 
[snip]

Although with domains in different countries, you would imagine they would
have EV certs in the appropriate country.  Yahoo may be a better example,
where uk.yahoo.com and www.yahoo.com are also different sites, and giving
different search results.

-- 
Michael
0
Michael
2/17/2007 10:19:21 PM
Gervase Markham wrote:
>>> 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. 
>>
>> What happens when there is a host called wibble.example.com, and it runs
>> an intranet on http and a webmail service on https, with a self-signed
>> cert.  The UI would be consistent (indeed, identical), but the content
>> would be completely different.
> 
> Who actually runs two different websites on the same URL, one http and
> one https? Given that it's easy to use DNS to give the machine two names...
> 
> (Yes, I know about SSL and the lack of vhosting. That's different.)

I do, actually. Exactly the way Michael described (https for webmail
and admin tasks, http for main webpage). And I'm sure I'm not the only
one.
However, the users type www.mail.host.tld, and are redirected to
https://host.tld. Still, I'm against many of the changed described here.

RQ
0
Rimas
2/18/2007 1:09:11 AM
Sorry, I haven't read all of the answers, but it's 3AM already...

Gervase Markham wrote:
> 1) Hide the scheme
>=20
> 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 differenc=
e
> between HTTP and HTTPS is, of course, important, but we have other UI t=
o
> 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 a=
s
> if they were HTTP - e.g. for self-signed certificates, which people jus=
t
> 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.
>=20
> FTP could have a special favicon, as could file://.

Please, don't. You could aswell indicate those not-so-trustworthy
HTTPS connections using the "other UI" you mentioned. Also, see below.

> 2) Hide username and password
>=20
> If present. Usernames and passwords over unencrypted channels, embedded=

> in GET requests (which are cached) and links, are fundamentally insecur=
e
> and their most common use is for spoofing (although we already have som=
e
> 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.

Hmm, I'm not sure I completely understood this point. Do you want to
apply some stripping to GET urls? Nah, I don't think we want it.
Firstly, because it's unforgivably stupid to transmit user and
password using GET's, and no serious sites should be doing that.
Secondly, you may never know, which get variable holds the username
and password, so you'll never be 100% sure you stripped the right
variables from display.
However, I'm not against stripping the "username:password@" part from
the URLs.

> 3) Highlight hostname
>=20
> Take either the entire hostname or the Effective TLD + 1 and highlight
> it in a button-like style. So either:
>=20
> www. [EXAMPLE.COM] /foo/bar/baz?q=3Dx
>=20
> Or maybe
>=20
> [www.EXAMPLE.COM] /foo/bar/baz?q=3Dx
>=20
> where capital letters indicate some sort of styling such as bold. (We
> need to be careful with bold; with some fonts, it reduces the differenc=
e
> 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.

I think bold is enough, and the font should remain as chosen by the
user. See below for more.

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

Right. That's difficult. It could just be anything...
A kind of related issue is that Mozilla apps still ignore <link
rel=3D"next"> and similar head items. Adding some buttons (maybe a
separate optional toolbar or something) could solve this issue (not
from anti-phishing point of view, though). Also, see below.

> For file URLs, you'd get:
>=20
> [C:] /Program Files/Firefox/
>=20
> on Windows, and
>=20
> [/] home/gerv/test/
>=20
> 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

Solution: you could use:
[C:/] Program Files/Firefox/
to solve the slash problem.

> 4) Display EV business name and country
>=20
> For HTTPS connections with EV certificates, replace the hostname with
> the O (Organisation) and C (Country) fields from the certificate. So:
>=20
> [* Paypal, Inc.] /foo/bar/baz?q=3Dx
>=20
> 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=
=2E

Now, here's the "below" part. Have you seen IE7? It adds a small
clickable field with a lock for secure sites. Now we could have
something similar. Why not PREPEND an EV (WTF is EV?) information
instead of replacing the domain name with it? So, it could look like this=
:
[[L] Paypal, Inc., *] https://www.paypal.com/foo/bar/baz?q=3Dx
The [L] could be replaced by a Lock icon, and a * - with country
letters (US, UK). This whole field could itself be a button, which,
when clicked, could show a dialog with more information, or whatever
you want. This way, you:
1) Don't break stuff people use;
2) Reduce the risk of spoofing (you may still make the hostname
bolded, if you like);
3) Make the common operations easier.

One your goal that isn't met is "Make the contents of the URL bar more
understandable", but I'm not sure we really need it. I certainly don't
want breadcrumbs navigation (for all the reasons stated in those posts
I've read already), and I don't want any blue/green/whatever arrows
either. I want slashes, I want clickable text to edit, and I don't
want it to change on hover or on my click. Really.

> The flag is next to where the favicon should be, which raises a risk of=

> confusing of spoofing, but leads on to:
>=20
> 5) Remove the favicon from the URL bar entirely
>=20
> 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 the=
y
> 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.

I agree with this one.

> I believe that the only other function of the page-proxy-icon (where th=
e
> 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.

You don't need a favicon to do that. I liked the proposal to display
different icon for different protocols here (The lock being an icon
for https sites). So the user could use that protocol-specific icon to
create a bookmark, IMO.

> 6) Focus turns bar back to a text box

See above.

> 7) Change selection behaviour
>=20
> 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").

I agree. However, I also believe that most people don't really change
the URL often. Instead, they often rewrite it completely, or erase
everything that is after the domain part.

> 8) Analyse font choice carefully
>=20
> 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.

It hurts my eyes when some =FCbercool application decides for me what
fonts/colors/button styles etc I want to use in that application, I'm
almost always against that. Well, there always are exceptions, for
example, I like the way how address bar changes its color in Firefox,
depending on SSL state.

However, for example, in Linux, you're simply never sure what fonts
are available and if they are the best choice. Using monospace font
could be a solution, however, still it's a customization and a
departure from what the user has chosen in his global UI prefs (or
what the OS vendor has chosen for the user).

Maybe, instead of a button and bold, we could have some other visual
differentiation? For example, add some border+background for the
domain name part, but not make it a button? And if this weren't a
button, it would be themable through CSS, so it would be fairly easy
to make it different for people with vision problems.

RQ
0
Rimas
2/18/2007 1:49:59 AM
Rimas Kudelis wrote:
> Now, here's the "below" part. Have you seen IE7? It adds a small
> clickable field with a lock for secure sites.

Just for the reference, here's how IE7 handles a website with a
self-signed certificate:
http://pics.rq.online.lt/index.php?folder=/screens/windows/ie7/

Those screenshots also depict how to install a SSL certificate into
IE. You may ignore that part. :)

RQ
0
Rimas
2/18/2007 2:06:28 AM
Tony Mechelynck wrote:
> - For file:/// and ftp:// URLs it is possible to get the directory
> listing -- indeed, I guess it shouldn't be overly hard to browse
> directories of these protocols file-manager-wise.

For file://, yes; for ftp:// not necessarily, as I may enter or click
on a URL pointing right to
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/, so Fx won't know
what's in /pub/mozilla.org/

And as file:// remains probably the only URL type where this would
work, I think it's a little inconvenient. Instead, for file:// URL's
Firefox could display more suggestions than history actually contains. ;)

RQ
0
Rimas
2/18/2007 2:15:55 AM
ksulli@volny.cz wrote:
>> - Make the contents of the URL bar more understandable
>=20
> I haven't seen it mentioned yet - please display urlescaped characters
> properly. Many languages just don't work with ascii very well... which
> is more understandable
> http://ja.wikipedia.org/wiki/=E3=83=A1=E3=82=A4=E3=83=B3=E3=83=9A=E3=83=
=BC=E3=82=B8
> or
> http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83=
%BC%E3%82%B8

Now consider a URL with 30 %20's. If unescaped, these would be
displayed as spaces. And as the URL bar only has finite length (say,
40 symbols, and then text flows out), and no scrollbar, you'll simply
NOT know that the URL you see is incomplete. That's a good phishing
opportunity, IMO. Don't you think so?

This should be thought of before unescaping characters. BTW, how does
Firefox handle IDN currently?

RQ
0
Rimas
2/18/2007 2:29:08 AM
Rimas Kudelis, 17-02-2007 23:15:
> Tony Mechelynck wrote:
>> - For file:/// and ftp:// URLs it is possible to get the directory
>> listing -- indeed, I guess it shouldn't be overly hard to browse
>> directories of these protocols file-manager-wise.
> 
> For file://, yes; for ftp:// not necessarily, as I may enter or click
> on a URL pointing right to
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/, so Fx won't know
> what's in /pub/mozilla.org/
> 
> And as file:// remains probably the only URL type where this would
> work, I think it's a little inconvenient. Instead, for file:// URL's
> Firefox could display more suggestions than history actually contains. ;)
> 

It's "possible" to do the same for FTP.
When you're viewing an FTP connection you share the same connection and 
can do multiple requests.

The XUL way of viewing directory listing allow you to do multiple 
requests without loading a new page.

It means that an FTP request could be fired when clicking there and the 
remote content could be displayed.
It could even be prefetched, so the user would see the list immediately 
right after the click.


Well... I'm not saying that I like it, I'm just saying it is possible.

0
Asrail
2/18/2007 4:20:20 AM
Rimas Kudelis, 17-02-2007 22:49:
> 
> Gervase Markham wrote:
>> 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.
> 
> Right. That's difficult. It could just be anything...
> A kind of related issue is that Mozilla apps still ignore <link
> rel="next"> and similar head items. Adding some buttons (maybe a
> separate optional toolbar or something) could solve this issue (not
> from anti-phishing point of view, though). Also, see below.
> 

Firefox had a site navigation bar a long, long time ago and it was dropped.
SeaMonkey still having one.

Well... most pages don't use navigation links.
Even pages that follow the next, previous, up, top structure makes use 
of this.

If you find some good place at the UI, let us know.
0
Asrail
2/18/2007 4:37:15 AM
Rimas Kudelis, 17-02-2007 23:29:
> ksulli@volny.cz wrote:
>>> - Make the contents of the URL bar more understandable
>> 
>> I haven't seen it mentioned yet - please display urlescaped characters
>> properly. Many languages just don't work with ascii very well... which
>> is more understandable
>> http://ja.wikipedia.org/wiki/メインページ
>> or
>> http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8
> 
> Now consider a URL with 30 %20's. If unescaped, these would be
> displayed as spaces. And as the URL bar only has finite length (say,
> 40 symbols, and then text flows out), and no scrollbar, you'll simply
> NOT know that the URL you see is incomplete. That's a good phishing
> opportunity, IMO. Don't you think so?

URL should be escaped. If there are issues like this, they should be fixed.
A indicator that the visible area has been overflowed would be a good 
option.

> This should be thought of before unescaping characters. BTW, how does
> Firefox handle IDN currently?

Nicely.
0
Asrail
2/18/2007 4:46:01 AM
Asrail wrote:
[...]
> Firefox had a site navigation bar a long, long time ago and it was dropped.
> SeaMonkey still having one.
[...]

Never knew Firefox ever had one. I like SeaMonkey's, even if I can only use it 
on the Bugzilla site.


Best regards,
Tony.
-- 
hundred-and-one symptoms of being an internet addict:
42. Your virtual girlfriend finds a new net sweetheart with a larger bandwidth.
0
Tony
2/18/2007 10:39:31 AM
Asrail wrote:
>> Gervase Markham wrote:
>>> 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.
>>
>> Right. That's difficult. It could just be anything...
>> A kind of related issue is that Mozilla apps still ignore <link
>> rel="next"> and similar head items. Adding some buttons (maybe a
>> separate optional toolbar or something) could solve this issue (not
>> from anti-phishing point of view, though). Also, see below.
>>
> 
> Firefox had a site navigation bar a long, long time ago and it was dropped.
> SeaMonkey still having one.

Hmm... Never saw it. OK.

> Well... most pages don't use navigation links.

Because most browsers ignore them. ;)

> Even pages that follow the next, previous, up, top structure makes use
> of this.

Well, on the other hand, most pages have their own way of going up, so
it's probably not so much in a need. I don't know... Anyways, same
applies to the hostname button still.

> If you find some good place at the UI, let us know.

The problem is probably not where to put those buttons, but how to
distinguish them from already existing "Back", "Forward" and "Home"
buttons... Furthermore, separate toolbar is probably not the best
thing, as it may clutter UI (I have installed Web Developer and
Operator at work, and it already looks cluttered with the total of
five toolbars including menu).

The short answer is "I don't know for sure".

RQ
0
Rimas
2/18/2007 10:51:48 AM
>
> Now consider a URL with 30 %20's. If unescaped, these would be
> displayed as spaces. And as the URL bar only has finite length (say,
> 40 symbols, and then text flows out), and no scrollbar, you'll simply
> NOT know that the URL you see is incomplete. That's a good phishing
> opportunity, IMO. Don't you think so?

You're right that so many spaces are something that needs to be
handled (maybe visualise long strings of whitespace), but I'm not sure
if it's really a phishing opportunity because un-escaping %20 should
only happen in the file part of the url, not in the query part - and
since most URL based phishing attacks try to either spoof the domain
(which is handled elsewhere in the IDN code), or use a publicly
acessible redirect, it would be a bit tricky.

You'd basically need some url like

www.somebank.com/path/to/redirector/%20%20%20%20%20%20%20%20%20%20%20%20%20=
%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20?url=3Dhttp://xx.xx.xx.x=
x/steal-login

which is almost equally susceptible to phishing, because, well, do you
really think that ordinary users will try to decipher a long string of
"some garbage with numbers and % signs"? Also, since the %20 have to
be in the "path", you'd need some really stupid url-handling rules to
be able to do that... so let's suppose they have, and the above is a
valid path, which would be rendered like

www.somebank.com/path/to/redirector/                              ?
url=3Dhttp://xx.xx.xx.xx/steal-login

Why not display such overly long strings of whitespace in the filename
using the middle dot (as is commonly done in word processors with the
"show whitespace" option turned on):
www.somebank.com/path/to/redirector/=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=
=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7?url=3Dhttp://xx.xx.xx.x=
x/steal-login

There is another even simpler option: don't unescape whitespace (Opera
does this like that). It's probably the simplest solution, and I think
it's an acceptable trade-off between URL readability, and security
(and normal sites won't usually have more than a few %20 in their url
anyway, and those that care will have replaced them with - or _).

0
Kim
2/18/2007 11:36:13 AM
Rimas Kudelis, 18-02-2007 07:51:
> Asrail wrote:
>>> Right. That's difficult. It could just be anything...
>>> A kind of related issue is that Mozilla apps still ignore <link
>>> rel="next"> and similar head items. Adding some buttons (maybe a
>>> separate optional toolbar or something) could solve this issue (not
>>> from anti-phishing point of view, though). Also, see below.
>>>
>> 
>> Firefox had a site navigation bar a long, long time ago and it was dropped.
>> SeaMonkey still having one.
> 
> Hmm... Never saw it. OK.

It was before 1.0, I'm sure. I don't know until which version (maybe it 
wasn't even called Firefox), but it had one (I can look at the FTP site 
and show an example).

>> Well... most pages don't use navigation links.
> 
> Because most browsers ignore them. ;)

Opera don't, SM don't, FX dropped... I think you meant "because IE 
ignores them".

>> Even pages that follow the next, previous, up, top structure makes use
>> of this.
> 
> Well, on the other hand, most pages have their own way of going up, so
> it's probably not so much in a need. I don't know... Anyways, same
> applies to the hostname button still.

Move to another page magically based on numbers near the end of the URL 
was proposed some time ago as one features for this extension.
I think that the navigation links are useful. One could assign shortcuts 
for these with a extension, for instance.

>> If you find some good place at the UI, let us know.
> 
> The problem is probably not where to put those buttons, but how to
> distinguish them from already existing "Back", "Forward" and "Home"
> buttons... Furthermore, separate toolbar is probably not the best
> thing, as it may clutter UI (I have installed Web Developer and
> Operator at work, and it already looks cluttered with the total of
> five toolbars including menu).

Yet another toolbar is the SM approach. I dislike it and would like to 
see some improvement on that area. We shouldn't transform the URL bar in 
a "Emacs minibuffer", as joked a friend of mine, but may to exist some 
way of adding functionality without confusing the UI or being hard to use.
0
Asrail
2/18/2007 3:51:55 PM
Tony Mechelynck, 18-02-2007 07:39:
> Asrail wrote:
> [...]
>> Firefox had a site navigation bar a long, long time ago and it was 
>> dropped.
>> SeaMonkey still having one.
> [...]
> 
> Never knew Firefox ever had one. I like SeaMonkey's, even if I can only 
> use it on the Bugzilla site.
> 

View --> Show/Hide --> Site navigation bar

;)

Yeah, that works fine with bugzilla.


0
Asrail
2/18/2007 3:53:32 PM
Asrail wrote:
>>>> Right. That's difficult. It could just be anything...
>>>> A kind of related issue is that Mozilla apps still ignore <link
>>>> rel="next"> and similar head items. Adding some buttons (maybe a
>>>> separate optional toolbar or something) could solve this issue (not
>>>> from anti-phishing point of view, though). Also, see below.
>>>>
>>>
>>> Firefox had a site navigation bar a long, long time ago and it was
>>> dropped.
>>> SeaMonkey still having one.
>>
>> Hmm... Never saw it. OK.
> 
> It was before 1.0, I'm sure. I don't know until which version (maybe it
> wasn't even called Firefox), but it had one (I can look at the FTP site
> and show an example).

No need for that, I believe you. :)

>>> Well... most pages don't use navigation links.
>>
>> Because most browsers ignore them. ;)
> 
> Opera don't, SM don't, FX dropped... I think you meant "because IE
> ignores them".

Yes, IE ignores them, and that alone constitutes a vast majority of
web users. However, the next most popular browser, Firefox, now
ignores them too, and it's irrelevant if it supported those buttons
back in Phoenix 0.5 or not. That was a long time ago, when it didn't
have its current userbase. Safari, the default browser for Mac, also
doesn't have this functionality, Konqueror either. What remains is
Opera, which is way less popular than Fx, and Sm, which has like
err... 0% of total userbase?.. That's not much to worry about...

Btw, I think Opera is mostly used by people who consider themselves
power users, and people like these rarely complain about missing
features like the one I'm talking about... :)


>>> Even pages that follow the next, previous, up, top structure makes use
>>> of this.
>>
>> Well, on the other hand, most pages have their own way of going up, so
>> it's probably not so much in a need. I don't know... Anyways, same
>> applies to the hostname button still.
> 
> Move to another page magically based on numbers near the end of the URL
> was proposed some time ago as one features for this extension.

Yeah. Imagine it increasing the value of PHPSESSID :) I think such
functionality is probably OK for an extension, but it definitely
shouldn't go into mainstream Firefox.

> I think that the navigation links are useful. One could assign shortcuts
> for these with a extension, for instance.

If you're talking about <link rel="next"> etc, then I agree. But
again, it possibly clutters the UI, and is rarely used by website
owners... One of the reasons for that is that websites are tree-like,
and it would be quite hard to put them into a single row logically.

The two cases where I see such links working would be:
1) paged articles (which are often misused anyway, IMO);
2) small websites with, say, 5 pages total.

However, I hardly imagine myself enumerating pages of the website of
my university into some sequence...

>>> If you find some good place at the UI, let us know.
>>
>> The problem is probably not where to put those buttons, but how to
>> distinguish them from already existing "Back", "Forward" and "Home"
>> buttons... Furthermore, separate toolbar is probably not the best
>> thing, as it may clutter UI (I have installed Web Developer and
>> Operator at work, and it already looks cluttered with the total of
>> five toolbars including menu).
> 
> Yet another toolbar is the SM approach. I dislike it and would like to
> see some improvement on that area. We shouldn't transform the URL bar in
> a "Emacs minibuffer", as joked a friend of mine, but may to exist some
> way of adding functionality without confusing the UI or being hard to use.

Maybe one of the problems is that Firefox/Thunderbird don't allow
stacking toolbars next to each other (like classic MS Office does). Do
I really need 19 centimeters of space for the URL bar in Firefox? I
doubt it. ;)

BTW, it's a bit weird that I can easily add a new toolbar, but not
remove one... :)

RQ
0
Rimas
2/18/2007 6:02:22 PM
Rimas Kudelis wrote:
> Asrail wrote:
>>>>> Right. That's difficult. It could just be anything...
>>>>> A kind of related issue is that Mozilla apps still ignore <link
>>>>> rel="next"> and similar head items. Adding some buttons (maybe a
>>>>> separate optional toolbar or something) could solve this issue (not
>>>>> from anti-phishing point of view, though). Also, see below.
>>>>>
>>>> Firefox had a site navigation bar a long, long time ago and it was
>>>> dropped.
>>>> SeaMonkey still having one.
>>> Hmm... Never saw it. OK.
>> It was before 1.0, I'm sure. I don't know until which version (maybe it
>> wasn't even called Firefox), but it had one (I can look at the FTP site
>> and show an example).
> 
> No need for that, I believe you. :)
> 
>>>> Well... most pages don't use navigation links.
>>> Because most browsers ignore them. ;)
>> Opera don't, SM don't, FX dropped... I think you meant "because IE
>> ignores them".
> 
> Yes, IE ignores them, and that alone constitutes a vast majority of
> web users. However, the next most popular browser, Firefox, now
> ignores them too, and it's irrelevant if it supported those buttons
> back in Phoenix 0.5 or not. That was a long time ago, when it didn't
> have its current userbase. Safari, the default browser for Mac, also
> doesn't have this functionality, Konqueror either. What remains is
> Opera, which is way less popular than Fx, and Sm, which has like
> err... 0% of total userbase?.. That's not much to worry about...
> 
> Btw, I think Opera is mostly used by people who consider themselves
> power users, and people like these rarely complain about missing
> features like the one I'm talking about... :)
> 
> 
>>>> Even pages that follow the next, previous, up, top structure makes use
>>>> of this.
>>> Well, on the other hand, most pages have their own way of going up, so
>>> it's probably not so much in a need. I don't know... Anyways, same
>>> applies to the hostname button still.
>> Move to another page magically based on numbers near the end of the URL
>> was proposed some time ago as one features for this extension.
> 
> Yeah. Imagine it increasing the value of PHPSESSID :) I think such
> functionality is probably OK for an extension, but it definitely
> shouldn't go into mainstream Firefox.
> 
>> I think that the navigation links are useful. One could assign shortcuts
>> for these with a extension, for instance.
> 
> If you're talking about <link rel="next"> etc, then I agree. But
> again, it possibly clutters the UI, and is rarely used by website
> owners... One of the reasons for that is that websites are tree-like,
> and it would be quite hard to put them into a single row logically.
> 
> The two cases where I see such links working would be:
> 1) paged articles (which are often misused anyway, IMO);
> 2) small websites with, say, 5 pages total.
> 
> However, I hardly imagine myself enumerating pages of the website of
> my university into some sequence...
> 
>>>> If you find some good place at the UI, let us know.
>>> The problem is probably not where to put those buttons, but how to
>>> distinguish them from already existing "Back", "Forward" and "Home"
>>> buttons... Furthermore, separate toolbar is probably not the best
>>> thing, as it may clutter UI (I have installed Web Developer and
>>> Operator at work, and it already looks cluttered with the total of
>>> five toolbars including menu).
>> Yet another toolbar is the SM approach. I dislike it and would like to
>> see some improvement on that area. We shouldn't transform the URL bar in
>> a "Emacs minibuffer", as joked a friend of mine, but may to exist some
>> way of adding functionality without confusing the UI or being hard to use.
> 
> Maybe one of the problems is that Firefox/Thunderbird don't allow
> stacking toolbars next to each other (like classic MS Office does). Do
> I really need 19 centimeters of space for the URL bar in Firefox? I
> doubt it. ;)

You can move any widgets from one toolbar to another, to the menu bar, or 
altogether off the screen.

> 
> BTW, it's a bit weird that I can easily add a new toolbar, but not
> remove one... :)
> 
> RQ

View => Toolbars => click a toolbar name to remove the check mark. From then 
on it won't be displayed.


Best regards,
Tony.
-- 
Oh, wow!  Look at the moon!
0
Tony
2/18/2007 6:33:41 PM
Tony Mechelynck wrote:
> Rimas Kudelis wrote:
>> BTW, it's a bit weird that I can easily add a new toolbar, but not
>> remove one... :)
> 
> View => Toolbars => click a toolbar name to remove the check mark. From
> then on it won't be displayed.

But it won't be deleted. :) Well, maybe not everyone needs it OTOH...

RQ
0
Rimas
2/18/2007 6:46:37 PM
Kim Sullivan, 18-02-2007 08:36:
> 
> You'd basically need some url like
> 
> www.somebank.com/path/to/redirector/%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20?url=http://xx.xx.xx.xx/steal-login
> 

I don't believe any ordinary user would pay attention to the redirect 
part. Mainly because that could/should looks like:
q=http%3A%2F%2Fxx.xx.xx%2Fsl
instead of the obvious steal one.
Tiny URL and alike are as dangerous as this one and not phishing domains 
shouldn't allow arbitrary redirects.
Google allow redirects for the pages that appear on their search 
(changing the URL redirects you to a notice page).

But the ordinary users pay attention to what they see and won't read 
long URLs at all.
We should add security by not allowing the user to be 
infected/threatened just by visiting the page and he would see the wrong 
domain there, anyway.

> 
> Why not display such overly long strings of whitespace in the filename
> using the middle dot (as is commonly done in word processors with the
> "show whitespace" option turned on):
> www.somebank.com/path/to/redirector/������������������������������?url=http://xx.xx.xx.xx/steal-login
> 
> There is another even simpler option: don't unescape whitespace (Opera
> does this like that). It's probably the simplest solution, and I think
> it's an acceptable trade-off between URL readability, and security
> (and normal sites won't usually have more than a few %20 in their url
> anyway, and those that care will have replaced them with - or _).
> 

Allowing the user to copy is good. Wikipedia accepts "%20" or "_", so 
both would work, but a lot of sites only allow "%20" to represent spaces.
So changing it to something else would stop copy and past.
Changing from "�" to "%20" on mouseover is not pretty.
Version 0.8 of the scrollbar does not changes the look of the text URL 
on mouseover, only the visual style.
You could give a try to different versions and see what features make it 
less comfortable to browse (moving things too much and changing a lot of 
other things would gave me a headache).
0
Asrail
2/18/2007 11:58:25 PM
Karl Guertin wrote:
> The only other thing I have to say is that I suggest MoFo conduct some
> actual usability studies on whatever the changes wind up being, as you
> are changing a fundamental piece of the browser's UI.

I'll look into my crystal ball then...

Ahhh. 4 groups:

1. Novice users never looked at the location bar and still don't. The 
only thing they use above the content area is the back button, the 
window close button, and maybe the print button (but probably not, since 
it's stupidly not in the default set). They might notice that "the 
Internet looks a little different now," but they won't really care. Most 
everything up above the content area is scary.

2. Moderately advanced users will be annoyed at the change since they 
(at least vaguely) understood how the location bar worked previously. 
They don't like change. Or they'll feel like things are being dumbed down.

3. Very advanced users will appreciate how the changes could help their 
"educated novice" family members. (see group 4)

4. The last group is the "educated novices." These are the users who 
would belong to group 1, but have family belonging to group 3. They have 
been told what to look for to avoid getting caught by phishing scams. 
They err on the safe side and don't use their bank's website if anything 
looks a little different from how they remember things last time. They 
also like to forward scam emails with the message "Is this real?"
These proposed changes to the location bar may benefit these users in 
the long run, but the actual benefit comes to group 3: group 4 will call 
group 3 on the phone less frequently with questions. Group 3 WILL have 
to spend time re-educating group 4 on how to understand the new features 
since anything that--even subtly--looks different will potentially seem 
like a huge change to group 4.


**Disclaimer**
I don't mean to discourage the efforts of those persons working on these 
changes.

Greg
0
Greg
2/19/2007 2:23:39 AM
On Feb 19, 12:58 am, Asrail <asr...@gmail.com> wrote:
> > Why not display such overly long strings of whitespace in the filename
> > using the middle dot (as is commonly done in word processors with the
> > "show whitespace" option turned on):
> >www.somebank.com/path/to/redirector/=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=
=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7=B7?url=3Dhttp://xx.xx.x=
x=2Exx/steal-login
>
> > There is another even simpler option: don't unescape whitespace (Opera
> > does this like that). It's probably the simplest solution, and I think
> > it's an acceptable trade-off between URL readability, and security
> > (and normal sites won't usually have more than a few %20 in their url
> > anyway, and those that care will have replaced them with - or _).
>
> Allowing the user to copy is good. Wikipedia accepts "%20" or "_", so
> both would work, but a lot of sites only allow "%20" to represent spaces.
> So changing it to something else would stop copy and past.

I didn't mean to actually change it, just display a different
character than would be copied. I'm all for copying. I've been
thinking about another issue with copying URLS - copy the escaped or
unescaped URL? I mean, sometimes you want to directly use the address
as a target for a link, in which case you want the escape sequences.
In other cases, you want to copy the URL so it will be human readable
later, so you really want to copy the characters, and not the escape
sequences.

I think that a hover menu (that appears below the location bar, and
doesn't change the text or look of the text in the address) would be a
lot more flexible than trying to fit everything in a single line.

Whatever the final decision will be, it should consistent with how
URLs are displayed in the status bar. Currently, they are displayed
unescaped (which is good), including spaces (which is not so good).

0
Kim
2/19/2007 9:18:25 AM
Kim Sullivan wrote:
> On Feb 19, 12:58 am, Asrail <asr...@gmail.com> wrote:
>>> Why not display such overly long strings of whitespace in the filenam=
e
>>> using the middle dot (as is commonly done in word processors with the=

>>> "show whitespace" option turned on):
>>> www.somebank.com/path/to/redirector/=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=
=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=
=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7?=
url=3Dhttp://xx.xx.xx.xx/steal-login
>>> There is another even simpler option: don't unescape whitespace (Oper=
a
>>> does this like that). It's probably the simplest solution, and I thin=
k
>>> it's an acceptable trade-off between URL readability, and security
>>> (and normal sites won't usually have more than a few %20 in their url=

>>> anyway, and those that care will have replaced them with - or _).
>> Allowing the user to copy is good. Wikipedia accepts "%20" or "_", so
>> both would work, but a lot of sites only allow "%20" to represent spac=
es.
>> So changing it to something else would stop copy and past.
>=20
> I didn't mean to actually change it, just display a different
> character than would be copied. I'm all for copying. I've been
> thinking about another issue with copying URLS - copy the escaped or
> unescaped URL? I mean, sometimes you want to directly use the address
> as a target for a link, in which case you want the escape sequences.
> In other cases, you want to copy the URL so it will be human readable
> later, so you really want to copy the characters, and not the escape
> sequences.
>=20
> I think that a hover menu (that appears below the location bar, and
> doesn't change the text or look of the text in the address) would be a
> lot more flexible than trying to fit everything in a single line.

Think of the third case =E2=80=93 when you don't really care at all about=
 the
way your URL would be copied. I think this is the most common scenario.

I wouldn't really want to get a hover menu each time I want to copy
something. That's rude. Maybe a simple about:config variable would do,
leaving context menu stuff to some extension?

RQ
0
Rimas
2/19/2007 9:38:37 AM
Tony Mechelynck wrote:
> Bolding, underlining, changing text or background colour... Maybe it 
> would be enough to define a class or classes for the highlighted text, 
> probably a default style too, and let themes and/or userChrome.css 
> change it at will.

Possibly. But that still leaves the question of what the default is. 
Also, for UI which has a security dimension, consistency across browser 
versions is important. So ideally we would pick one style that worked 
everywhere and stick to it.

Gerv
0
Gervase
2/19/2007 10:09:06 AM
Ben Bucksch wrote:
> So, make it very easy to replace the whole URL with a new one. Very 
> obvious, no additional screen space. It's probably be unrelated to your 
> proposal, though. (It would be related to mine, though.)

Press Ctrl-L and start typing?

Gerv
0
Gervase
2/19/2007 10:09:48 AM
jonquark@gmail.com wrote:
> On Feb 16, 3:37 pm, Gervase Markham <g...@mozilla.org> wrote:
> 
>>> * I do not believe the button-style is required and I feel it creates
>>> too much "noise" in the URL bar.
>> You feel the bolding is sufficient? The problem with bolding is that it
>> doesn't work well for some scripts (e.g. Chinese).
> 
> We could use colour, in fact we could make it blue and underlined like
> a link.

We could. Conceptually, that makes some sense, but I can't help thinking 
it would confuse people in practice.

> (each directory in the URL could also be a link, styled similarly that
> leads to that directory).

But then the domain would no longer be distinctively styled.
0
Gervase
2/19/2007 10:10:58 AM
Gervase Markham wrote on 19.02.2007 11:09:
> Ben Bucksch wrote:
>> So, make it very easy to replace the whole URL with a new one. Very 
>> obvious, no additional screen space. It's probably be unrelated to 
>> your proposal, though. (It would be related to mine, though.)
> 
> Press Ctrl-L and start typing?

Discoverable? Easily discoverable? Complies with usage habits?
-- 
Regards,

Peter Lairo

Lame attempt to get rich: http://www.lairo.com/donations.html
0
Peter
2/19/2007 10:16:33 AM
Heikki Toivonen wrote:
> Hiding scheme may make it hard to figure out if you are connected over
> SSL or not (especially if the UI changes to not distinguish between
> plain HTTP and self signed certs + SSL). 

As Ben says, that's the idea. We specifically don't want people to think 
they are more secure.

> And if there is additional
> functionality like in the case of ftp it would be nice to know that too.

Then, when and if such functionality appears, we should provide 
understandable UI that shows that. As Ben also points out, we can 
theoretically provide upload capabilities for both HTTP and FTP.

Let's use upload as an example. Saying "If you want to know if you can 
upload, look for 'ftp://' in the URL bar" is not particularly good UI. 
There's no mental connection for most people between the ability to 
upload and the six weird characters 'ftp://'. You would describe the UI 
that way only because that's all there would be to indicate that this 
capability is available.

> My concern about hiding the domain was about potential situations where
> the same company controls multiple domains. Maybe you can tell the
> difference from the content, maybe not (I have tried to search Google
> myself several times, without realizing I was on Google News).

Then that's a bug in Google's site. :-)

> However, I think the point that really convinced me that hiding parts of
> URLs is bad is that we'd then find bunch of broken links on the web. If
> my mom sees the location bar say:
> 
> Example Business, Inc. / shopping / basket ? id=1
> 
> she would be likely to *type* that in an email to a friend to take a
> look at the product, rather than copy and paste. 

Really? Do people type out entire URLs because copy and paste is beyond 
them? I know we have to take account of all users, but it seems to me 
that it would be very difficult to use any application on a computer 
these days without some notion of the idea of copy and paste.

> Also, if I were to take
> a screenshot of a browser window showing
> 
> Example Business Inc. / main.php
> 
> and make a bug report saying that web page does not lay out properly in
> Firefox, you'd be pretty frustrated...

Perhaps. But you will admit this is a very niche case.

Gerv
0
Gervase
2/19/2007 10:16:50 AM
Dao Gottwald wrote:
> What I meant is, if we occasionally replace the domain, a user could 
> think that the EV business name is an equivalent, which it isn't.

They might. What's the worst that happens? The URL bar does a search on 
the business name with the default search provider, and most of the time 
they'll get to where they want to go quite soon.

Remember also the name button might have a flag, which of course they 
can't type in. The use of an icon perhaps makes it more obvious that 
this is not something you can type yourself.

Gerv
0
Gervase
2/19/2007 10:18:48 AM
Asrail wrote:
> What should you have to be able to drag the URL to the bookmarks or some 
> tab? It was just an idea.

That's a good question. We'd certainly need to consider that.

We could just stop putting the favicon there and always have it as the 
default blank sheet of paper. But then it's more likely that people 
would consider that the browser is broken.

>>> Please, I wanna my protocol.
>>
>> Why? Just so you can copy it, or for some other reason also?
> 
> Copy and also to be able to change it quickly.
> Some places on the web tell you to change "http" for "https", for instance.
> Also you could change http for ftp if you do prefer using it to browse 
> remote directories and the link on the page (and was linked to a http one).

Perhaps we need to make the protocol visible in the full text version...

>> No; once the URL bar is focussed, you can edit the domain name.
> 
> it's more natural to click in the place he did the mistake and that 
> would lead the user to another page, instead of allowing him to edit it.
> Why should he click on some white space or another place of the URL when 
> the typo is in the domain?

Again, a good point.

Gerv
0
Gervase
2/19/2007 10:21:15 AM
Tony Mechelynck wrote:
> At the moment, every (advanced) user can, if he wants, select the URL 
> bar font: here is, as an example, an extract from my userChrome.css:

Right - but this has basically no bearing on the question, because even 
if we provided UI for changing the font, users would a) probably never 
change it, and b) if they did, they'd change it for a font that looked 
prettier, not one that was more secure.

We need to choose the font, and we need to make the correct choice for 
security.

Gerv

0
Gervase
2/19/2007 10:22:25 AM
Rimas Kudelis wrote:
> I do, actually. Exactly the way Michael described (https for webmail
> and admin tasks, http for main webpage). And I'm sure I'm not the only
> one.

Why? Why not use different hostnames? Is it too inconvenient for you to 
change the DNS to have two aliases for the same machine?

Gerv

0
Gervase
2/19/2007 10:23:22 AM
Tony Mechelynck wrote:
> The Flags extension displays a flag (or a COM or ORG icon) on the status 
> bar; IMHO this is enough for whoever wants a flag -- no need to 
> duplicate it in the URL bar.

It's not about "wanting a flag", it's about indicating the jurisdiction 
under which the company works in order to disambiguate names. And the 
flag is not generated from the TLD, it's generated from the C field of 
the certificate (which might be different).

Still, I'm sure that extension would be a good source of flag icons :-)

Gerv
0
Gervase
2/19/2007 10:24:24 AM
Karl Guertin wrote:
> Reasonable answer. I recognize that most people probably don't look at
> the domain/site icon when they're flipping between tabs like I do. I
> will say that content area doesn't show up in history/bookmarks/

Right - the page title does. Which is not affected by this proposal.

> statusbar/etc. Without seeing the domain in the statusbar, there's
> less reinforcement of site identity.

I'm not sure what you mean here. Are you talking about the domain 
indicator in the bottom right?

> I mostly mention the copy and paste due to the edge cases. I'm
> assuming you're going to include the scheme in the copied text. Under
> which conditions is the scheme added? When the full location is
> selected? When the selection includes the full domain (my vote)? When
> I have 'mozilla.org' selected and I'm on 'addons.mozilla.org'? I'm not
> sure whether removing the scheme would be a net win or a net loss,
> just trying to point out possible problems with removing the domain.

All good points. If the scheme were hidden, I would expect it to be 
added to the copy whenever the selection started at the left hand end of 
the URL bar.

> I do believe that making the domain a clickable button is a usability
> loss. The 'click the mast head, go to site root' is pervasive enough
> that a similar feature in chrome is largely redundant. It's the ghost
> of <link rel=> nav bar past! I'm also fairly confident -- as confident
> as I can be without an actual study -- that it will totally screw up
> people trying to correct mistyped domain names. I think a button after
> the domain _could_ work, but it still smacks of developer-geekiness
> rather than end user desire.

I'm beginning to agree with you.

> The only other thing I have to say is that I suggest MoFo conduct some
> actual usability studies on whatever the changes wind up being, as you
> are changing a fundamental piece of the browser's UI. 

A good point.

Gerv

0
Gervase
2/19/2007 10:26:19 AM
Tony Mechelynck wrote:
> It may matter whether they are served by www.google.com or 
> www.google.cn, because the Chinese Google is censored by the People's 
> Republic. 

Remember, this only happens for SSL connections, not for plain HTTP 
connections like the ones to Google. And, if both connections were over 
HTTPS, it's quite likely (although not guaranteed) that the flags would 
be different.

> I think I've seen Hanzi/Kanji emphasis done by bracketing (using some 
> CJK brackets, black with a squarish outside and a concave inside) in 
> some CJK spam I've been getting. 

That's really interesting.

> Which gets back to the "button" option, 
> but with "localizable" brackets. Other options are bolding, underlining, 
> or color (fg/bg) emphasis. IMHO (as I said elsewhere in this thread) any 
> option we choose should be only a "default", changeable by themes and by 
> userChrome.css -- which suggests any kind of CSS style should be 
> possible, including e.g. surrounding with an outline.

Yes, it should be themeable, just like anything else. But ideally the 
default would be the same for all locales, as that's what 99% of people 
will use.

Gerv
0
Gervase
2/19/2007 10:29:20 AM
Myk Melez wrote:
> One option would be to display (and emphasize) the port if isn't the 
> default port for the given protocol.  The port would almost never 
> appear, and thus it wouldn't be in the way most of the time but might 
> raise a red flag when it does show up.

That's certainly an interesting idea.

Gerv
0
Gervase
2/19/2007 10:30:16 AM
Ben Bucksch wrote:
> Oh, Google is a great example! google.de, google.fr and google.com give 
> totally different results. And not just due to the default language 
> (which changes basically all results and I don't know why until I see 
> "google.fr", a clue which would then be gone), but also the 
> government-induced filters. Not that you enter google.com and end up at 
> google.fr automatically, redirection based on (bad) IP address location 
> guessing.

Remember, this substition is only for HTTPS.

> Stepping back from that, more generally: If you say I don't care about 
> the hostname, why do I care about the path then? Why not drop the whole 
> URL and have a domain only? Surely, the hostname is more significant 
> than the path. And the second level domain more than the hostname.

We could. That's a more radical change, but it's perhaps consistent. 
After all, most users see it as a jumble of confusing characters...

>> 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.
> 
> Not at all! The whole *point* of serving on different ports is to have 
> different sites on it. 

Different sites, yes. But controlled by different people who are not 
mutually trusting?

Where would you find a server where I have a website on port 80 and Mr. 
Evil, who I don't know and don't trust, has a website on port 90?

> The port, if not the default, is just as significant as the hostname. 
> Treat it in UI similarly (i.e. don't emphasize it, but leave it in).

Myk suggested highlighting it if not the default.

>> Surely you distinguish between Google services by, er, looking at the
>> content area? :-)
> 
> I thought we wanted to move people *away* from using the content area to 
> identify where they are?

It's a different sort of distinguishing. It's about distinguishing what 
you are doing, as opposed to on whose site you are doing it.

I want to distinguish whether I'm on my bank's site or a spoof of my 
bank's site by looking at the domain indicator. Sure. But then, I 
distinguish whether I'm editing my account or reading about mortgages by 
looking at the content area. This point is almost too obvious to be 
worth making. How do you know what you are doing on the web? By what the 
content area says. If it's got lists of emails, I'm looking at my inbox. 
If it's a single email, I'm reading one.

>> I agree that the method of domain emphasis may have to vary based on
>> locale. Which is not ideal.
> 
> Wait. We're talking about domain names only. I thought we dropped IDN? 

I don't know what you mean by that. You mean from the discussion, or 
from the product? :-)

> If not, we can still find other ways to emphasize things for IDNs, or 
> simply not bold at all in that case. Still, 99.9+% of all domains are 
> a-z0-9.

That is true, at the moment. But ideally, the highlight method we use 
should be future-proof. I don't want to have to switch highlight methods 
depending on the exact combination of characters in the domain name.

Gerv
0
Gervase
2/19/2007 10:36:48 AM
Tony Mechelynck wrote:
> Gervase Markham wrote:
>> * If all the path components are buttoned, then there's nowhere you can
>>   click to focus the URL bar and turn it into a text box.
> 
> between buttons, or in the white space at the left or right ends.

But are people really going to rememeber to do that?

I realise this argument is also an argument against making the domain 
name clickable.

>> * One reason this works well in e.g. file managers is that they know all
>>   the possible options for a path component, and can present them in a
>>   dropdown. We don't in most cases.
> 
> - There is a dropdown for "complete from history" which is, IIRC, 
> governed by some pref (about:config only or Prefs-UI I don't recall of 
> the top of my head). Of course, it gives only all "currently known" 
> completions, not all "possible" ones.

Indeed - and I think it would be hard to unambiguously indicate to the 
user that the list was not exhaustive.

Gerv
0
Gervase
2/19/2007 10:38:06 AM
Ben Bucksch wrote:
> Heikki Toivonen wrote:
>> Hiding scheme may make it hard to figure out if you are connected over
>> SSL or not (especially if the UI changes to not distinguish between
>> plain HTTP and self signed certs + SSL).
> 
> That is the *intent*. We want to allow people to connect to self-signed

who is "we"?

> HTTPS sites, without warning dialogs, and let them make use of the tiny
> bit of extra protection (no passive sniffing), but we *don't* want them
> to think it's "secure" or "protected against sniffing and alteration",
> because it's not (MITM). If they see SSL / HTTPS, they'll think it is
> protected. Hiding the scheme has the *advantage*, not downside, to hide
> the fact that it's SSL. We'll show other indicators to show whether it's
> protected against sniffing or not.
> 
> This really is a critical part in significantly improving our SSL
> handling and UI.
> 
0
Nelson
2/19/2007 10:42:27 AM
Robert Kaiser wrote:
> It's clear such a restructuring can't (easily) satisfy everyone, but I'd 
> be happy to e.g. be able to correct a mistyped URL fast, even if I 
> mistyped the domain part. And, from your proposal, I couldn't yet find 
> out how to get to an empty location bar in which I can type a new URL, 
> or search query.

One way is to press Ctrl-L and start typing. Ctrl-L will still focus the 
URL bar and select all the contents.

> Ah, yes, that leads me to the next idea/problem: I love typing a bunch 
> of words in the location bar and have SeaMonkey automatically search 
> Google (my default search engine) for those, not needing a special 
> "search" textbox in the toolbar. It's not that hard to detect if what 
> the user entered is a URL or not :)

I would hope that would continue to work; I don't see why it wouldn't.

> I'd hope that we could get to some stage where we have one place in the 
> UI where a user would enter "what he wants to see/find" and we would 
> perform the right action based on circumstances. That action could be 
> "request the entered URL", "search the web for this expression" or even 
> "search the currently viewed page for this expression". I believe that 
> could be done from one central place in the UI, the location bar being 
> the obvious candidate for that in my eyes. Maybe the bar would need to 
> visibly enter different modes of operation or so for that, but I think 
> it should be tried, as it really would ease user interaction with the 
> browser, IMO.

This is the "merge location bar and search box" proposal. I used to 
think this was a great idea myself, but I've moved away from it as the 
search box has acquired more function (e.g. selecting search providers 
from a dropdown, autocomplete of search terms) which it would be hard to 
put into the URL bar without making it insanely complex.

> That and the difference between HTTP and FTP in some common cases makes 
> me think instead of removing the protocol, we should just display it 
> differently, e.g. replace "http://" with something that says "Web:" or 
> so, "https://" could get "Web (secure):", "ftp://" could be converted to 
> "FTP:" or "Remote file:", then "file://" could be "Local file:" - in 
> this case, we could even leave favicons in (and use some nice favicons 
> for ftp/file), as "[file icon] Local file: /home/robert/" is far enough 
> from a spoofed "[file icon] Web: fakehome.com /robert/" or such.

If we put other text in place, it's possible that people will try to 
type it instead of the real thing. And then we have to recognise it. And 
then they do it in other browsers and wonder why it doesn't work. And we 
either have a compatibility problem, or we have invented a new /de 
facto/ alternative for "http://", which is "web:".

> With some user action (edit icon or such?) to start editing the full 
> URL, we could switch the bar into edit mode, displaying a dropdown with 
> a current value of "URL:" instead of the protocol identifier string I 
> proposed in the last paragraph, and the full URL for simple editing as 
> in the current location bar. The dropdown would be changeable to "Search 
> the Web" or "Find in page", each of which would clear the space for 
> editing and allow the user to either enter a web search or do a FAYT 
> operation on the current page. Of course, any current way of invocation 
> of those functions currently would switch into the respective edit mode 
> (Ctrl+F, Ctrl+L, etc.) - and ESC or small cancel icon in the bar would 
> leave edit/search mode and go back to normal display.

I would be concerned that such a multi-modal URL bar would be hard for 
users to understand. Perhaps one of my goals should be: "not increase 
complexity".

Gerv
0
Gervase
2/19/2007 10:43:22 AM
Mardak wrote:
> How extensive should this be to keep the interface consistent?

_Very_ good point.

> Examples of other places to recplicate the hostname emphasis.
> - History entries in autocomplete dropdown

Yes, we should do that.

> - Status bar (setting the status bar to be some text would not trigger
> the emphasis)

Well, we disable the ability to set the status bar text now anyway. But 
yes, URLs in the status bar should have the same emphasis if possible.

> - URL bar (as you type - instant notification if you mistyped)

Good stuff too.

> - Bookmarks

Well, normally the URL isn't displayed, is it?

But the big point here is that if the highlighting is going to be 
present throughout the UI, and if it is going to be consistent, then we 
have to use a text style which works in places which are much more 
"text-y". In other words, we sort of have a choice of bold, italic, 
underline or some combination of the three.

Gerv

0
Gervase
2/19/2007 10:45:42 AM
ksulli@volny.cz wrote:
>> - Make the contents of the URL bar more understandable
> 
> I haven't seen it mentioned yet - please display urlescaped characters
> properly. Many languages just don't work with ascii very well... which
> is more understandable
> http://ja.wikipedia.org/wiki/メインページ
> or
> http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8

I believe Locationbar2 does this already. I was worried about it to 
start with, but I'm beginning to like it. As long as it switches back on 
focus.

There are standards for this sort of thing, I believe - IRIs and so on.

>> 1) Hide the scheme
> 
> Please keep it. While I understand that selecting the whole URL
> (including scheme) will still be possible, you have to realize that
> many "normal" users don't really use copy'n'paste, they look at the
> adress and type it from memory (and sometimes, you even have to type
> the adress on paper). Even today, you get a lot of people posting
> broken links with the scheme missing, because somehow they think that
> part isn't important. Try explain to your grandmother that if other UI
> indicates a difference between http, https or ftp she has to correctly
> infer the protocol scheme to write the adress correctly on a post-it
> note (or focus the URL bar to turn it back into a textbox).

But people write "www.mozilla.org" or similar on post-it notes all the 
time, and the world doesn't stop spinning. If you type "www.mozilla.org" 
into the URL bar of a browser, you'll end up in the right place.

The only place "http://" becomes important is for people hand-editing 
HTML. Does your grandmother do that? If she does, she should know about 
URL schemes.

> OK, maybe I'm overreacting a bit - in the majority of cases the scheme
> really is irrelevant and doesn't need to be written on post-it notes
> by anyone (because it's http, and if it's https you usually get
> redirected to the secure version anyway). But if you type a ftp url
> without the scheme into the adress bar, you could get into problems
> (unless the browser tries the possible variants for you).

Firefox already tries FTP first for hosts whose name is "ftp".

Gerv
0
Gervase
2/19/2007 10:48:39 AM
Rimas Kudelis wrote:
  > Now consider a URL with 30 %20's. If unescaped, these would be
> displayed as spaces. And as the URL bar only has finite length (say,
> 40 symbols, and then text flows out), and no scrollbar, you'll simply
> NOT know that the URL you see is incomplete. That's a good phishing
> opportunity, IMO. Don't you think so?

Not really. Because it only gives the opportunity to hide what the URL 
is _within_ a particular domain - and all that content should be under 
the control of the same person. Phishing relies on confusion about the 
domain.

Gerv
0
Gervase
2/19/2007 10:49:37 AM
Ben Bucksch wrote:
> Responding to your proposal. I may also post my own one here again.
> 
> Gervase Markham wrote:
>> 1) Hide the scheme
> 
> Agreed.

Ben - I'm glad that you agree with so much of the proposal. I'm 
focussing on the bits you disagree about in this reply only because 
there's not much point discussing the things we agree on! :-)

> Strongly DISagreed.
> 
> Reasons:
> 
>    * The domain is still the main trust root, the realname just
>      additional trust root.
>    * Uniqueness on domainnames is more strictly enforced and easier
>      than real names.
>    * We may be able to disable IDN (international domain names), but we
>      can't cowards out of showing international characters in real
>      names, reopening the whole homograph issue.

I don't think we have any plans to disable IDN. But I agree, there is 
potentially a homograph problem which would need to be solved again. The 
jurisdiction indicator mitigates this to a certain extent.

>    * There's a whole new way to have phishing with similar or confusing
>      names, e.g. eBay Helpers, Inc..

I'm not sure that would pass the "human sanity check" part of the EV 
process.

>    * Many company may have a real name that is not easily recognizable,
>      making people just accept anything even more than they do now!

That is certainly a risk. There are particular problems with this in 
Japan, where often the official English transliteration of the Japanese 
name is not the same as the name everyone knows the company by. For 
example, Sony's Japanese name officially transliterates to "Sonii 
Corporation". Does that look like a phishing attempt to you? :-)

In this case (Japan), the EV people are working on a way to authenticate 
the name everyone really knows the company by, so that it can be put 
into the relevant field. But I agree there's a concern.

>    * There are actually cases where two or more companies have almost
>      the same name. One of my father's companies is called "P&M
>      Consulting" <http://www.pm-consulting.com>. Now, look at
>      <http://www.google.com/search?q=P+M+consulting>.

Are any two in the same country?

> Using the realname as *only* trust root is a really bad idea, IMHO. As 
> additional one: great. So, show the realname to the left of the urlbar, 
> shifting the URLbar to the right.  That means the realname will then 
> appear where the hostname usually is, but the hostname is still there 
> and just as prominent as button etc.

Now that's an interesting idea.

>> This would probably imply making the tab bar always visible ... so 
>> that the favicon was always visible
> 
> Not good enough reason for a whole toolbar. It's just a tiny icon, after 
> all. The tabbar looks quite ridiculous with only one tab. Do we want to 
> encourage people to load more tabs, jumping around, not concentrating on 
> one page? :) (OK, I'm a bit off.)

I think we definitely want to improve the discoverability of tabs, and 
encourage people to use them more, yes.

As monitor sizes get bigger, the "screen real estate" argument fades 
into the background a bit.

> Also, favicons in tab headers are still in chrome.

True, but they are in an area of the chrome which is both right next to 
the content area, and already filled with content from it (page titles).

> I'd suggest to drop this change from the proposal, it's only vaguely 
> related.

It's certainly not tied in tightly. But I think it's worth keeping it as 
part of the same discussion, because it combats a possible disadvantage 
of another idea.

Gerv
0
Gervase
2/19/2007 10:57:23 AM
> > I think that a hover menu (that appears below the location bar, and
> > doesn't change the text or look of the text in the address) would be a
> > lot more flexible than trying to fit everything in a single line.
>
> Think of the third case =E2=80=93 when you don't really care at all about=
 the
> way your URL would be copied. I think this is the most common scenario.

I think that it's not really a question about caring or not, I believe
people want it to just work. Unfortunately, URIs/URLs are defined in a
way that prevents this, because they require non us-ASCII octets to be
encoded with percent signs, which is contrary to what users want (or
at least so I believe), namely readable URLs.

The problem is that
http://ja.wikipedia.org/wiki/=E3=83=A1=E3=82=A4=E3=83=B3=E3=83=9A=E3=83=BC=
=E3=82=B8 is not really a valid URL (at
least the way I nunderstand the RFC spec), allthough Opera, IE and FF
seem to handle it OK if it's a part of a link (and the w3c validator
accepts it as well).

So, using character sequences all the time (on display and on copy/
paste) would probably work well enough - completely hiding the fact
that there is something as an encoding scheme using percent signs and
hex numbers (except for whitespace).

> I wouldn't really want to get a hover menu each time I want to copy
> something. That's rude. Maybe a simple about:config variable would do,
> leaving context menu stuff to some extension?

You're right - being able to use the adress bar as a text field (copy/
paste, editing) is important. The hover menu was just an idea, because
there seem to be contradicting suggestions - people want to be able to
select and edit and copy/paste the adress as usual, and at the same
time they would like to have parts of the url active as buttons,
displaying EV (whatever that means), and I think you can't really have
both at the same time (the current LocationBar2 extension nicely shows
that, to be able to edit something you first have to actually click on
a part of the URL)

Kim

0
Kim
2/19/2007 10:59:57 AM
Rimas Kudelis wrote:
> However, I'm not against stripping the "username:password@" part from
> the URLs.

That's all I meant. :-)

> Now, here's the "below" part. Have you seen IE7? It adds a small
> clickable field with a lock for secure sites. Now we could have
> something similar. Why not PREPEND an EV (WTF is EV?) information
> instead of replacing the domain name with it? 

You are the second person to suggest that (after Ben). It's certainly an 
interesting idea.

Gerv
0
Gervase
2/19/2007 11:00:54 AM
Gervase Markham wrote:
> Rimas Kudelis wrote:
>> I do, actually. Exactly the way Michael described (https for webmail
>> and admin tasks, http for main webpage). And I'm sure I'm not the only
>> one.
> 
> Why? Why not use different hostnames? Is it too inconvenient for you to
> change the DNS to have two aliases for the same machine?

Because it's not always JUST mail. Plus, the problem of secure
name-based vhosts still exists. Plus, as I said, people do type a
different hostname. It simply redirects them to https://domain.name/

RQ
0
Rimas
2/19/2007 11:05:51 AM
On Feb 19, 11:48 am, Gervase Markham <g...@mozilla.org> wrote:

> But people write "www.mozilla.org" or similar on post-it notes all the
> time, and the world doesn't stop spinning. If you type "www.mozilla.org"
> into the URL bar of a browser, you'll end up in the right place.
>
> The only place "http://" becomes important is for people hand-editing
> HTML. Does your grandmother do that? If she does, she should know about
> URL schemes.

Not really - many public discussion sites (and blogs and whatnot)
assume that URLs that are pasted without http: are relative urls
(actually it's the browser itself that does this, the websites don't
assume anything), people just write something like
[url]addons.mozilla.org[/url] and post it. When the page is displayed,
it contains a link like
<a href="addons.mozilla.org">addons.mozilla.org</a> which usually gets
interpreted by the browser as a relative URL, pointing to
http://www.whateversiteyouron.com/addons.mozilla.org, and not to
http://addons.mozilla.org

When you type a URL in the address bar (or post-it note), you can be
reasonably sure that it's an absolute URL. Whenever you post a link to
some website, you probably mean it to be an absolute URL too. But the
browser doesn't know that, and unless the website is kind enough to do
the assuming for
you (e.g. some forms conveniently display http before the textfield),
you end up with a relative URL.

Kim

0
Kim
2/19/2007 11:49:22 AM
Rimas Kudelis wrote:
> Gervase Markham wrote:
>> Rimas Kudelis wrote:
>>> I do, actually. Exactly the way Michael described (https for webmail
>>> and admin tasks, http for main webpage). And I'm sure I'm not the only
>>> one.
>> Why? Why not use different hostnames? Is it too inconvenient for you to
>> change the DNS to have two aliases for the same machine?
> 
> Because it's not always JUST mail. Plus, the problem of secure
> name-based vhosts still exists. Plus, as I said, people do type a
> different hostname. It simply redirects them to https://domain.name/

I don't understand your response, I'm afraid.

Why do you not have the equivalent of:

https://admin.foo.com/webmail -> https://100.1.1.2/webmail
https://admin.foo.com/admin -> https://100.1.1.2/admin
www.foo.com -> http://100.1.1.2/

? (The path components on the HTTPS URLs are needed, of course, because 
there is no HTTPS vhosting; but that's not a problem we can solve here.)

Gerv
0
Gervase
2/19/2007 12:12:27 PM
Kim Sullivan wrote:
> Not really - many public discussion sites (and blogs and whatnot)
> assume that URLs that are pasted without http: are relative urls
> (actually it's the browser itself that does this, the websites don't
> assume anything), people just write something like
> [url]addons.mozilla.org[/url] and post it. When the page is displayed,
> it contains a link like
> <a href="addons.mozilla.org">addons.mozilla.org</a> which usually gets
> interpreted by the browser as a relative URL, pointing to
> http://www.whateversiteyouron.com/addons.mozilla.org, and not to
> http://addons.mozilla.org

Then the blogging software is, arguably, not very usable. People do this 
already - it needs to cope. Doing nothing to the Firefox URL bar will 
not magically fix the problem. :-) Conversely, changing the Firefox URL 
bar will not increase the number of bits of software that need to be fixed.

Gerv
0
Gervase
2/19/2007 12:14:15 PM
Gervase Markham schrieb:
> Why do you not have the equivalent of:

Well, this almost sounds like you want to impose changes of websites on 
the base of the kind of UI you'd like to introduce. That sounds a bit 
backwards to me...

Robert Kaiser
0
Robert
2/19/2007 12:52:43 PM
On 2007-02-19, Gervase Markham <gerv@mozilla.org> wrote:
> Rimas Kudelis wrote:
>> I do, actually. Exactly the way Michael described (https for webmail
>> and admin tasks, http for main webpage). And I'm sure I'm not the only
>> one.
>
> Why? Why not use different hostnames? Is it too inconvenient for you to 
> change the DNS to have two aliases for the same machine?

Well, in our case it's because we can't change the DNS, because it's all
set up by the internet provider, using a hostname in their domain.

It wouldn't be too hard for me to change stuff (which I've been meaning to
do anyway) for us so it works with a new Firefox version.  The question is
whether you want to explain to everyone else in the same situation that
they need to reconfigure their DNS so it works well with Firefox 3.

-- 
Michael
0
Michael
2/19/2007 12:55:10 PM
Greg Campbell schrieb:
> Ahhh. 4 groups:
[...]
> 3. Very advanced users will appreciate how the changes could help their 
> "educated novice" family members. (see group 4)

You forgot one important group:
Advanced users who care about *their own* web experience first, not the 
one of others, and who will be annoyed if "everything works differently" 
(and yes, for those the URL bar is probably one of the most important 
parts of the browser).
Anyways, Firefox probably does not need to care too much about those, 
from how you treat them. SeaMonkey will treat them well ;-)

I just would hope that Firefox and SeaMonkey can go with a common 
approach in this area. We'll see how this discussion turns out though - 
we (SeaMonkey) will need to go with a solution that works well for our 
target audience anyways. If the Firefox solution will fit that or not is 
to be seen.

Robert Kaiser
0
Robert
2/19/2007 12:58:26 PM
Gervase Markham wrote:
> Ben Bucksch wrote:
>> So, make it very easy to replace the whole URL with a new one.
>
> Press Ctrl-L and start typing?

Discoverability? Not even I knew about it. Yeah, it's in the menu, but 
that menu item is odd, and nobody looks in the menu anyways. Surely not 
to go to a new site.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/19/2007 1:06:39 PM
Gervase Markham schrieb:
> Heikki Toivonen wrote:
>> Example Business, Inc. / shopping / basket ? id=1
>>
>> she would be likely to *type* that in an email to a friend to take a
>> look at the product, rather than copy and paste. 
> 
> Really? Do people type out entire URLs because copy and paste is beyond 
> them?

I fear they actually do, from what I heard in talks of novices...

Robert Kaiser
0
Robert
2/19/2007 1:08:47 PM
Gervase Markham schrieb:
> Ben Bucksch wrote:
>> So, make it very easy to replace the whole URL with a new one. Very 
>> obvious, no additional screen space. It's probably be unrelated to 
>> your proposal, though. (It would be related to mine, though.)
> 
> Press Ctrl-L and start typing?

Many people nowadays have no clue about keyboard shortcuts - esp. not 
about ones that aren't featured in menus.

Robert Kaiser
0
Robert
2/19/2007 1:09:54 PM
Nelson Bolyard wrote:
> Ben Bucksch wrote:
>   
>> That is the *intent*. We want to allow people to connect to self-signed
>>     
>
> who is "we"?
>   

Me, Gerv as he wrote, and quite a number of other serious Mozilla people 
I read on that subject.

I know you hate self-signed certs, partially for good reasons, but you 
have to admit that they are more secure than plain HTTP (they at least 
force sniffers to make an active attack instead of passive sniffing), 
and when we treat them the same as unsecured HTTP in our security UI, 
there's no problem with them.

Ben
0
Ben
2/19/2007 1:12:12 PM
Robert Kaiser wrote:
> Greg Campbell schrieb:
>> Ahhh. 4 groups:
> [...]
>> 3. Very advanced users will appreciate how the changes could help
>> their "educated novice" family members. (see group 4)
> 
> You forgot one important group:
> Advanced users who care about *their own* web experience first, not the
> one of others, and who will be annoyed if "everything works differently"
> (and yes, for those the URL bar is probably one of the most important
> parts of the browser).
> Anyways, Firefox probably does not need to care too much about those,
> from how you treat them. SeaMonkey will treat them well ;-)

Power users know about extensions, and know how to install them, so I
don't think it's a big problem for them indeed.

RQ
0
Rimas
2/19/2007 1:19:07 PM
Gervase Markham wrote:
>>>> I do, actually. Exactly the way Michael described (https for
>>>> webmail and admin tasks, http for main webpage). And I'm sure
>>>> I'm not the only one.
>>> Why? Why not use different hostnames? Is it too inconvenient
>>> for you to change the DNS to have two aliases for the same
>>> machine?
>> 
>> Because it's not always JUST mail. Plus, the problem of secure 
>> name-based vhosts still exists. Plus, as I said, people do type a
>>  different hostname. It simply redirects them to
>> https://domain.name/
> 
> I don't understand your response, I'm afraid.
> 
> Why do you not have the equivalent of:
> 
> https://admin.foo.com/webmail -> https://100.1.1.2/webmail 
> https://admin.foo.com/admin -> https://100.1.1.2/admin www.foo.com
> -> http://100.1.1.2/

Because we don't. :)

*.host.tld redirects to http://host.tld/
(*.)mail.host.tld redirects to https://host.tld/horde3/

It's not a problem about our users. The problem is that, in my
opinion, you're trying to oversimplify the UI of Firefox, which is
perfectly simple enough already.

Quoting Linus Torvalds on a similar discussion about Gnome:
> "This 'users are idiots, and are confused by functionality'
> mentality of Gnome is a disease. If you think your users are
> idiots, only idiots will use it. I don't use Gnome, because in
> striving to be simple, it has long since reached the point where it
> simply doesn't do what I need it to do."

RQ
0
Rimas
2/19/2007 1:30:56 PM
On Feb 19, 1:14 pm, Gervase Markham <g...@mozilla.org> wrote:
> Kim Sullivan wrote:
> > Not really - many public discussion sites (and blogs and whatnot)
> > assume that URLs that are pasted without http: are relative urls
> > (actually it's the browser itself that does this, the websites don't
> > assume anything), people just write something like
> > [url]addons.mozilla.org[/url] and post it. When the page is displayed,
> > it contains a link like
> > <a href="addons.mozilla.org">addons.mozilla.org</a> which usually gets
> > interpreted by the browser as a relative URL, pointing to
> >http://www.whateversiteyouron.com/addons.mozilla.org, and not to
> >http://addons.mozilla.org
>
> Then the blogging software is, arguably, not very usable. People do this
> already - it needs to cope. Doing nothing to the Firefox URL bar will
> not magically fix the problem. :-) Conversely, changing the Firefox URL
> bar will not increase the number of bits of software that need to be fixed.

I think the problem is that people don't realize the http:// is part
of the URL (since its http most of the time, why not omit it?).
Removing it completely will only validate this feeling and make it
worse, and those people who might have "got" it won't even have a
chance (except for figuring out why http mysteriously appears when
they try to copy'n'paste an address from the address bar, and
mysteriously disappears when you paste an URL from somewhere else).

Will it be possible to switch the scheme? Some (arguably, not very
usable) sites offer both http and https access, currently it's a
matter of changing a letter in the url.

But I see that I won't be able to convince you anyway ;-) At least
make it easily configurable via options to show the scheme (don't
hardcode the assumption that the scheme isn't displayed).

0
Kim
2/19/2007 1:51:18 PM
On 2/19/07, Robert Kaiser <kairo@kairo.at> wrote:
> Gervase Markham schrieb:
> > Press Ctrl-L and start typing?
>
> Many people nowadays have no clue about keyboard shortcuts - esp. not
> about ones that aren't featured in menus.

Yeah, I think that's why File->Open Location is there (as it has been,
with the accel-L binding, I believe since the days of Mosaic and in
all IE versions I can recall).

Mike
0
Mike
2/19/2007 2:00:31 PM
On 2/19/07, AhT Lairo DOhT com"@lists.mozilla.org Peter Lairo <"Peter> wrote:
> Gervase Markham wrote on 19.02.2007 11:09:
> > Ben Bucksch wrote:
> >> So, make it very easy to replace the whole URL with a new one. Very
> >> obvious, no additional screen space. It's probably be unrelated to
> >> your proposal, though. (It would be related to mine, though.)
> >
> > Press Ctrl-L and start typing?
>
> Discoverable? Easily discoverable? Complies with usage habits?

Menu item with a keybinding, and it's been the same way in IE and
Netscape for likely a decade?  I'd say "yes".

Mike
0
Mike
2/19/2007 2:04:48 PM
On 2/19/07, Gervase Markham <gerv@mozilla.org> wrote:
> Not really. Because it only gives the opportunity to hide what the URL
> is _within_ a particular domain - and all that content should be under
> the control of the same person.

"Should" and $3 will get you a latte, of course, even if that were to
be universally accepted (which I would personally dispute).  Myspace,
blog hosting sites, etc.

> Phishing relies on confusion about the domain.

Phishing relies on confusion about authenticity of the content; domain
similarities are just one trick of dozens possible.

Many, _many_ phishing attacks, which I have no reason to believe
suffer from decreased effectiveness, don't bother with a domain at
all, or use ones that are totally unrelated to the attack they're
performing.

Mike
0
Mike
2/19/2007 2:09:25 PM
Ben Bucksch wrote:
> I know you hate self-signed certs, partially for good reasons, but you 
> have to admit that they are more secure than plain HTTP (they at least 
> force sniffers to make an active attack instead of passive sniffing), 
> and when we treat them the same as unsecured HTTP in our security UI, 
> there's no problem with them.

Nelson: I bow to your superior security expertise, but if you object to 
the principle of showing self-signed cert connections as if they were 
identical to a plain HTTP connection, I'd be interested in your rationale.

Gerv
0
Gervase
2/19/2007 2:23:34 PM
Mike Shaver wrote:
> On 2/19/07, Gervase Markham <gerv@mozilla.org> wrote:
>> Not really. Because it only gives the opportunity to hide what the URL
>> is _within_ a particular domain - and all that content should be under
>> the control of the same person.
> 
> "Should" and $3 will get you a latte, of course, even if that were to
> be universally accepted (which I would personally dispute).  Myspace,
> blog hosting sites, etc.

OK, let's look at it the other way round. What extra possibilities of 
confusion or exploit are there for decoded URLs as opposed to encoded 
ones? Can someone give two URLs which are clearly and meaningfully 
different when encoded, but similar when decoded?

>> Phishing relies on confusion about the domain.
> 
> Phishing relies on confusion about authenticity of the content; domain
> similarities are just one trick of dozens possible.
> 
> Many, _many_ phishing attacks, which I have no reason to believe
> suffer from decreased effectiveness, don't bother with a domain at
> all, or use ones that are totally unrelated to the attack they're
> performing.

That just shows that some people are easily fooled - in other words, 
they are fooled by the content area, and don't even get as far as the 
URL bar - even if it displays 17.15.23.65 rather than www.paypal.com. 
This is, obviously, a problem, but not one changes to the URL bar can 
affect.

Gerv
0
Gervase
2/19/2007 2:27:49 PM
Kim Sullivan wrote:
> But I see that I won't be able to convince you anyway ;-) 

See the version 1.1 proposal. Is that better?

Gerv
0
Gervase
2/19/2007 2:28:38 PM
Mike Shaver wrote:
> Many, _many_ phishing attacks, which I have no reason to believe
> suffer from decreased effectiveness, don't bother with a domain at
> all, or use ones that are totally unrelated to the attack they're
> performing.

OK, but if anything Gerv's proposal *improves* the situation by making 
the domain really jump into your eye, no?

Or were you talking about URL decoding of the URL path specifically? I 
don't care much, I don't see how that makes things worse. Even on hosts 
with multiple users which are differentiated using the username in the 
start of the URL path.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/19/2007 3:13:34 PM
On 2/19/07, Ben Bucksch <ben.bucksch.news@beonex.com> wrote:
> Mike Shaver wrote:
> > Many, _many_ phishing attacks, which I have no reason to believe
> > suffer from decreased effectiveness, don't bother with a domain at
> > all, or use ones that are totally unrelated to the attack they're
> > performing.
>
> OK, but if anything Gerv's proposal *improves* the situation by making
> the domain really jump into your eye, no?

I was replying only to the portion that I quoted, which asserted that
phishing relied on domain confusion.  I have no way of knowing if
Gerv's proposal will improve the situation, but past studies on the
effectiveness of _any_ non-modal site authenticity indicators would
keep me from betting on it, I think.

Mike
0
Mike
2/19/2007 4:17:01 PM
On Feb 19, 3:27 pm, Gervase Markham <g...@mozilla.org> wrote:
> Mike Shaver wrote:
> > On 2/19/07, Gervase Markham <g...@mozilla.org> wrote:
> >> Not really. Because it only gives the opportunity to hide what the URL
> >> is _within_ a particular domain - and all that content should be under
> >> the control of the same person.
>
> > "Should" and $3 will get you a latte, of course, even if that were to
> > be universally accepted (which I would personally dispute).  Myspace,
> > blog hosting sites, etc.
>
> OK, let's look at it the other way round. What extra possibilities of
> confusion or exploit are there for decoded URLs as opposed to encoded
> ones? Can someone give two URLs which are clearly and meaningfully
> different when encoded, but similar when decoded?

I believe that the original concern here was related specifically to
long strings of decoded whitespace that could overflow the address
bar. I think that other characters could be considered "safe" for
showing as characters. Probably more safe - while decoded homographs
could be problem, an UTF-8 url-encoded CJK string looks similar even
when the characters really are different... it's just a string of
hexadecimal numbers separated with percent signs.

I, too, don't think that decoded whitespace in the path part of an URL
could pose a serious security threat (especially since people fall for
much simpler things). But even if it wasn't (and you can never be sure
of that until someone tries to exploit it), it would be really
inconvenient if someone could "hide" parts of an URL in the address
bar using whitespace.

I'm sure someone would think, "hey, that's cool, I can hide the ugly
GET request using whitespace". Even on legitimate sites, some people
would use URLs like
http://www.example.com/survey-form/
/get-method-handler.php?sensitive-data=xxx&other-sensitive-data=yyy
(imagine lots of spaces between survey-form and get-method-
handler.php).

Kim

0
Kim
2/19/2007 6:39:21 PM
Mike Shaver schrieb:
> On 2/19/07, Robert Kaiser <kairo@kairo.at> wrote:
>> Gervase Markham schrieb:
>> > Press Ctrl-L and start typing?
>>
>> Many people nowadays have no clue about keyboard shortcuts - esp. not
>> about ones that aren't featured in menus.
> 
> Yeah, I think that's why File->Open Location is there (as it has been,
> with the accel-L binding, I believe since the days of Mosaic and in
> all IE versions I can recall).

The menu item is Ctrl+Shift+L here in SeaMonkey and opens a separate 
window for input, while Ctrl+L take you to the URL bar (and that 
shortcut isn't visible anywhere in the UI). I don't think we have 
changed this from Mozilla 1.x to SeaMonkey - Firefox might have, though, 
I don't know about its UI that well.

Robert Kaiser
0
Robert
2/19/2007 7:10:24 PM
Ben Bucksch schrieb:
> I know you hate self-signed certs, partially for good reasons, but you 
> have to admit that they are more secure than plain HTTP (they at least 
> force sniffers to make an active attack instead of passive sniffing), 
> and when we treat them the same as unsecured HTTP in our security UI, 
> there's no problem with them.

For the plain reason that they are at least immune against passive 
sniffing, I think there should still be some indication that they are 
different from real plain HTTP. Not sure though what indication is best 
for that.

Robert Kaiser
0
Robert
2/19/2007 7:12:36 PM
Robert Kaiser wrote:
> Mike Shaver schrieb:
>> On 2/19/07, Robert Kaiser <kairo@kairo.at> wrote:
>>> Gervase Markham schrieb:
>>> > Press Ctrl-L and start typing?
>>>
>>> Many people nowadays have no clue about keyboard shortcuts - esp. not
>>> about ones that aren't featured in menus.
>>
>> Yeah, I think that's why File->Open Location is there (as it has been,
>> with the accel-L binding, I believe since the days of Mosaic and in
>> all IE versions I can recall).
> 
> The menu item is Ctrl+Shift+L here in SeaMonkey and opens a separate
> window for input, while Ctrl+L take you to the URL bar (and that
> shortcut isn't visible anywhere in the UI). I don't think we have
> changed this from Mozilla 1.x to SeaMonkey - Firefox might have, though,
> I don't know about its UI that well.

In Firefox, Ctrl+N opens a separate window, while Ctrl+L focuses the
address bar. Both are available in File menu.

RQ
0
Rimas
2/19/2007 7:18:59 PM
Rimas Kudelis wrote:
> Robert Kaiser wrote:
>> Mike Shaver schrieb:
>>> On 2/19/07, Robert Kaiser <kairo@kairo.at> wrote:
>>>> Gervase Markham schrieb:
>>>>> Press Ctrl-L and start typing?
>>>> Many people nowadays have no clue about keyboard shortcuts - esp. not
>>>> about ones that aren't featured in menus.
>>> Yeah, I think that's why File->Open Location is there (as it has been,
>>> with the accel-L binding, I believe since the days of Mosaic and in
>>> all IE versions I can recall).
>> The menu item is Ctrl+Shift+L here in SeaMonkey and opens a separate
>> window for input, while Ctrl+L take you to the URL bar (and that
>> shortcut isn't visible anywhere in the UI). I don't think we have
>> changed this from Mozilla 1.x to SeaMonkey - Firefox might have, though,
>> I don't know about its UI that well.
> 
> In Firefox, Ctrl+N opens a separate window, while Ctrl+L focuses the
> address bar. Both are available in File menu.
> 
> RQ

In SeaMonkey, Ctrl-Shift-L opens a popup:

(*) Open Web Location                                                  [_] [X]
Enter the Web location (URL) or specify the local page you would like to open:
[___________________________________________________] [Choose File...]

Open in: [ Current Navigator Window |v]
          | New Navigator Window     |
          | New Navigator Tab        |              [ Open ] [ Cancel ]
          |--------------------------|
          | New Composer Window      |
          |__________________________|


Ctrl-L (undocumented in Sm) focuses the Location Bar and selects its contents 
(as in Fx). Ctrl-N opens a new window (on the homepage, I think) in both Fx 
and Sm.


Best regards,
Tony.
-- 
When the weight of the paperwork equals the weight of the plane, the
plane will fly.
		-- Donald Douglas
0
Tony
2/19/2007 7:54:43 PM
Mardak wrote:

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

[Sorry, OT alert!]

Make sure you don't run afoul of the California Republican Party, which 
believes that this sort of stuff is "hacking the server" and "stealing 
intellectual property". (:-))

Some Democratic activists did this on a site with Gov. Schwartzenegger's 
radio addresses, and found some unedited audio clips in the directory 
listing, with really embarrassing outtakes from Arnie.

The Republican Party then forced the California Highway Patrol (!) to 
file theft and hacking charges against the activists, and do a 6-month 
"preliminary investigation", before they realized how stupid it all was..
0
Shankar
2/19/2007 8:25:46 PM
On Feb 19, 3:28 pm, Gervase Markham <g...@mozilla.org> wrote:
> Kim Sullivan wrote:
> > But I see that I won't be able to convince you anyway ;-)
>
> See the version 1.1 proposal. Is that better?
>
> Gerv

Yes, definitely an improvement, thanks for considering it. I'm a bit
worried about the shifting (not only from an accessibility
standpoint), but it remains to be seen how it works out in usability
testing.

Kim

0
Kim
2/19/2007 8:50:12 PM
Robert Kaiser wrote:
> For the plain reason that they are at least immune against passive 
> sniffing, I think there should still be some indication that they are 
> different from real plain HTTP. Not sure though what indication is best 
> for that.

The problem as I see it is that we need to come up with an indicator 
which does both of these things:

- Does _not_ give 99% of users any sense of being more "secure"
- Tells the 1% of users that the specific, limited non-eavesdroppability 
they wanted is in place.

I'm half-thinking that the UI for this should be an extension, installed 
by those who are using such connections.

Gerv
0
Gervase
2/20/2007 9:58:42 AM
Kim Sullivan wrote:
> I believe that the original concern here was related specifically to
> long strings of decoded whitespace that could overflow the address
> bar. I think that other characters could be considered "safe" for
> showing as characters. Probably more safe - while decoded homographs
> could be problem, an UTF-8 url-encoded CJK string looks similar even
> when the characters really are different... it's just a string of
> hexadecimal numbers separated with percent signs.

Exactly. There's significant upsides to decoding.

> I, too, don't think that decoded whitespace in the path part of an URL
> could pose a serious security threat (especially since people fall for
> much simpler things). But even if it wasn't (and you can never be sure
> of that until someone tries to exploit it), it would be really
> inconvenient if someone could "hide" parts of an URL in the address
> bar using whitespace.

Let's think about the set of URLs that could be confused. As I see it, 
you can confuse:

http://www.example.com/some/path/
with
http://www.example.com/some/path/<spaces>something else

I can't come up with anything dangerous. Take the myspace case. People get:

myspace.com/fredbloggs

They could construct a URL that was

myspace.com/fredbloggs<spaces>something else

and try and pretend to be myspace.com/fredbloggs - but they already own 
that! There's no way they can pretend to be the root of myspace.com. We 
don't offer ^H (backspace) as a character :-)

> I'm sure someone would think, "hey, that's cool, I can hide the ugly
> GET request using whitespace". 

In some browsers. Perhaps.

> Even on legitimate sites, some people
> would use URLs like
> http://www.example.com/survey-form/
> /get-method-handler.php?sensitive-data=xxx&other-sensitive-data=yyy
> (imagine lots of spaces between survey-form and get-method-
> handler.php).

They can do that today with a long string of underscores or plus signs 
or various things. But no-one bothers.

Gerv
0
Gervase
2/20/2007 10:02:57 AM
Gervase Markham wrote:
> Robert Kaiser wrote:
>> For the plain reason that they are at least immune against passive 
>> sniffing, I think there should still be some indication that they are 
>> different from real plain HTTP. Not sure though what indication is 
>> best for that.
> 
> The problem as I see it is that we need to come up with an indicator 
> which does both of these things:
> 
> - Does _not_ give 99% of users any sense of being more "secure"
> - Tells the 1% of users that the specific, limited non-eavesdroppability 
> they wanted is in place.

Showing the protocol on hover/focus probably does that.
0
Dao
2/20/2007 10:51:28 AM
Even though Locationbar^2 is not the explicit topic here, note that 
recent versions encode spaces, mainly because copying URLs with plain 
spaces is useless and I was convinced that the formatted and editable 
views should differ as less as possible (for easy selecting).
0
Dao
2/20/2007 10:56:33 AM
Dao Gottwald wrote:
> Showing the protocol on hover/focus probably does that.

I think you are right.

Gerv
0
Gervase
2/20/2007 12:28:35 PM
On 2/20/07, Gervase Markham <gerv@mozilla.org> wrote:
> Robert Kaiser wrote:
> > For the plain reason that they are at least immune against passive
> > sniffing, I think there should still be some indication that they are
> > different from real plain HTTP. Not sure though what indication is best
> > for that.
>
> The problem as I see it is that we need to come up with an indicator
> which does both of these things:
>
> - Does _not_ give 99% of users any sense of being more "secure"
> - Tells the 1% of users that the specific, limited non-eavesdroppability
> they wanted is in place.

The problem is that right now we only have one indicator of "secure"
and that's 1:1 related with SSL, which doesn't mean "secure".

I would suggest that what we're really looking for is an indicator of
"SSL encrypted" which could easily be shown for self-signed-cert
sights, but reserve further indicators of security (identity, trust,
etc) for certs which give us more reliable metadata.

cheers,
mike

-- 
/ mike beltzner / phenomenologist / mozilla corporation /
0
beltzner
2/20/2007 7:53:42 PM
Gervase Markham wrote:

> Where would you find a server where I have a website on port 80 and Mr. 
> Evil, who I don't know and don't trust, has a website on port 90?

Unix servers often allow regular accounts to launch processes that 
listen to arbitrary ports above 1023, so Mr. Evil could do this in at 
least these two cases:

1. Mr. Evil has access to a shared server hosting someone else's site 
good.com.  Mr. Evil starts an HTTP daemon that listens to traffic at 
port 8080 for all domains hosted on that server, so Mr. Evil controls 
the site at http://good.com:8080/.

2. Mr. Evil breaks into safe.com's web server by compromising a regular 
account on it.  The account doesn't have admin privileges or access to 
the web site, so Mr. Evil can't touch the main HTTP daemon or the files 
it serves, but he can launch his own HTTP daemon that listens to traffic 
at port 8080, so Mr. Evil controls the site at http://safe.com:8080/.

-myk
0
Myk
2/21/2007 12:40:49 AM
beltzner wrote:
> The problem is that right now we only have one indicator of "secure"
> and that's 1:1 related with SSL, which doesn't mean "secure".
>
> I would suggest that what we're really looking for is an indicator of
> "SSL encrypted" which could easily be shown for self-signed-cert
> sights, but reserve further indicators of security (identity, trust,
> etc) for certs which give us more reliable metadata.

(crypto primer:)

Problem is that encryption without signing is pretty useless. They are 
not just arbitrarily or conveniently tied. With self-signed certs, and 
assuming you don't manually check the cert fingerprint, anybody could be 
sniffing in by presenting their own cert. Sure, that would be an active 
attack, which at least stops the NSA general data warehouse and hobby 
hackers at your office, but it doesn't stop anybody who really wants to 
get at you.

Thus, self-signed certs, assuming they are not checked and/or stored, 
don't do a lot on top of HTTP. Even calling it "encrypted" would be 
severely misleading. So, in essence, they are *slightly* more secure 
than plain HTTP, but only stop casual listeners, and the difference is 
too fine for the user to care. Worse, he'd likely misunderstand it. So, 
treat it the same as plain HTTP. Maybe with a on-demand dialog, 
accessible from the menu, showing what's actually there.

(However, *if* self-signed certs are properly checked *and* stored, they 
are even more secure than the usual SSL PKI.)

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/21/2007 2:16:45 AM
Gervase Markham wrote:
> Ben Bucksch wrote:
>> Oh, Google is a great example! google.de, google.fr and google.com 
>> give totally different results. And not just due to the default 
>> language (which changes basically all results and I don't know why 
>> until I see "google.fr", a clue which would then be gone), but also 
>> the government-induced filters. Not that you enter google.com and end 
>> up at google.fr automatically, redirection based on (bad) IP address 
>> location guessing.
>
> Remember, this substition is only for HTTPS.

Well, it was just an example for the principle. There's more than just 
Google out there.

>> Stepping back from that, more generally: If you say I don't care 
>> about the hostname, why do I care about the path then? Why not drop 
>> the whole URL and have a domain only? Surely, the hostname is more 
>> significant than the path. And the second level domain more than the 
>> hostname.
> We could. That's a more radical change, but it's perhaps consistent. 
> After all, most users see it as a jumble of confusing characters...

Exactly. (and that is one reason why phishing works.) As mentioned on 
..security, I'd propose to actually do that. Show only domain, plus EV 
cert holder if available, where the URL is atm. The URLbar is still 
available as optional toolbar element via toolbar customization. And/or 
maybe in very fine print (4px) underneath the domain.

>> The port, if not the default, is just as significant as the hostname. 
>> Treat it in UI similarly (i.e. don't emphasize it, but leave it in).
>
> Myk suggested highlighting it if not the default.

I know, what's why I said that. Port is almost as significant as the 
hostname, but not more.

>>> Surely you distinguish between Google services by, er, looking at the
>>> content area? :-)
>> I thought we wanted to move people *away* from using the content area 
>> to identify where they are?
> It's a different sort of distinguishing. It's about distinguishing 
> what you are doing, as opposed to on whose site you are doing it.

Argument accepted.

>> I thought we dropped IDN? 
>
> I don't know what you mean by that. You mean from the discussion, or 
> from the product? :-)

I thought IDNs were disabled in Firefox; I'm pretty sure you announced 
at some point that they were, at least temporarily. Maybe you have 
better protections (like enforcing one language / char set only) now and 
re-enabled it, then I was wrong.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/21/2007 2:33:51 AM
Ben Bucksch wrote:
>>> The port, if not the default, is just as significant as the hostname. 
>>> Treat it in UI similarly (i.e. don't emphasize it, but leave it in).
>>
>> Myk suggested highlighting it if not the default.
> 
> I know, what's why I said that. Port is almost as significant as the 
> hostname, but not more.

Myk said highlight it, you said don't emphasize. I'd agree with you. 
Highlighting the port doesn't tell the user anything without additional 
explanation. I'd say just show it if it's not the default one - and 
that's what Firefox already does.

>>> I thought we dropped IDN? 
>>
>> I don't know what you mean by that. You mean from the discussion, or 
>> from the product? :-)
> 
> I thought IDNs were disabled in Firefox; I'm pretty sure you announced 
> at some point that they were, at least temporarily. Maybe you have 
> better protections (like enforcing one language / char set only) now and 
> re-enabled it, then I was wrong.

You can at least enable IDN for certain TLDs.
0
Dao
2/21/2007 9:27:32 AM
Ben Bucksch wrote:
> I thought IDNs were disabled in Firefox; I'm pretty sure you announced 
> at some point that they were, at least temporarily. Maybe you have 
> better protections (like enforcing one language / char set only) now and 
> re-enabled it, then I was wrong.

We now enable IDN for a whitelist of some 30 TLDs, who have policies in 
place to prevent homograph spoofing.
http://www.mozilla.org/projects/security/tld-idn-policy-list.html

Gerv
0
Gervase
2/21/2007 9:54:53 AM
Rimas Kudelis wrote:
> Gervase Markham wrote:
>> Rimas Kudelis wrote:
>>> I do, actually. Exactly the way Michael described (https for webmail
>>> and admin tasks, http for main webpage). And I'm sure I'm not the only
>>> one.
>> Why? Why not use different hostnames? Is it too inconvenient for you to
>> change the DNS to have two aliases for the same machine?
> 
> Because it's not always JUST mail. 
> Plus, the problem of secure name-based vhosts still exists. 

Not really.  FF2 now fully supports the TLS "server name indication"
extension, which sends the server a clue about the desired virtual host
name in the handshake.  All you need is a server that supports SNI.

> Plus, as I said, people do type a
> different hostname. It simply redirects them to https://domain.name/
> 
> RQ
0
Nelson
2/21/2007 2:30:07 PM
Gervase Markham wrote:
> Robert Kaiser wrote:
>> For the plain reason that they are at least immune against passive
>> sniffing, I think there should still be some indication that they are
>> different from real plain HTTP. Not sure though what indication is
>> best for that.
> 
> The problem as I see it is that we need to come up with an indicator
> which does both of these things:
> 
> - Does _not_ give 99% of users any sense of being more "secure"
> - Tells the 1% of users that the specific, limited non-eavesdroppability
> they wanted is in place.

Yes, that is the challenge.  Will FF UI folks accept that challenge?

0
Nelson
2/21/2007 2:33:27 PM
beltzner wrote:
> On 2/20/07, Gervase Markham <gerv@mozilla.org> wrote:
>> Robert Kaiser wrote:
>> > For the plain reason that they are at least immune against passive
>> > sniffing, I think there should still be some indication that they are
>> > different from real plain HTTP. Not sure though what indication is best
>> > for that.
>>
>> The problem as I see it is that we need to come up with an indicator
>> which does both of these things:
>>
>> - Does _not_ give 99% of users any sense of being more "secure"
>> - Tells the 1% of users that the specific, limited non-eavesdroppability
>> they wanted is in place.
> 
> The problem is that right now we only have one indicator of "secure"
> and that's 1:1 related with SSL, which doesn't mean "secure".

Mike, the only people who claim that the lock means "secure" are the people
who want to do away with it.

The lock means "page received over connection(s) that were authenticated
and encrypted".  If that's too much of a mouthful for a sound bite, then
boil it down to "authenticated", not "encrypted".

> I would suggest that what we're really looking for is an indicator of
> "SSL encrypted" which could easily be shown for self-signed-cert
> sights, but reserve further indicators of security (identity, trust,
> etc) for certs which give us more reliable metadata.

IMO That would give 99% of the users the false sense of being more "secure".

> cheers,
> mike
> 
0
Nelson
2/21/2007 2:39:09 PM
Gervase Markham <gerv@mozilla.org> writes:

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

These are good goals.

> Suggested Changes:
> 
> 1) Hide the scheme
> 
> The scheme (e.g. "http://", "ftp://") should be hidden permanently
> for HTTP, HTTPS, FTP and file URLs. 
  
Perhaps.  I agree with the sentiment behind this, but if the user
inadvertently types (say) ftp.gmd.de by mistake (neglecting to prepend
the ftp:// protocol signifier), there needs to be an easy way for the
user to change the assumed http:// to what it should be.

Perhaps when the thing goes into editable-textbox-mode (see below),
then the scheme should be present, but otherwise not.
  
> FTP could have a special favicon, as could file://.

Agreed.

> 2) Hide username and password

Agreed.  Not sure why they were ever shown in the first place.
Practically every computer interface in the history of the universe at
the very least _obscures_ passwords, and hiding them altogether is
common.  In the context of the location bar, I don't think the
username is really relevant either (for http anyway -- perhaps for
non-anonymous ftp, since it often does get you access to a different
set of directories in that case, and could thus be considered
meaningful location information).

> 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

Makes sense.

> Clicking the hostname "button" takes you back to the root of the site

Okay.

> For file URLs, you'd get:
> 
> [C:] /Program Files/Firefox/
> 
> on Windows, and

No.  (More in a moment.)

> [/] home/gerv/test/
> 
> on Unix. 

Yes.  And on Windows:
[C:/] Program Files/Firefox/
[//production/publicfiles/] html/welcome-2007-01.html

That leaves the question of what to do about special directories like
the user's home dir (on Unix) or My Documents (on Windows).  Yes, it
*has* a canonical form as above, but it _probably_ should be shown in
some fashion as being what it is -- the current user's home dir.

One obvious way to do that on Unix:
[~/] foo/bar.html
Perhaps on Windows the equivalent could be something like
[My Documents/] foo/bar.html

In other words, treat it as a (virtual) root of its own.  Multi-rooted
filesystems often have virtual roots anyway, a la drive letters
assigned via SUBST on DOS, UNC pathnames on Win32 (which can indeed
refer back to directories on C: if the current system has shares), or
SYS$WHATEVER on VMS.  It might feel slightly odd on Unix, but only
slightly, because every Unix shell I've ever heard of supports ~/ as
if it were a virtual filesystem root.  If there are single-rooted
systems other than Unix, they're special cases IMO and the issue can
be addressed by a porting team.

Be aware, however, that it is _possible_ for the My Documents
directory to be somewhere other than the default location, and
although it is somewhat unusual, Firefox should probably be aware of
it.  TweakUI for instance lets the user change this.

> Yes, these two are inconsistent with respect to the placement of the
> initial slash. 

Inconsistency fixed.  HTH.HAND.

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

Agreed.  Don't do that.

> 4) Display EV business name and country

I am not against displaying this information, BUT...

> 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

Ack, no!  For the love of all that is sane, no.  That sounds like
something Microsoft would come up with, right along the same lines as
replacing server-generated 404s with the same error message used when
name resolution fails.  Doubleplusungood.  Rethink fullwise.

An important part (perhaps *the* most important part) of the function
of the location bar is that whatever the user sees there is a
location, i.e., a globally-unique address.  Currently, anything the
user sees there can be typed back in at a later time and the same site
retrieved again.  Thus it has been since NCSA Mosaic.  This is almost
as important a UI feature as the back button.  Breaking it is eleven
different kinds of insane.  

And no, the user doesn't necessarily already know what it is, because
he didn't necessarily type it to get there.  He may have, for
instance, followed a link.  Yes, there's bookmarking, but that small
comfort to users who aren't on their regular computer at the time.

End users have *enough* trouble keeping straight the difference
between search terms and addresses as it is.  This proposal would
increase the confusion tenfold.

And no, I most certainly do not want groups.google.com and
mistersanity.blogspot.com and www.gmail.com to all show as being the
same site.  They aren't, ownership notwithstanding.  Nor should
slashdot and sourceforge show as the same site.  They aren't.

I'm not against showing the flag, or even displaying the company name
if you can find a place for it, but the FQDN *MUST* still be shown.
We need to know what site it is *far more* than we need to know what
company owns it.  Both would be nice, but if we have to pick, we've
gotta show what site it is.

> 5) Remove the favicon from the URL bar entirely

Perhaps.  I'll let others discuss the merits of this one, except that
I will say...

> I admit there's further thinking to do here.

There is that.

> 6) Focus turns bar back to a text box

I like this one.  A lot.  It's elegant.  It gets dual use out of a
single piece of screen real estate.  It makes certain problems (e.g.,
the ability to change the scheme if #1 is implemented) just go away.
There may be some details to work out, but overall this is a keeper.

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

This is okay as far as it goes, but *don't* screw around with how
dragging works.  Some word processing programs do that, and it makes
it really hard to select what you want in certain cases, particularly
when what you want crosses a word boundary.  Leave dragging alone.

But the double-click and triple-click stuff is fine by me.

> Again, I don't know if this is a can of worms - I suspect URL bar
> selection behaviour has been discussed before.

Undoubtedly.

> 8) Analyse font choice carefully

Yeah.  I'd suggest Andale Mono as a font that does a good job of
making all printable ASCII characters look distinct from one another,
but I doubt if you can get permissions to distribute that one in the
manner that you'd want to do (i.e., *not* in its exe-wrapped-cabinet
original form).  So you'll probably have to find another font that
does a similarly good job of that.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/21/2007 3:26:08 PM
Ben Bucksch wrote:

> Problem is that encryption without signing is pretty useless. 

I think you mean "without authentication".
Authentication is much more than mere signing.

>`They are
> not just arbitrarily or conveniently tied. With self-signed certs, and
> assuming you don't manually check the cert fingerprint, anybody could be
> sniffing in by presenting their own cert. Sure, that would be an active
> attack, which at least stops the NSA general data warehouse and hobby
> hackers at your office, but it doesn't stop anybody who really wants to
> get at you.
> 
> Thus, self-signed certs, assuming they are not checked and/or stored,
> don't do a lot on top of HTTP. Even calling it "encrypted" would be
> severely misleading. So, in essence, they are *slightly* more secure
> than plain HTTP, but only stop casual listeners, and the difference is
> too fine for the user to care. Worse, he'd likely misunderstand it. So,
> treat it the same as plain HTTP. Maybe with a on-demand dialog,
> accessible from the menu, showing what's actually there.

self signed certs off NO proof of identity.  Or as some security
researchers sarcastically call it: "proof by assertion".

"I'm George Bush and you should believe it because I said so."
That's the only proof of identity of any self-signed cert.

Our UI should make it impossible to see the subject name and issuer
name of a self-signed cert.  Otherwise, users will be fooled into
thinking that the name in the cert is trustworthy, because it's in a
cert and ALL certs are trustworthy, regardless of issuer, aren't they?

> (However, *if* self-signed certs are properly checked *and* stored, they
> are even more secure than the usual SSL PKI.)

Two issues with that.

1. There is absolutely no revocation mechanism.  If the private key for
the self-signed cert is compromised, you have no way of finding that out.

2. NO ONE ever does "proper checking".  Proper checking involves checking
the "fingerprint" of the cert with the party named in the cert through
some out-of-band mechanism, some other channel that cannot be attacked in
the same way by the same attacker.  Confirming fingerprints by voice over
the phone is the classic example of how to do it.

NO ONE ever does that!  Instead, all SSH users use a model where they
assume that the first time they contact a host, they are not being spoofed.
They take the initial cert at face value and store it without any checking
at all.  They assume that they were not being attacked in that first visit.

This scheme works well enough for SSH users today because most SSH servers
are low value targets, not worth the effort of an MITM attack.  But if it
became the way that browsers identified the users' bank's certificates,
it would be a disaster.

It has been proposed that FF should accept and remember any cert for any
SSL server on first encounter with that server, without any dialogs at all.
No reliance on ANY CAs.  Self-signed or not, wouldn't matter.  Thereafter,
always compare the received cert with the previously stored one, and
complain if it changes.  All certs are validated by comparing with last
known value.  This is called "opportunistic encryption".  I oppose it.

Let me describe what would happen if that plan were actually to be
implemented.  MITM attacks would become RAMPANT.  Every proxy server
would become a MITM attacker.  It would be like the infamous Netsetter
MITM proxy, on steroids.  ISPs would soon MITM all SSL connections to/from
their subscribers, under pressure from the FBI/CIA/NSA/carnivore-du-jour.
There would be multiple MITMs on a single connection.  The temptation
would be just too great.  mod_ssl would be overtaken by mod_MITM in
popularity.

DNS cache poisoning would become rampant, because it would actually work.
(SSL detects such attacks today and prevents them, so they're rare.)

There would be a huge outpouring of phishing email, the likes of which
has never before been seen.  Every bad guy would want you to visit HIS
MITM site first, before visiting your bank's real server, so that you
would have the MITM's cert, and not your bank's cert, in your cert store.

If you happened to get the real IP address of your bank, and you visited
your bank's real site, you'd get the "cert has changed" dialog, which
would further discourage most users from trusting the real site, and
encourage them to trust the MITM site instead.

SSL/PKI's big PR problem is that it got started before the attackers were
very sophisticated.  It prevented a huge class of attacks from ever getting
started.  People don't appreciate the value of that protection because
they've never experienced the web without it.  It might have been better
if SSL/PKI hadn't gotten started until the web had matured a bit more,
and attacks had been rampant.  If even 1% of web users had memories of
the bad old days when they had no security (no secrecy, no authentication)
for their communications, SSL/PKI would be seen as heroic instead of as a
nuisance.
0
Nelson
2/21/2007 3:39:35 PM
Jeff Walden <jwalden+nmo@mit.edu> writes:

> More likely it's not generally useful -- the set of users who need
> to upload files via FTP is small 

Small relative to those who browse the web, but still much larger
than, say, those who use usenet.  A full internet suite certainly
ought to support it.  However...

> and is often better served by a real uploading application.

For Firefox, I would say this is a good position to take.  It works
well by analogy to also recommending a separate email client, separate
newsreader, and so forth.  

A proper ftp client has by necessity a very different interface from a
web browser, and it doesn't fit into the browsing interface.  The
whole design of Firefox is predicated on *not* supporting every
popular protocol on the web, just the ones that fit into a
web-browsing paradigm.  Of course there is an ftp extension for
Firefox, and that's fine, but ftp upload is beyond the scope of what
Firefox is intended to do.  Not so much in terms of functionality
(web-form-based file uploads are supported after all), but in terms of
user interface, ftp uploads just don't belong.  For one thing, it's
hard to imagine a decently usable graphical ftp interface that doesn't
have some kind of split view with the local system in one half and the
remote system in the other half, and that's just totally out of place
in a web browser window.

As noted, the full suite *should* have it, but that's different.  A
full internet application suite needs to support all the major
standard app-layer protocols: HTTP, POP3, SMTP, IMAP, FTP, SSH, NNTP,
IRC, VOIP, BitTorrent, Jabber, SSL-based versions of those where
appropriate, and probably utility protocols (ping and traceroute and
whois and so forth), as well.  Because it's a full suite.  Firefox
isn't.  It's a web browser.

Anon ftp downloads are different, because web pages frequently link to
them, and the user clicks and expect it to work.  And ftp is a
sufficiently simple and well-understood protocol that making it Just
Work like that is easy enough.  It adds no significant complexity to
the UI and I suspect not much to the footprint either.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/21/2007 4:53:29 PM
Ben Bucksch wrote:
> Problem is that encryption without signing is pretty useless. They are 
> not just arbitrarily or conveniently tied. With self-signed certs, and 
> assuming you don't manually check the cert fingerprint, anybody could be 
> sniffing in by presenting their own cert. Sure, that would be an active 
> attack, which at least stops the NSA general data warehouse and hobby 
> hackers at your office, but it doesn't stop anybody who really wants to 
> get at you.

As dmose points out in bug 228684, comment 47 
<https://bugzilla.mozilla.org/show_bug.cgi?id=228684#c47>, it's 
significantly harder to launch a MITM attack than it is to merely sniff 
packets in some common cases like open wireless networks, so encryption 
without authentication does make a difference.

Nevertheless, I agree that the difference is probably not significant 
for most users of browsers (although it is significant for many mail 
users), so it probably does make sense not to indicate the 
encrypted-but-not-authenticated state by default, as per the current 
proposal (except, of course, via the presence of the "s" when viewing 
the entire URL on hover/edit).

-myk
0
Myk
2/21/2007 5:41:17 PM
Jonadab the Unsightly One wrote:
[...]
> A proper ftp client has by necessity a very different interface from a
> web browser, and it doesn't fit into the browsing interface.  The
> whole design of Firefox is predicated on *not* supporting every
> popular protocol on the web, just the ones that fit into a
> web-browsing paradigm.  Of course there is an ftp extension for
> Firefox, and that's fine, but ftp upload is beyond the scope of what
> Firefox is intended to do.  Not so much in terms of functionality
> (web-form-based file uploads are supported after all), but in terms of
> user interface, ftp uploads just don't belong.  For one thing, it's
> hard to imagine a decently usable graphical ftp interface that doesn't
> have some kind of split view with the local system in one half and the
> remote system in the other half, and that's just totally out of place
> in a web browser window.
[...]

Just FYI, Konqueror doesn't have that split view. It shows one (remote or 
local) directory at a time (in tabs with a file: or ftp: directory URL -- 
there are others of course). To upload by FTP, highlight one or more files in 
the local folder, drag them to the tab for the remote folder (don't release 
the mouse: the tab opens) then drop them in the contents area and you get a 
popup: "Move Here / Copy Here / Link Here / Cancel". Similarly for download 
(and regardless of whether it's authenticated FTP or anonymous FTP).


Best regards,
Tony.
-- 
Barometer, n.:
	An ingenious instrument which indicates what kind of weather we
are having.
		-- Ambrose Bierce, "The Devil's Dictionary"
0
Tony
2/21/2007 5:44:49 PM
Nelson Bolyard wrote:
>> `They are
>> not just arbitrarily or conveniently tied. With self-signed certs, and
>> assuming you don't manually check the cert fingerprint, anybody could be
>> sniffing in by presenting their own cert. Sure, that would be an active
>> attack, which at least stops the NSA general data warehouse and hobby
>> hackers at your office, but it doesn't stop anybody who really wants to
>> get at you.
>>
>> Thus, self-signed certs, assuming they are not checked and/or stored,
>> don't do a lot on top of HTTP. Even calling it "encrypted" would be
>> severely misleading. So, in essence, they are *slightly* more secure
>> than plain HTTP, but only stop casual listeners, and the difference is
>> too fine for the user to care. Worse, he'd likely misunderstand it. So,
>> treat it the same as plain HTTP. Maybe with a on-demand dialog,
>> accessible from the menu, showing what's actually there.
>>     
>
> self signed certs off NO proof of identity. ... "I'm George Bush and you should believe it because I said so."
>   

Has anybody said that we want to use self-signed certs for that? The 
word "identity" doesn't even appear in my text. I said "anybody could 
sniff in". You're changing subjects, trying to lead the discussion 
elsewhere than it went. The question simply was: Are self-signed certs 
*less* secure than plain HTTP, if it's presented the same as plain HTTP?

>> (However, *if* self-signed certs are properly checked *and* stored, they
>> are even more secure than the usual SSL PKI.)
>>     
>
> Two issues with that.
>
> 1. There is absolutely no revocation mechanism.  If the private key for
> the self-signed cert is compromised, you have no way of finding that out.
>
> 2. NO ONE ever does "proper checking".  Proper checking involves checking
> the "fingerprint" of the cert with the party named in the cert through
> some out-of-band mechanism

You are thinking of totally different usecases than the people using 
self-signed certs are. Think of a 3-man company, or a personal host, or 
whatever. The "revocation mechanism" there is to tell the person "hey, I 
goofed, there'll be a new cert". The "proper cert checking" can happen 
by simply using it on the private Ethernet or whatever, where no MITM is.

I am sure that my SSH connections are fine, because I *physically*, 
directly, connected to the most critical servers at some point in time, 
because they are my machines. SSH would have jumped up and down, if the 
key changed afterwards when I'm connecting over the Internet. Not so 
with PKI, there are third parties involved, and new certs can be used 
without me noticing, which is why I would not be able to be as sure 
about the Internet connection.

> It has been proposed that FF should accept and remember any cert for any
> SSL server on first encounter with that server, without any dialogs at all.
> No reliance on ANY CAs.

FWIW, I am not proposing to get rid of CAs for normal webshops. CAs can 
work fine there.

> always compare the received cert with the previously stored one, and
> complain if it changes.  All certs are validated by comparing with last
> known value.
>   

I think that part would dramatically improve security of SSL. Some time 
ago, I opened a thread in .security or .crypto about that, so let's keep 
that discussion there, it's not really relevant here.

> Let me describe what would happen if that plan were actually to be
> implemented.  MITM attacks would become RAMPANT.  Every proxy server
> would become a MITM attacker.

You are totally misunderstanding or misrepresenting this.

> MITM ... under pressure from the FBI/CIA/NSA/carnivore-du-jour
>   

(Right. As if the govt had absolutely no access to VeriSign. If it would 
happen then, it happens now already. Which is exactly what storing keys 
would *prevent*.)


-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/21/2007 7:35:32 PM
On 2/21/07, Myk Melez <myk@mozilla.org> wrote:
> As dmose points out in bug 228684, comment 47
> <https://bugzilla.mozilla.org/show_bug.cgi?id=228684#c47>, it's
> significantly harder to launch a MITM attack than it is to merely sniff
> packets in some common cases like open wireless networks, so encryption
> without authentication does make a difference.

Sadly, there are out-of-the-box MITM attack tools available (widely!)
for use with open wireless networks, so I'm not actually sure that's
true any more.

Mike
0
Mike
2/21/2007 7:39:12 PM
Nelson Bolyard wrote:
> Mike, the only people who claim that the lock means "secure" are the people
> who want to do away with it.
>   

No, it's what users think when they see a lock.

I mean, your private home territory in CVS is called security/ ! How can 
you claim that you never, ever, I'm-swearing, associated SSL with "secure"?

So, can I quote you on "lock does not mean secure"?

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/21/2007 7:46:43 PM
Nelson Bolyard wrote:
> Gervase Markham wrote:
>   
>> [self-signed vs. plain HTTP]
>>
>> [UI that]
>> - Does _not_ give 99% of users any sense of being more "secure"
>> - Tells the 1% of users that the specific, limited non-eavesdroppability
>> they wanted is in place.
>>     
>
> Yes, that is the challenge.  Will FF UI folks accept that challenge?

I accept it. Indeed, I already proposed it.

   1. Show self-signed SSL connections the same as HTTP in normal browser UI
   2. In the menu, e.g. in Page info, have a dialog which tells about
      the cert being used (esp. the fingerprint), let it clearly say
      that 'nobody has verified that the connection really goes to the
      intended party ("self-signed")' or something like that and that
      the user needs to check it himself, by asking in person, to be sure.


-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/21/2007 7:53:23 PM
Nelson Bolyard wrote:

> 2. NO ONE ever does "proper checking".

Or perhaps almost no one.  The difference can be significant in some 
cases, since a small number of checkers could prevent a long-term attack 
from succeeding, although it probably isn't significant for most 
browser-based attacks.


> Instead, all SSH users use a model where they
> assume that the first time they contact a host, they are not being spoofed.
> They take the initial cert at face value and store it without any checking
> at all.  They assume that they were not being attacked in that first visit.
> 
> This scheme works well enough for SSH users today because most SSH servers
> are low value targets, not worth the effort of an MITM attack.

Presumably it also works for SSH because many initial connections to SSH 
servers are via trustworthy connections and SSH users are technically 
savvy enough to understand the cert mismatch dialog.

For example, if I first connect to an internal SSH server at my company 
from inside our firewall, I might reasonably trust the initial cert the 
server presents.  Then, if I later connect to the same server from an 
Internet cafe, and I get presented with a cert mismatch dialog, I'll 
know not to just click through.


> But if it
> became the way that browsers identified the users' bank's certificates,
> it would be a disaster.
> 
> It has been proposed that FF should accept and remember any cert for any
> SSL server on first encounter with that server, without any dialogs at all.
> No reliance on ANY CAs.  Self-signed or not, wouldn't matter.

Perhaps this has been proposed, but no one has proposed it in this 
conversation.

(Nor has anyone proposed applying the SSH model to bank certificates, 
although I'll note that many bank clients have in-person contact with 
their bank at a physical branch when they sign up for an account, so it 
would be conceivable for a bank to implement the SSH model, providing 
customers with their certificate's fingerprint, perhaps as a USB dongle 
with automation for verifying the fingerprint, if support for the model 
existed on the client side.)

We've merely been discussing what value, if any, a self-signed cert 
provides, and how to express that value in the browser's UI.  And the 
current proposal is to lend self-signed certificates even less credence 
than they currently enjoy, which I would think you would support.

-myk
0
Myk
2/21/2007 10:38:46 PM
On 2/21/07, Myk Melez <myk@mozilla.org> wrote:
> We've merely been discussing what value, if any, a self-signed cert
> provides, and how to express that value in the browser's UI.  And the
> current proposal is to lend self-signed certificates even less credence
> than they currently enjoy, which I would think you would support.

Right. And in my mind, we've been discussing this the wrong way
around. We support self-signed certs because, presumably, they offer
some value to some subset of our audience. We need to first answer:

 - who is this subset?
 - what is this value that they add?

cheers,
mike
-- 
/ mike beltzner / phenomenologist / mozilla corporation /
0
beltzner
2/21/2007 10:45:40 PM
Nelson Bolyard schrieb:
> Mike, the only people who claim that the lock means "secure" are the people
> who want to do away with it.
> 
> The lock means "page received over connection(s) that were authenticated
> and encrypted".  If that's too much of a mouthful for a sound bite, then
> boil it down to "authenticated", not "encrypted".

Actually, the lock currently means "https" which has the "s" from 
"secure", IIRC, it was "authenticated", it probably would be "httpa" and 
function a bit differently (e.g. wouldn't even allow self-signed certs").
And probably "encrypted" would be a better word for what the icon really 
means at the moment, but still it's "https", not "httpe"...

Robert Kaiser
0
Robert
2/21/2007 11:01:57 PM
Gervase Markham schrieb:
> Ben Bucksch wrote:
>> I thought IDNs were disabled in Firefox; I'm pretty sure you announced=
=20
>> at some point that they were, at least temporarily. Maybe you have=20
>> better protections (like enforcing one language / char set only) now=20
>> and re-enabled it, then I was wrong.
>=20
> We now enable IDN for a whitelist of some 30 TLDs, who have policies in=
=20
> place to prevent homograph spoofing.
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html

And that's a really really good solution. This way, we, who are in=20
countries with decent registries who have good policies, can use domains =

names that are freed from the ASCII cage such as www.w=E4hlt.at (which is=
=20
my pet IDN).

Thanks, Gerv and others who worked on getting this good solution into pla=
ce.

Robert Kaiser
0
Robert
2/21/2007 11:09:08 PM
Ben Bucksch <ben.bucksch.news@beonex.com> writes:

> Problem is that encryption without signing is pretty useless.

Encryption *with* signing, as currently implemented for https, is, as
near as I can tell, also pretty well useless.  Not that it has no
value at *all*, but it doesn't protect against enough of the likely
threats to really make the user's overall browsing experience
significantly more secure overall.  It is only even *intended* to
verify is that there's not a difficult-to-execute and not-very-common
eavesdropping attack going on, which is for most users an extremely
unlikely threat.  Much more likely scenarios that it does *not*
protect against include the following:
  * The spammers hacked a server that's got a valid SSL cert and put
    their phishing stuff up there ten minutes ago, right before
    sending the user the message that brought him here.  This
    happens on a fairly regular basis these days.  The site is
    "secure" enough to show a padlock icon in the browser, but
    in fact giving it any sensitive information is a quite bad idea.
  * The miscreants went out and bought a duly signed certificate.  On
    average they can better afford to do this than the average small
    business.
  * Somebody got ahold of a CA key that shouldn't have.
  * The user uses the same four-digit number for the bank as for
    everything else, and it's also the last four digits of the user's
    phone number (or house number, or birthdate), because that makes
    it easier to remember.  (At least 10% of all users do this.)
  * The user's own computer has been compromised in some fashion.

The last two there aren't directly related to the web browsing
experience, so perhaps they're not relevant.  But the first three
pretty much make https encryption meaningless IMO.  Not that we should
stop *using* the encryption (it does protect against one threat, after
all), but it seems wrong to represent it as making the browsing
session secure, when we know very well that it doesn't do that.

I don't think a UI distinction between http and https is necessary or
really waranted (except when the user clicks in the location bar, in
which case you show the protocol so it can be edited, copied, or
cetera).  The difference is technical in nature and has very little
bearing on security (or anything else) for the casual user.  

The padlock icon's primary value, IMO, is to make people *feel* more
secure, in which case, just put the lock on all websites and have
done.  Indeed, make the browser's own icon a lock and the throbber too
while you're at it, if making people feel more secure is the effect
you're going for.  (Actually, come to think of it, I can think of
worse things than that.  Firefox *is* more secure than IE, so extra
locks on Firefox that IE doesn't have make at least twice as much
sense as an extra lock on https sites that http sites don't have.
Indeed, only showing the lock when Firefox has checked recently and
knows it has all the latest security updates would actually make it a
meaningful indicator of something important.)

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3
hackerkey.com
0
Jonadab
2/22/2007 3:33:56 AM
Gervase Markham <gerv@mozilla.org> writes:

> Let's use upload as an example. Saying "If you want to know if you
> can upload, look for 'ftp://' in the URL bar" is not particularly
> good UI. 

Agreed.

> > However, I think the point that really convinced me that hiding parts of
> > URLs is bad is that we'd then find bunch of broken links on the web. If
> > my mom sees the location bar say:
> > Example Business, Inc. / shopping / basket ? id=1
> > she would be likely to *type* that in an email to a friend to take a
> > look at the product, rather than copy and paste.
> 
> Really? Do people type out entire URLs because copy and paste is
> beyond them? 

Of course they do.  How can you not know this?  Haven't you ever
watched end users at a computer?  They type URLs overwhelmingly more
frequently than they copy and paste, I can tell you that for free.

Typing has a very discoverable interface, because the letters are
actually printed on the keys on the keyboard.  Even people who say
they don't know how to type nonetheless generally do in fact know
*exactly* how to type, albeit not very quickly.  (Occasionally I run
into someone who doesn't understand shift, but that's an anomoly.
More often people get confused between the left arrow and backspace,
or the down or right arrow and enter...)  

Copy and paste are buried in the menus and mostly used by power users.
A significant minority of end users do not user pull-down menus, EVER.
If it's not on the toolbar, they don't do it.  Even end users who do
use the menus (because they have been shown how, usually for things
like File->Save and File->Print) don't generally go digging through
them on a regular basis looking for things to do.  Power users do
that, but many end users do not.

But frankly, clueless end users aside, *I* don't want to lose the
ability to look at the address bar, see what site I'm visiting, and
type the URL later, at another computer.  I copy and paste all the
time (probably several times a minute average), but there are
situations in which it doesn't work.

> I know we have to take account of all users, but it seems to me that
> it would be very difficult to use any application on a computer
> these days without some notion of the idea of copy and paste.

Many users do find computers inherently hard to use, but they go ahead
and use them anyway.  Not always efficiently.

> > Also, if I were to take
> > a screenshot of a browser window showing
> > Example Business Inc. / main.php
> > and make a bug report saying that web page does not lay out properly
> > in
> > Firefox, you'd be pretty frustrated...
> 
> Perhaps. But you will admit this is a very niche case.

Bug reports are a niche case, and screenshots are normally only taken
by people who understand computers *WAY* better than average.

Nonetheless, the point is that the location bar is the primary UI by
which the user determines what site he's looking at, so it needs to
show that information.  Always.  Showing the name of the company is
absolutely not an acceptable substitute.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/22/2007 4:03:20 AM
"Jason Barnabe (np)" <jason_barnabe@fastmail.fm> writes:

> On Windows XP, servers on UNC paths are not considered a part of "My
> Computer"; 

That's because Microsoft systems are multi-rooted, and have been at
least since DOS introduced support for multiple disks (circa version
2.0 I think, possibly sooner).  Unix is single-rooted, and it's normal
there for additional filesystems or disks to be mounted on the tree at
various points.  One logical filesystem tree addresses all of the
physical filesystems, local and remote.  DOS and Windows have never
done things that way.

Quite aside from that, though, calling the root "My Computer" on Unix
would certainly annoy a lot of geeks, for no very good reason.

And I don't think it makes a whole lot of sense on Windows either,
because then you've either got this:

[My Computer] C:/path/to/file

Which seems unnecessarily redundant (why not just make C:/ the root
since you have to show it anyway).

Or else there's a major inconsistency between the boot drive and other
drives in terms of how the root is labelled, which would be even more
unnatural.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/22/2007 4:26:37 AM
Tony Mechelynck wrote:
> Jonadab the Unsightly One wrote:
> [...]
>> A proper ftp client has by necessity a very different interface from a
>> web browser, and it doesn't fit into the browsing interface.  The
>> whole design of Firefox is predicated on *not* supporting every
>> popular protocol on the web, just the ones that fit into a
>> web-browsing paradigm.  Of course there is an ftp extension for
>> Firefox, and that's fine, but ftp upload is beyond the scope of what
>> Firefox is intended to do.  Not so much in terms of functionality
>> (web-form-based file uploads are supported after all), but in terms of
>> user interface, ftp uploads just don't belong.  For one thing, it's
>> hard to imagine a decently usable graphical ftp interface that doesn't
>> have some kind of split view with the local system in one half and the
>> remote system in the other half, and that's just totally out of place
>> in a web browser window.
> [...]
> 
> Just FYI, Konqueror doesn't have that split view. It shows one (remote
> or local) directory at a time (in tabs with a file: or ftp: directory
> URL -- there are others of course). To upload by FTP, highlight one or
> more files in the local folder, drag them to the tab for the remote
> folder (don't release the mouse: the tab opens) then drop them in the
> contents area and you get a popup: "Move Here / Copy Here / Link Here /
> Cancel". Similarly for download (and regardless of whether it's
> authenticated FTP or anonymous FTP).

Konqi can also copy and paste files locally, while Firefox can't. Fx
is simply not a file manager.

RQ
0
Rimas
2/22/2007 5:32:11 AM
Ben Bucksch wrote:
> (Right. As if the govt had absolutely no access to VeriSign. If it would 
> happen then, it happens now already. Which is exactly what storing keys 
> would *prevent*.)

It may not be much comfort, but at least only one government has the 
potential to influence Verisign in this way :-) The scenario Nelson 
proposes potentially allows any government or third party to MITM 
connections.

Gerv
0
Gervase
2/22/2007 9:49:52 AM
Jonadab the Unsightly One wrote:
>   * The spammers hacked a server that's got a valid SSL cert and put
>     their phishing stuff up there ten minutes ago, right before
>     sending the user the message that brought him here.  This
>     happens on a fairly regular basis these days.  

Do you have documented evidence of an occurrence of this?

>   * The miscreants went out and bought a duly signed certificate.  On
>     average they can better afford to do this than the average small
>     business.

This does happen occasionally, and I agree it shouldn't. The solution to 
this particular problem is better verification of applicants, so if a 
certificate is used fraudulently, you know whose door to knock on.

>   * Somebody got ahold of a CA key that shouldn't have.

I don't believe this has ever happened for any CA in a major browser. Do 
you know otherwise?

If it were to happen, we would treat it like any other browser security 
flaw, and issue a firedrill security update removing the root.

>   * The user uses the same four-digit number for the bank as for
>     everything else, and it's also the last four digits of the user's
>     phone number (or house number, or birthdate), because that makes
>     it easier to remember.  (At least 10% of all users do this.)

Right. And SSL doesn't prevent burglars breaking into my house, because 
it's not designed to do that either.

>   * The user's own computer has been compromised in some fashion.

Same answer.

> The padlock icon's primary value, IMO, is to make people *feel* more
> secure, in which case, just put the lock on all websites and have
> done.  Indeed, make the browser's own icon a lock and the throbber too
> while you're at it, if making people feel more secure is the effect
> you're going for.  (Actually, come to think of it, I can think of
> worse things than that.  Firefox *is* more secure than IE, so extra
> locks on Firefox that IE doesn't have make at least twice as much
> sense as an extra lock on https sites that http sites don't have.

That's a different meaning of the word "security". Firefox is more 
secure in the sense that your computer is less likely to get compromised 
when using it. That's not at all the same thing as the level of security 
available for keeping your information private on the web. Here, Firefox 
and IE offer broadly similar facilities from day to day - although our 
hard-working NSS hackers have being doing stuff recently with Elliptic 
Curve crypto and so on.

Gerv
0
Gervase
2/22/2007 9:55:14 AM
Jonadab the Unsightly One wrote:
> Of course they do.  How can you not know this?  Haven't you ever
> watched end users at a computer?  They type URLs overwhelmingly more
> frequently than they copy and paste, I can tell you that for free.

I didn't ask "Do users ever type URLs". Of course they do, as you point 
out. I ask "do users ever see a URL (which is not a link) on a computer 
screen, and retype it into the browser address bar (switching windows 
several times to check what it says) instead of doing copy and paste?

> Copy and paste are buried in the menus and mostly used by power users.

And on the toolbar for things like word processors.

> But frankly, clueless end users aside, *I* don't want to lose the
> ability to look at the address bar, see what site I'm visiting, and
> type the URL later, at another computer.  I copy and paste all the
> time (probably several times a minute average), but there are
> situations in which it doesn't work.

Maybe this thread is a bit behind the versions of the proposal, but I 
don't think anyone's suggesting that you lose the ability to see the URL 
in the address bar (when you focus it).

Gerv
0
Gervase
2/22/2007 9:58:23 AM
Nelson Bolyard wrote:
> Not really.  FF2 now fully supports the TLS "server name indication"
> extension, which sends the server a clue about the desired virtual host
> name in the handshake.  All you need is a server that supports SNI.

Really? I didn't know that. Cool!

Do you have a test server I could try it against?

Gerv
0
Gervase
2/22/2007 9:59:06 AM
Jonadab the Unsightly One wrote:
   > Perhaps.  I agree with the sentiment behind this, but if the user
> inadvertently types (say) ftp.gmd.de by mistake (neglecting to prepend
> the ftp:// protocol signifier), there needs to be an easy way for the
> user to change the assumed http:// to what it should be.

Actually, Firefox assumes ftp:// for hosts named "ftp".

> Perhaps when the thing goes into editable-textbox-mode (see below),
> then the scheme should be present, but otherwise not.

That's what we've settled on, I think :-)

>> [* Paypal, Inc.] /foo/bar/baz?q=x
> 
> Ack, no!  For the love of all that is sane, no.  

See proposal 1.2.

> An important part (perhaps *the* most important part) of the function
> of the location bar is that whatever the user sees there is a
> location, i.e., a globally-unique address. 

Name and country together are also supposed to be globally unique, FWIW.

Gerv
0
Gervase
2/22/2007 10:01:31 AM
Rimas Kudelis wrote:
> Tony Mechelynck wrote:
>> Jonadab the Unsightly One wrote:
>> [...]
>>> A proper ftp client has by necessity a very different interface from a
>>> web browser, and it doesn't fit into the browsing interface.  The
>>> whole design of Firefox is predicated on *not* supporting every
>>> popular protocol on the web, just the ones that fit into a
>>> web-browsing paradigm.  Of course there is an ftp extension for
>>> Firefox, and that's fine, but ftp upload is beyond the scope of what
>>> Firefox is intended to do.  Not so much in terms of functionality
>>> (web-form-based file uploads are supported after all), but in terms of
>>> user interface, ftp uploads just don't belong.  For one thing, it's
>>> hard to imagine a decently usable graphical ftp interface that doesn't
>>> have some kind of split view with the local system in one half and the
>>> remote system in the other half, and that's just totally out of place
>>> in a web browser window.
>> [...]
>>
>> Just FYI, Konqueror doesn't have that split view. It shows one (remote
>> or local) directory at a time (in tabs with a file: or ftp: directory
>> URL -- there are others of course). To upload by FTP, highlight one or
>> more files in the local folder, drag them to the tab for the remote
>> folder (don't release the mouse: the tab opens) then drop them in the
>> contents area and you get a popup: "Move Here / Copy Here / Link Here /
>> Cancel". Similarly for download (and regardless of whether it's
>> authenticated FTP or anonymous FTP).
> 
> Konqi can also copy and paste files locally, while Firefox can't. Fx
> is simply not a file manager.
> 
> RQ

That's true. But I was replying to (and disagreeing with) the sentence 
"...it's hard to imagine a decent usable graphical ftp interface that doesn't 
have some sort of split view with the local system in one half and the remote 
system in the other half...".

Best regards,
Tony.
-- 
ERROR 047: Keyboard not found.  Press RETURN to continue.
0
Tony
2/22/2007 12:06:53 PM
Gervase Markham <gerv@mozilla.org> writes:

> Asrail wrote:
> > I don't think it's really needed by default. A "Micros Soft
> > Cooporation" on Jamaica could confuse someone, anyway.
> 
> No more, and hopefully a lot less, than www.micros0ft.com.

What if instead of "Micros Soft Cooporation" it's "Microsoft
Corporation".  Perhaps more relevantly, what if the name of the
company is "First Federal Bank"?

Security aside, the name of a company is, fundamentally, non-unique.
That by itself prevents it from being a valid a substitute for a FQDN.

> Hmm. It is going to be hard to square the circle of "hide some stuff",
> "allow copying of everything" and "don't make stuff move when you
> focus the URL bar"...

Only if you're determined to stamp out whitespace.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/22/2007 12:46:37 PM
Gervase Markham <gerv@mozilla.org> writes:

> We need to choose the font, and we need to make the correct choice
> for security.

For the default, I agree.

The user still should be permitted to change it though.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/22/2007 12:55:54 PM
Gervase Markham schrieb:
> Jonadab the Unsightly One wrote:
>> Of course they do.  How can you not know this?  Haven't you ever
>> watched end users at a computer?  They type URLs overwhelmingly more
>> frequently than they copy and paste, I can tell you that for free.
> 
> I didn't ask "Do users ever type URLs". Of course they do, as you point 
> out. I ask "do users ever see a URL (which is not a link) on a computer 
> screen, and retype it into the browser address bar (switching windows 
> several times to check what it says) instead of doing copy and paste?

Yes. Enough people out there don't even know how copy and paste is done, 
and really feel they "know something about computers" once they realize 
how it works and are even able to use it (I still remember how proud my 
mom was when she learned how to even to that with keyboard shortcuts)...

Robert Kaiser
0
Robert
2/22/2007 1:08:10 PM
Gervase Markham wrote:
> It may not be much comfort, but at least only one government has the 
> potential to influence Verisign in this way :-)

Well, count the number and locations of root certs. 40? Some of them 
being the government directly.

> The scenario Nelson proposes potentially allows any government or 
> third party to MITM connections. 

But you realize that Nelson's scenario was completely off, because it 
used a completely different circumstance? Nobody here proposes to 
replace CA-backed certs for webshops and banks with self-signed certs. 
His scenario is total nonsense. I thought I made *that* clear.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/22/2007 6:35:00 PM
beltzner wrote:
> presumably, they offer
> some value to some subset of our audience. We need to first answer:
>
> - who is this subset?
> - what is this value that they add?

I answered that in my posts.

It's very convenient for tiny sites with a handful of people or single 
individuals, mostly webmail, IMAPS, SMTP via SSP, private sections of 
websites. They won't pay even $50 for a cert. For them, self-signed or 
not means encrypted or plain HTTP/IMAP.

For example, I am using a self-signed cert for IMAPS, and I *did* check 
the fingerprint, and I ordered my IMAP client to reject any cert that 
doesn't match that fingerprint. With fetchmail, for example, you can put 
the fingerprint right next to the host configuration.

Also, it's far faster to set up than getting a CA cert. A 10 minute 
process, not including reading the contracts and instructions of 20 page 
fineprint, will mean that a lot of one-man sites won't bother getting a 
cert.

There's a *huge* "market" for certs which are free and created in no 
time, for micro sites. Given that they are just for 1-3 persons, they 
don't show up on most people's radar, but are still probably in the 
millions.

Ben
0
Ben
2/22/2007 6:49:51 PM
beltzner wrote:
> presumably, they offer
> some value to some subset of our audience. We need to first answer:
>
> - who is this subset?
> - what is this value that they add?

I answered that in my posts.

It's very convenient for tiny sites with a handful of people or single 
individuals, mostly webmail, IMAPS, SMTP via SSP, private sections of 
websites. They won't pay even $50 for a cert. For them, self-signed or 
not means encrypted or plain HTTP/IMAP.

For example, I am using a self-signed cert for IMAPS, and I *did* check 
the fingerprint, and I ordered my IMAP client to reject any cert that 
doesn't match that fingerprint. With fetchmail, for example, you can put 
the fingerprint right next to the host configuration.

Also, it's far faster to set up than getting a CA cert. A 10 minute 
process, not including reading the contracts and instructions of 20 page 
fineprint, will mean that a lot of one-man sites won't bother getting a 
cert.

There's a *huge* "market" for certs which are free and created in no 
time, for micro sites. Given that they are just for 1-3 persons, they 
don't show up on most people's radar, but are still probably in the 
millions.

Ben
0
Ben
2/22/2007 6:49:51 PM
On 2/22/07, Gervase Markham <gerv@mozilla.org> wrote:
> >   * Somebody got ahold of a CA key that shouldn't have.
>
> I don't believe this has ever happened for any CA in a major browser. Do
> you know otherwise?
>
> If it were to happen, we would treat it like any other browser security
> flaw, and issue a firedrill security update removing the root.

I don't think it's _that_ much of a stretch to consider the incident
in which Verisign issued a Microsoft Corp. cert to some random social
engineer such a case.

Mike
0
Mike
2/22/2007 7:05:58 PM
Mike Shaver wrote:
> On 2/22/07, Gervase Markham <gerv@mozilla.org> wrote:
>> >   * Somebody got ahold of a CA key that shouldn't have.
>>
>> I don't believe this has ever happened for any CA in a major browser. Do
>> you know otherwise?
>>
>> If it were to happen, we would treat it like any other browser security
>> flaw, and issue a firedrill security update removing the root.
> 
> I don't think it's _that_ much of a stretch to consider the incident
> in which Verisign issued a Microsoft Corp. cert to some random social
> engineer such a case.

He said "CA key"; I assumed he meant someone getting a CA root 
certificate private key, rather than someone fraudulently obtaining a 
certificate.

I accept that the latter will happen occasionally (and the case you 
mention is the one everyone mentions) and I don't think it "make[s] 
https encryption meaningless", to quote Jonadab.

Gerv
0
Gervase
2/22/2007 7:12:47 PM
Nelson Bolyard wrote:
> Rimas Kudelis wrote:
>> Gervase Markham wrote:
>>> Rimas Kudelis wrote:
>>>> I do, actually. Exactly the way Michael described (https for webmail
>>>> and admin tasks, http for main webpage). And I'm sure I'm not the only
>>>> one.
>>> Why? Why not use different hostnames? Is it too inconvenient for you to
>>> change the DNS to have two aliases for the same machine?
>> Because it's not always JUST mail. 
>> Plus, the problem of secure name-based vhosts still exists. 
> 
> Not really.  FF2 now fully supports the TLS "server name indication"
> extension, which sends the server a clue about the desired virtual host
> name in the handshake.  All you need is a server that supports SNI.

Does Apache support it?

RQ
0
Rimas
2/22/2007 8:18:45 PM
Jonadab the Unsightly One wrote:
> What if instead of "Micros Soft Cooporation" it's "Microsoft
> Corporation".  Perhaps more relevantly, what if the name of the
> company is "First Federal Bank"?
> 
> Security aside, the name of a company is, fundamentally, non-unique.

Combined with a jurisdiction, it's pretty unique. Companies don't tend 
to like other companies with the same name trading in the same place; it 
causes too much consumer confusion :-)

Gerv
0
Gervase
2/23/2007 10:06:38 AM
Gervase Markham <gerv@mozilla.org> writes:

> It's true that you could have two windows where the URL bar looks
> the same but the content displayed is different (because you are
> using a different protocol). I don't think that's necessarily a
> showstopper; there's not a security risk because they are all on the
> same host.

Security risk or not, it would without question be confusing.

> > in smaller settings, there may well be 1 host name with a bunch of
> > different services, and they would be confusing and spoofable.
> > For example, I could set up some HTML pages on an FTP server on a
> > host which was running the organisation's intranet, and make it
> > look like I'd replaced the intranet with my web pages.
> 
> But surely if you have access to do that, you could just replace the
> pages anyway?

Huh?

Oh, you're assuming the purpose of the ftp service is to allow the web
content to be updated, so it would access the same directories.  If
that's all you can imagine, your experience with ftp is very narrow.
It is not unusual in small-network settings to have an *anonymous* ftp
service running on the same host as a website.  

However, to allow the exploit described above, the ftp service would
have to allow writing to and reading from the same directory, which is
usually considered a Bad Idea for anon ftp, since it invites warez
mongers and their ilk to fill up your ftp server with their nonsense.

> > But it could mean for a radically different hostname, you have a
> > similar textual name.  If someone gets an EV certificate for
> > Manybank Inc, they can host their site at
> > https://kjasdffdsfjewf.evil.com and the URL bar will be almost
> > identical to the genuine site of Anybank Inc.
> 
> If you can get an EV cert for the same or a similar name, getting a
> similar domain name would be the easy bit. I'm not sure what extra
> protection showing both would actually afford.

You keep talking about "similar", but there is not much that can be
done about "similar".  There are always going to be things that are
similar enough that non-careful people fail to notice the difference.
This isn't going to change.

However, I'd like to steer you toward thinking about a concept that
goes beyond similar, i.e., the concept of "identical".  There are many
companies with 100% identical names.  Legitimately.  In some cases
they are competitors.  NOBODY can register a domain name that's 100%
identical with their competitor's domain name, at the same time.

FQDNs are unique.  Company names are not.  The FQDN is the address,
the "location" if you prefer.  The company name is not.  Both metadata
may be useful, but the FQDN is more important.

> The whole "don't have things jump around on focus" thing is looking
> harder and harder to do...

If you use "click" instead of "focus", then the jumping around is less
disastrous, among other things because it doesn't get you into an
infinite loop of focus/unfocus.  This works for hiding the protocol,
for instance.  But you need to think very long and very hard before
hiding the FQDN or replacing it with other information.  IMO, that is
unmitigated madness.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/23/2007 3:24:14 PM
Tony Mechelynck <antoine.mechelynck@belgacom.net> writes:

> Just FYI, Konqueror doesn't have that split view. It shows one
> (remote or local) directory at a time (in tabs with a file: or ftp:
> directory URL -- there are others of course). To upload by FTP,
> highlight one or more files in the local folder, drag them to the
> tab for the remote folder (don't release the mouse: the tab opens)
> then drop them in the contents area and you get a popup: "Move Here
> / Copy Here / Link Here / Cancel". Similarly for download (and
> regardless of whether it's authenticated FTP or anonymous FTP).

That's approximately what I was envisioning in terms of how it could
be supported in Firefox, which is why I said what I did.

A user who has to do very much with ftp would be better served with a
real ftp app.  Not only is the traditional two-pane ftp interface a
good deal more efficient with the amount of moving-the-mouse-around
that you have to do, but it also allows you to compare the local and
remote directories side-by-side at a glance, and if one of them is
missing a file it's immediately obvious.

And, as noted, Firefox is a web browser, not a full internet
application suite, nor a file manager.  (Incidentally, the whole idea
of a web browser that is also a file manager is one that I find
bizarre in the extreme, along the same lines as a photo editor that is
also a music player, or a tape backup program that is also a usenet
newsreader.  The two tasks are so different that combining them does
unnatural things to the UI.  Throwing in full ftp is similarly weird.)

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/23/2007 3:45:39 PM
Gervase Markham <gerv@mozilla.org> writes:

> Jonadab the Unsightly One wrote:
> >   * The spammers hacked a server that's got a valid SSL cert and
> >   put their phishing stuff up there ten minutes ago, right before
> >   sending the user the message that brought him here.  This
> >   happens on a fairly regular basis these days.
> 
> Do you have documented evidence of an occurrence of this?

Not on hand, but I was sure I'd read several articles at various times
about the phenomenon, written I think by people involved with security
research and/or honeypot-style projects.

I don't have a URL handy, though.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/23/2007 3:49:35 PM
Gervase Markham <gerv@mozilla.org> writes:

> He said "CA key"; I assumed he meant someone getting a CA root
> certificate private key,
  
That is what I meant.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/23/2007 3:50:35 PM
Gervase Markham <gerv@mozilla.org> writes:

> I didn't ask "Do users ever type URLs". Of course they do, as you
> point out. I ask "do users ever see a URL (which is not a link) on a
> computer screen, and retype it into the browser address bar
> (switching windows several times to check what it says) instead of
> doing copy and paste?

Oh.  Yes, they do that too, albeit rather less often.

> > Copy and paste are buried in the menus and mostly used by power
> > users.
> 
> And on the toolbar for things like word processors.

True.  Still, many users don't use it much.  Come to that, a lot of
people don't use word processing at all, but do use the web.  Indeed,
I've more than once seen users (of Yahoo Mail or Hotmail) email
something to themselves so they can print it out.

Not that I think Firefox should cater heavily toward that sort of
thing.  Any tool can be used in an unintended fashion by someone who
doesn't know about other tools.  

Nonetheless, being able to see the URI of the currently visible web
page is important.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/23/2007 4:01:48 PM
Gervase Markham <gerv@mozilla.org> writes:

> Jonadab the Unsightly One wrote:
> > Perhaps more relevantly, what if the name of the company is "First
> > Federal Bank"?  Security aside, the name of a company is,
> > fundamentally, non-unique.
> 
> Combined with a jurisdiction, it's pretty unique. Companies don't
> tend to like other companies with the same name trading in the same
> place; it causes too much consumer confusion :-)

Define "jurisdiction" and "the same place".  Earlier, I thought you
were talking about entire countries.

My bank is called "First Federal Bank".  (It used to be called "First
Federal Savings & Loan", but they changed it some time in the last
five years.)  There are several branches, but the headquarters is in
Galion, four blocks from my house.  There's another branch on the west
side of town (six or so blocks the other direction from my house), and
one in Ontario (20 minutes northeast by car), and I think maybe one in
Mt. Gilead (twenty minutes south by car).  There may be a couple of
other branches I don't know about.  I happen to know the treasurer,
Dave Beach.  His brother and I are long-standing faithful members of
the same church.  (I didn't know this when I selected the bank and
opened my account.)

Naturally, there numerous are other banks in Ohio, let alone in the
whole USA, called First Federal Bank or First Federal Savings & Loan,
which have no affiliation with this one.  In fact, if you Google
"First Federal Bank", my bank is not in the first page of results, nor
the second page, nor the third, fourth, or fifth page.  (I didn't look
beyond that.  It *is* indexed, because if you add the word Galion to
your query it's the first result then.  Galion is not a very
competitive search term.)

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/23/2007 4:26:13 PM
Jonadab the Unsightly One wrote:
> Tony Mechelynck <antoine.mechelynck@belgacom.net> writes:
> 
>> Just FYI, Konqueror doesn't have that split view. It shows one
>> (remote or local) directory at a time (in tabs with a file: or ftp:
>> directory URL -- there are others of course). To upload by FTP,
>> highlight one or more files in the local folder, drag them to the
>> tab for the remote folder (don't release the mouse: the tab opens)
>> then drop them in the contents area and you get a popup: "Move Here
>> / Copy Here / Link Here / Cancel". Similarly for download (and
>> regardless of whether it's authenticated FTP or anonymous FTP).
> 
> That's approximately what I was envisioning in terms of how it could
> be supported in Firefox, which is why I said what I did.
> 
> A user who has to do very much with ftp would be better served with a
> real ftp app. 

There is the FireFTP extension, but it is buggy and in some environments 
crash-prone; FileZilla, but it works only on Windows; on Linux Konqueror, with 
mouse movement and all, is much better than nothing (or than the "ftp" 
command-line utility). I will go as far, though, as agreeing that Konqueror is 
both a web browser and a file manager, while Firefox is a browser only.

> Not only is the traditional two-pane ftp interface a
> good deal more efficient with the amount of moving-the-mouse-around
> that you have to do, but it also allows you to compare the local and
> remote directories side-by-side at a glance, and if one of them is
> missing a file it's immediately obvious.
> 
> And, as noted, Firefox is a web browser, not a full internet
> application suite, nor a file manager.  (Incidentally, the whole idea
> of a web browser that is also a file manager is one that I find
> bizarre in the extreme, along the same lines as a photo editor that is
> also a music player, or a tape backup program that is also a usenet
> newsreader.  The two tasks are so different that combining them does
> unnatural things to the UI.  Throwing in full ftp is similarly weird.)
> 

With Konqueror or (maybe to a lesser degree, it's been years since I last used 
it) with Internet Explorer, the browser and file-manager functions integrate 
quite well and, shall I say, "naturally". The file manager comes into play 
when a file: or ftp: directory is displayed, the browser when it's a file 
(including the "default file" served by HTTP servers when a directory is 
requested). After using it for a while, it doesn't feel "weird" at all. People 
with black skin, or with slanted eyes (or, to take a non-European viewpoint, 
with long noses and non-black hair) are equally "weird" the first time you 
ever meet one.

The fact that Firefox is not a file manager and only affords quite limited 
capabilities when viewing a directory with a file: or ftp: URL, is not a 
blemish of Firefox: it's just that different choices have been made when 
deciding when deciding what Firefox should or shouldn't have. IOW: it's not 
better or worse, it's just different.

To play with your metaphor, I could even combine a photo editor with a music 
player in a "non-weird" way: by throwing in a movie and music editor capable 
of producing sound movies, including animation movies.


Best regards,
Tony.
-- 
Missionary Position:
	The missionary on top.
0
Tony
2/23/2007 4:34:32 PM
Gervase Markham <gerv@mozilla.org> writes:

> Name and country together are also supposed to be globally unique,
> FWIW.

Business name and country together are still absolutely not unique.
Not even vaguely close to unique, in a lot of cases.  Within walking
distance of my house I can off the top of my head think of the
following counterexamples:

 * The aforementioned First Federal Bank, which does now have a web
   presense but is numerous pages down the list of Google results if
   you don't add the word Galion to your query, which is not part of
   the name of the business.
 
 * Fox Plumbing & Heating, a locally owned family plumbing business.
   (It is not part of any chain or franchise.  Fox is the surname of
   the family.)  If you Google "Fox Plumbing and Heating" you will
   find numerous other businesses in the same country (the USA) with
   exactly the same name.  Somewhat suprisingly, the one in Galion
   does have a web presense and indeed shows up on the first page of
   Google results.

 * The Uptown Cafe, a small coffee shop owned and operated by one
   woman.  It is not part of any chain or franchise.  I don't know
   that it has a web presense, although I don't know that it doesn't,
   either.  Google of course reveals numerous other US businesses with
   exactly the same name.
   
Maybe the UK is rather different in this regard, but in the US it is
entirely normal for businesses to have names that are unique at the
local level (city or county) but not at the state level, much less the
whole country.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/23/2007 4:45:36 PM
Tony Mechelynck <antoine.mechelynck@belgacom.net> writes:

> There is the FireFTP extension, but it is buggy and in some
> environments crash-prone; 

I agree with that assessement.

> FileZilla, but it works only on Windows; 

FileZilla is neither here nor there.  There are *lots* of ftp
applications freely available, some better than others, some cross
platform, some not, some open-source, some not.  For any operating
system (with a graphical operating environment) that you care to name,
there are at least a dozen available.  I've recently been using gftp,
and that gets the job done, but there are lots of other choices.  On
FreeBSD, /usr/ports/ftp contains over a hundred different ports.  I'm
sure some of those aren't graphical ftp apps, but I'm also sure many
of them are.

As noted, I think the Mozilla application suite ought to include one,
and as far as I'm aware it really does not.  But that is neither here
nor there for Firefox.  Firefox does *not* need to duplicate this
functionality.

> on Linux Konqueror, with mouse movement and all, is much better than
> nothing (or than the "ftp" command-line utility).

Better than nothing isn't a very exacting criterion, though.

> > Not only is the traditional two-pane ftp interface a good deal
> > more efficient with the amount of moving-the-mouse-around that you
> > have to do, but it also allows you to compare the local and remote
> > directories side-by-side at a glance, and if one of them is
> > missing a file it's immediately obvious.  And, as noted, Firefox
> > is a web browser, not a full internet application suite, nor a
> > file manager.  (Incidentally, the whole idea of a web browser that
> > is also a file manager is one that I find bizarre in the extreme,
> > along the same lines as a photo editor that is also a music
> > player, or a tape backup program that is also a usenet newsreader.
> > The two tasks are so different that combining them does unnatural
> > things to the UI.  Throwing in full ftp is similarly weird.)
> 
> With Konqueror or (maybe to a lesser degree, it's been years since I
> last used it) with Internet Explorer, the browser and file-manager
> functions integrate quite well and, shall I say, "naturally". 

I can't agree with that.  Stuff that makes sense in a brower
environment doesn't necessarily make sense in a file manager, and vice
versa.  The location bar, okay, maybe, but where the browser has
concepts like home and bookmarks, the file manager instead has
concepts like parent directory and sort by extension.  Trying to make
the same chrome work for both gives you an interface that's not really
very good for either.

It's not just about "weird".  It's about building a peg that goes in
either a square or a round hole, depending on the situation.  It can
be done, but you can get better results by just having distinct round
and square pegs.

> To play with your metaphor, I could even combine a photo editor with
> a music player in a "non-weird" way: by throwing in a movie and
> music editor capable of producing sound movies, including animation
> movies.

But if I wanted to listen to music, I wouldn't want that app.  I'd
want a regular music player that just plays from my playlist and stays
out of my way otherwise.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/24/2007 12:30:52 AM
Gervase Markham <gerv@mozilla.org> writes:

> Mark Finkle wrote:
>   > * 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.
> 
> I'd be interested if anyone has any hard figures here. My gut tells
> me that clearing out the URL and replacing it with something else
> would be pretty common, but most other operations would be advanced.

I can confirm that with a fair degree of confidence.  Not with hard
figures as such, but as The Computer Guy at a public library I get to
see a lot of end users browsing the web, and it is obvious to me that
replacing the whole URL is by far the most common editing operation in
the location bar.

Of course, you want other, more advanced operations to be possible
also.  Power users do more URL editing, and you don't ever want to
sacrifice them in the name of the end user, since the power users are
often advocates.

But the *most* common location-editing operation, by a wide margin, is
typing in a whole new URL.  (Incidentally, in case you were wondering,
the second-most-common is probably typing in search terms that
obviously-to-me are not a domain name, just search terms, and then
appending .com to them.  But there are some forms of confusion that a
user interface can't really be expected to fix, and that may be one of
them.)

> > * I do not believe the button-style is required and I feel it
> > creates too much "noise" in the URL bar.
> 
> You feel the bolding is sufficient? The problem with bolding is that
> it doesn't work well for some scripts (e.g. Chinese).

Perhaps the form of emphasis should depend on l10n?

For en-us, bold is a much *better* form of emphasis than drawing a
button around it, IMO (although both together might be even better).
Color for emphasis is problematic because you don't know what the
user's system colors are when you pick your emphasis color.  (The
yellow background for https is terrible in this regard.  I have always
hated it.)

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/24/2007 12:55:54 AM
"Mike Shaver" <mike.shaver@gmail.com> writes:

> > > Press Ctrl-L and start typing?
> >
> > Discoverable? Easily discoverable? Complies with usage habits?
> 
> Menu item with a keybinding, and it's been the same way in IE and
> Netscape for likely a decade?  I'd say "yes".

Easily discoverable for those of us who use menus and understand what
keyboard shortcuts are.

In some respects it's tempting to have the whole URL highlighted when
the user clicks once in the address bar, but that would probably be
too annoying for power users.  It would certainly annoy me.  Also it
raises the question of what double-click would do then.  On the whole
I think it's probably a poor trade-off, though I'm not 100% certain.

FWIW, the following user behaviors (in no particular order) are all
fairly common:

 * Drag to highlight.  I've seen this done both ways (LTR and RTL) by
   different users.  Then the user either starts typing, or much more
   often hits backspace or delete first to clear it.  (Many users,
   perhaps most, do not understand about typing-replaces-selection.
   Not that it's a big deal: once it's highlighted, backspace is just
   one keypress.)

 * Click at the end of the URL and either hold backspace down, or tap
   it a whole bunch of times.  If the old URL is longer than the
   location bar, this creates difficulties, which sometimes leads to
   the next behavior...
 
 * Click anywhere in the location bar and use the right arrow key to
   get to the end (these users don't know cursor-control keys well
   enough to hit end), then use backspace to clear it, then type.
 
 * Click the current URL until it is highlighted (currently this is a
   double-click operation IIRC), hit backspace or delete to clear it,
   then start typing.
   
Less commonly, I've also occasonally seen users click at or near the
beginning of the location bar and use the delete key (either held or
tapped repeatedly) to erase its contents.  But using backspace is much
more common.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/24/2007 1:14:56 AM
Jonadab the Unsightly One wrote:
> Tony Mechelynck <antoine.mechelynck@belgacom.net> writes:
> 
>> There is the FireFTP extension, but it is buggy and in some
>> environments crash-prone; 
> 
> I agree with that assessement.
> 
>> FileZilla, but it works only on Windows; 
> 
> FileZilla is neither here nor there.  There are *lots* of ftp
> applications freely available, some better than others, some cross
> platform, some not, some open-source, some not.  For any operating
> system (with a graphical operating environment) that you care to name,
> there are at least a dozen available.  I've recently been using gftp,
> and that gets the job done, but there are lots of other choices.  On
> FreeBSD, /usr/ports/ftp contains over a hundred different ports.  I'm
> sure some of those aren't graphical ftp apps, but I'm also sure many
> of them are.
> 
> As noted, I think the Mozilla application suite ought to include one,
> and as far as I'm aware it really does not.  But that is neither here
> nor there for Firefox.  Firefox does *not* need to duplicate this
> functionality.
> 
>> on Linux Konqueror, with mouse movement and all, is much better than
>> nothing (or than the "ftp" command-line utility).
> 
> Better than nothing isn't a very exacting criterion, though.

Maybe I wasn't clear enough. I really like that interface.

> 
>>> Not only is the traditional two-pane ftp interface a good deal
>>> more efficient with the amount of moving-the-mouse-around that you
>>> have to do, but it also allows you to compare the local and remote
>>> directories side-by-side at a glance, and if one of them is
>>> missing a file it's immediately obvious.  And, as noted, Firefox
>>> is a web browser, not a full internet application suite, nor a
>>> file manager.  (Incidentally, the whole idea of a web browser that
>>> is also a file manager is one that I find bizarre in the extreme,
>>> along the same lines as a photo editor that is also a music
>>> player, or a tape backup program that is also a usenet newsreader.
>>> The two tasks are so different that combining them does unnatural
>>> things to the UI.  Throwing in full ftp is similarly weird.)
>> With Konqueror or (maybe to a lesser degree, it's been years since I
>> last used it) with Internet Explorer, the browser and file-manager
>> functions integrate quite well and, shall I say, "naturally". 
> 
> I can't agree with that.  Stuff that makes sense in a brower
> environment doesn't necessarily make sense in a file manager, and vice
> versa.  The location bar, okay, maybe, but where the browser has
> concepts like home and bookmarks, the file manager instead has
> concepts like parent directory and sort by extension.  Trying to make
> the same chrome work for both gives you an interface that's not really
> very good for either.
> 
> It's not just about "weird".  It's about building a peg that goes in
> either a square or a round hole, depending on the situation.  It can
> be done, but you can get better results by just having distinct round
> and square pegs.

Apparently we won't agree. One of my favourites Fx extensions (Parent Folder) 
removes one component (stopping at a slash) at the end of the current URL if 
possible then gets the result. And at one of my favourite sites ( 
http://ftp.mozilla.org/pub/mozilla.org/ etcetera) I have SeaMonkey sort the 
(end) directories by descending modif date rather than the default which is 
ascending filename. Now has Konqueror got bookmarks? ... yes, but I don't use 
them as much (by far) as Firefox's and SeaMonkey's.

> 
>> To play with your metaphor, I could even combine a photo editor with
>> a music player in a "non-weird" way: by throwing in a movie and
>> music editor capable of producing sound movies, including animation
>> movies.
> 
> But if I wanted to listen to music, I wouldn't want that app.  I'd
> want a regular music player that just plays from my playlist and stays
> out of my way otherwise.
> 

What about making movies? Making and editing all kinds of artwork from 
photomanipulation to line drawing to animated GIFs to animated cartoons (with 
sound) to electronic music to... There really _is_ a continuum. The fact that 
only one end interests you doesn't mean no one else has a right to address the 
rest without a whole bunch of specialized tools: one program for photomanip, 
and another one for line drawing, and another one for animation, and another 
one for... <shrug /> I guess we can't agree. Don't make your "I prefer" into 
"everybody should" and I won't either.


Best regards,
Tony.
-- 
Error in operator: add beer
0
Tony
2/24/2007 2:01:51 AM
Robert Kaiser <kairo@kairo.at> writes:

> (and yes, for those the URL bar is probably one of the most
> important parts of the browser).
  
The way I figure it, the three most important pieces of browser
chrome, in order of importance, are as follows:

1. The back button.  If it don't have a back button in the upper
   left-hand corner, it ain't a real web browser, period.
2. The vertical scrollbar on the right edge.
3. The URL bar.
   
For a lot of users, these are the *only* three pieces of browser
chrome that they ever use.  (I don't consider the window control
buttons (e.g., close, maximize, shade, and so forth) to be browser
chrome; those are window-manager features, even if in some
environments the window manager isn't a distinct program from other
components of the OS.  Anyway, it's not part of the browser chrome as
such.)

Number two gets less important every year, as scrollmice are gradually
taking over, but for the time being it is still vitally important.
(And of course it will always retain some importance, as it can be
used in drag-the-slider mode to get rapidly to a certain place in a
long document, plus glancing at it tells you how much of the page
you're currently seeing and which part.  But all of that is probably
less important than the URL bar; whereas, as long as there are still a
lot of non-scrollmouse users who don't know about pgdn, the scrollbar
remains more important.)

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/24/2007 4:30:14 AM
Gervase Markham <gerv@mozilla.org> writes:

> Myk Melez wrote:
> > One option would be to display (and emphasize) the port if isn't the
> > default port for the given protocol.  The port would almost never
> > appear, and thus it wouldn't be in the way most of the time but
> > might raise a red flag when it does show up.
> 
> That's certainly an interesting idea.

Except for the emphasis (which is probably a good idea), isn't this
basically what already happens?  I don't see :80 all the time, but I'm
pretty sure that if I use a URL with a non-standard port, it doesn't
currently get hidden.

Which is good, because when the port's something *other* than the
normal one, that's when I need to know about it.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/24/2007 4:36:41 AM
Ben Bucksch wrote:
> Gervase Markham wrote:

>> The scenario Nelson proposes potentially allows any government or
>> third party to MITM connections. 

I am not the one who proposes that we should abandon CAs for SSH-style
cert management.  The person who has repeatedly proposed that is not
presently participating in this discussion, but it appears to be his
life mission to do whatever it takes to see that proposal come to pass.

I am trying to get people to think of the consequences.  People who think
that massive MITM attacks are impractical don't know about Netsetter.

> But you realize that Nelson's scenario was completely off, because it
> used a completely different circumstance? Nobody here proposes to
> replace CA-backed certs for webshops and banks with self-signed certs.

Like I said, the proponent of that approach is not presently participating
in this thread, but give him time.  :)

I will also point out that if you let self-signed certs work as quietly as
certs from legitimate CAs, nothing will stop banks from using self-signed
certs.

> His scenario is total nonsense. I thought I made *that* clear.

I agree that the proposal to use SSH style cert management is total nonsense.
That's why I'm putting it up as a straw man.  I'm glad you hate it.
I hope you will continue to hate it when its major proponent starts to
propose it again.
0
Nelson
2/24/2007 8:16:04 PM
Ben Bucksch wrote:
> Nelson Bolyard wrote:
>> Gervase Markham wrote:
>>  
>>> [self-signed vs. plain HTTP]
>>>
>>> [UI that]
>>> - Does _not_ give 99% of users any sense of being more "secure"
>>> - Tells the 1% of users that the specific, limited non-eavesdroppability
>>> they wanted is in place.
>>>     
>>
>> Yes, that is the challenge.  Will FF UI folks accept that challenge?
> 
> I accept it. Indeed, I already proposed it.
> 
>   1. Show self-signed SSL connections the same as HTTP in normal browser UI
>   2. In the menu, e.g. in Page info, have a dialog which tells about
>      the cert being used (esp. the fingerprint), let it clearly say
>      that 'nobody has verified that the connection really goes to the
>      intended party ("self-signed")' or something like that and that
>      the user needs to check it himself, by asking in person, to be sure.

I want to read Beltzner's answer to my question.  That's the only answer
that is meaningful, IMO.  Sorry, but that's the way it is.
0
Nelson
2/24/2007 8:26:22 PM
Gervase Markham wrote:
> Nelson Bolyard wrote:
>> Not really.  FF2 now fully supports the TLS "server name indication" 
>> extension, which sends the server a clue about the desired virtual host 
>> name in the handshake.  All you need is a server that supports SNI.
> 
> Really? I didn't know that. Cool!
> 
> Do you have a test server I could try it against?

yes.  It uses certs issued by a test CA, so first download/install the
test root cert, then do the SNI tests, then remove trust from the root
CA cert you downloaded.

The root CA cert is at https://bob.sni.velox.ch/root.crt
the https virtual servers, which all share a common IP address and port,
are at these URLs:

https://alice.sni.velox.ch/
https://bob.sni.velox.ch/
https://carol.sni.velox.ch/
https://dave.sni.velox.ch/

the web site says:

> This Web server is running Apache 2.2 with mod_ssl linked against a recent
> snapshot of the OpenSSL 0.9.9 development version. Additionally, it includes
> a slightly modified version of a patch from the EdelKey project.
> 
> Apache is configured as shown below and uses three certificates, where
> CN=alice.sni.velox.ch, CN=bob.sni.velox.ch, 

> Browsers with support for TLS server name indication:
> 
> * Opera 8.0 and later (the TLS 1.1 protocol must be enabled) 
> * Internet Explorer 7 (under Windows Vista only, not under Windows XP)
> * Firefox 2.0 or later
> 
> See also mod_gnutls for an alternative Apache module featuring SNI support.
0
Nelson
2/24/2007 8:47:55 PM
Jonadab the Unsightly One wrote:
> Gervase Markham <gerv@mozilla.org> writes:
> 
>> Myk Melez wrote:
>>> One option would be to display (and emphasize) the port if isn't the
>>> default port for the given protocol.  The port would almost never
>>> appear, and thus it wouldn't be in the way most of the time but
>>> might raise a red flag when it does show up.
>> That's certainly an interesting idea.
> 
> Except for the emphasis (which is probably a good idea), isn't this
> basically what already happens?  I don't see :80 all the time, but I'm
> pretty sure that if I use a URL with a non-standard port, it doesn't
> currently get hidden.

Yes, this is what currently happens, but it wasn't part of Gerv's 
proposal (at least not explicitly), and he wrote that he wasn't sure 
what to do about the port, hence the suggestion.

-myk
0
Myk
2/25/2007 4:30:56 AM
ksulli@volny.cz writes:

> I haven't seen it mentioned yet - please display urlescaped characters
> properly. Many languages just don't work with ascii very well... which
> is more understandable
> http://ja.wikipedia.org/wiki/��0�0�0�0�0�0�
> or
> http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8

The second one is more understandable.  It's messy, but I can at least
tell that there are a number of *different* characters there, and waht
their hex values are if I'm technically inclined.  On the first one,
all I can do is count how many characters there are.

Frankly, though, I'd consider this a l10n issue.  Font and display
issues aside, I don't _want_ to see characters in the URL bar that I
can't type on my keyboard.  For me, that means printable ASCII
characters only, and anything else should be escaped.  Of course for
someone else it might mean a different set of characters -- which is
where localization comes in, IMO.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/25/2007 10:40:33 PM
Rimas Kudelis <rq@i.hate.spammers.very.much.---.akl.lt> writes:

> > 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.
> 
> You don't need a favicon to do that. I liked the proposal to display
> different icon for different protocols here (The lock being an icon
> for https sites). So the user could use that protocol-specific icon
> to create a bookmark, IMO.

That leaves the protocol icon for http looking like the place where
the favicon should go, so that everyone who sees it thinks favicon
support has regressed again.

> > 8) Analyse font choice carefully
> > 
> It hurts my eyes when some �bercool application decides for me what
> fonts/colors/button styles etc I want to use in that application,
> I'm almost always against that. 

Yeah, me too.

> Well, there always are exceptions, for example, I like the way how
> address bar changes its color in Firefox, depending on SSL state.

Ack!  I really hate that one.  Forcing terrible colors is *way* worse
than forcing bad fonts.  It's bright yellow, for crying out loud!  Who
invited bright yellow onto my desktop?  One of the reasons I never
browse the web with page colors enabled is because webmasters pull
stunts like that.  I selected perfectly good colors at the widget set
level; the application has ABSOLUTELY NO BUSINESS forcing its
particular garish taste in colors on me.  It's *WRONG*.

Fortunately I don't use https very much.  But still.

> However, for example, in Linux, you're simply never sure what fonts
> are available and if they are the best choice. Using monospace font
> could be a solution, however, still it's a customization and a
> departure from what the user has chosen in his global UI prefs (or
> what the OS vendor has chosen for the user).

I think it's vitally important to let the user override the font
choice and say, "No, use *this* font that I actually *like*".
However, there is good rationale behind shipping with a carefully
selected default font.  It would be great to use the user's chosen
font if the user chose one, but an unfortunate limit of the choosing
mechanism on most systems is that you can't tell for sure if the user
chose it on purpose or not.

Ideally, what the browser should do is this:

 1. If the user has expressed a preference for a certain font in the
    browser prefs themselves, use that.
 2. Otherwise, if the system administrator has set up a preference
    for a certain font in the site-level browser settings, use that.
 3. Otherwise, if the user has expressed a preference for a certain
    font at the OS or widget-set level (e.g., a GTK theme), use that.
 4. Otherwise, if the system administrator has set up a preference
    for a certain font at the OS or widget-set level, use that.
 5. Otherwise (over 90% of all cases) use a font that ships with
    the browser, chosen for its clarity in visibly distinguishing 
    each different character.

Unfortunately, as far as I'm aware, there is no way to determine the
difference, at the OS or widget-set level, between "user has expressed
a preference" versus "user left the setting at the default".

And the OS or widget-set default font is usually chosen with things
*other* than URLs in mind.  In particular, it's often a proportional
font (sometimes even sans-serif proportional) that does a fairly poor
job of distinguishing characters like l, 1, I, O, 0, and so on.  (The
Arial font that ships with most versions of MS Windows is particularly
wretched in this regard.)  In the normal text scenarios for which the
font is generally chosen, this is a total non-issue, but for a browser
URL bar it *is* an issue, and not just due to phishing.  A more
legible font is just a generally better thing for the URL bar.

So my vote would be for this:

 1. If the user has expressed a preference for a certain font in the
    browser prefs themselves, use that.
 2. Otherwise, if the system administrator has set up a preference
    for a certain font in the site-level browser settings, use that.
 3. Otherwise, if the user checks the "please use my system font"
    checkbox, then use that.
 4. Otherwise (over 90% of all cases) use a font that ships with
    the browser, chosen for its clarity in visibly distinguishing
    each different character.
    
This lets users like you and me override it with the font we prefer,
but it provides ordinary users (who mostly don't notice fonts anyhow)
with the ability to clearly read the URL bar without confusing
characters with one another; among other things, this helps a little
against spoofing, though of course it's far from complete protection.

BTW, there is really no excuse why about:config doesn't seem to have
any way to shut off or otherwise change the stupid bright yellow
background for https URLs.  Thou Shalt Not Hardcode Colors is one of
the ten commandments of UI design, as far as I'm concerned, and while
I understand the rationale behind using a color by default (though not
for choosing yellow, a color normally associated with warnings and
danger, to indicate encryption of all things), I cannot imagine why
someone thought it would be okay to force this on the user with no
option to change it.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/26/2007 3:26:34 AM
Jonadab the Unsightly One wrote:
> BTW, there is really no excuse why about:config doesn't seem to have
> any way to shut off or otherwise change the stupid bright yellow
> background for https URLs.  Thou Shalt Not Hardcode Colors is one of
> the ten commandments of UI design, as far as I'm concerned, and while
> I understand the rationale behind using a color by default (though not
> for choosing yellow, a color normally associated with warnings and
> danger, to indicate encryption of all things), I cannot imagine why
> someone thought it would be okay to force this on the user with no
> option to change it.

It's neither "bright yellow" for me, nor hardcoded. It's pale
desaturated yellow, and depends on a theme you use AFAIK.

But OK, I can agree with the rest.

Btw after someones posting, I tend to think that the first click
should maybe focus whole URL, then the second should put the cursor in
place, then the third focus a particular fragment in URL, then with
the fourth we should start again. What would others say?

RQ
0
Rimas
2/26/2007 5:41:29 AM
Jonadab the Unsightly One wrote:
[...]
> BTW, there is really no excuse why about:config doesn't seem to have
> any way to shut off or otherwise change the stupid bright yellow
> background for https URLs.  Thou Shalt Not Hardcode Colors is one of
> the ten commandments of UI design, as far as I'm concerned, and while
> I understand the rationale behind using a color by default (though not
> for choosing yellow, a color normally associated with warnings and
> danger, to indicate encryption of all things), I cannot imagine why
> someone thought it would be okay to force this on the user with no
> option to change it.
> 

IIUC, userChrome.css can do it. Of course, it's one step "geekier" than 
about:config, which itself is "geekier" than the prefs UI.


Best regards,
Tony.
-- 
hundred-and-one symptoms of being an internet addict:
66. You create a homepage with the impression to cure the afflicted...but
     your hidden agenda is to receive more e-mail.
0
Tony
2/26/2007 5:59:13 AM
Rimas Kudelis wrote:
> Jonadab the Unsightly One wrote:
>> BTW, there is really no excuse why about:config doesn't seem to have
>> any way to shut off or otherwise change the stupid bright yellow
>> background for https URLs.  Thou Shalt Not Hardcode Colors is one of
>> the ten commandments of UI design, as far as I'm concerned, and while
>> I understand the rationale behind using a color by default (though not
>> for choosing yellow, a color normally associated with warnings and
>> danger, to indicate encryption of all things), I cannot imagine why
>> someone thought it would be okay to force this on the user with no
>> option to change it.
> 
> It's neither "bright yellow" for me, nor hardcoded. It's pale
> desaturated yellow, and depends on a theme you use AFAIK.
> 
> But OK, I can agree with the rest.
> 
> Btw after someones posting, I tend to think that the first click
> should maybe focus whole URL, then the second should put the cursor in
> place, then the third focus a particular fragment in URL, then with
> the fourth we should start again. What would others say?
> 
> RQ

I'd prefer one click to position the cursor, additional clicks to create or 
widen a selection around it.

To select the whole URL in one step, there is the Ctrl-L hotkey.


Best regards,
Tony.
-- 
"I'd love to go out with you, but the last time I went out, I never
came back."
0
Tony
2/26/2007 6:23:33 AM
   I use the Firefox and I'm beginning to learn the Firefox source code, how it works and so on.
  For this purpose i try to do my own code in the source code 
  In which folder do i find the files, when i try to add my own 
  pup ups and alerts boxes and etc. ?
  Thanks


Tony Mechelynck <antoine.mechelynck@belgacom.net> schrieb:  Jonadab the Unsightly One wrote:
[...]
> BTW, there is really no excuse why about:config doesn't seem to have
> any way to shut off or otherwise change the stupid bright yellow
> background for https URLs. Thou Shalt Not Hardcode Colors is one of
> the ten commandments of UI design, as far as I'm concerned, and while
> I understand the rationale behind using a color by default (though not
> for choosing yellow, a color normally associated with warnings and
> danger, to indicate encryption of all things), I cannot imagine why
> someone thought it would be okay to force this on the user with no
> option to change it.
> 

IIUC, userChrome.css can do it. Of course, it's one step "geekier" than 
about:config, which itself is "geekier" than the prefs UI.


Best regards,
Tony.
-- 
hundred-and-one symptoms of being an internet addict:
66. You create a homepage with the impression to cure the afflicted...but
your hidden agenda is to receive more e-mail.
_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefox@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox


 		
---------------------------------
Keine Lust auf Tippen? Rufen Sie Ihre Freunde einfach an.
  Yahoo! Messenger. Jetzt installieren . 
0
henry
2/26/2007 8:27:20 AM
Nelson Bolyard wrote:
> I am not the one who proposes that we should abandon CAs for SSH-style
> cert management.  The person who has repeatedly proposed that is not
> presently participating in this discussion, but it appears to be his
> life mission to do whatever it takes to see that proposal come to pass.
>
> I am trying to get people to think of the consequences.  People who think
> that massive MITM attacks are impractical don't know about Netsetter.
>   

OK, that is fine.

Can you give a name? Because you replied to *me*, and made it appear 
that your scenario applies to *my* proposal, which is certainly does not 
at all.

> I will also point out that if you let self-signed certs work as quietly as
> certs from legitimate CAs, nothing will stop banks from using self-signed
> certs.
> I agree that the proposal to use SSH style cert management is total nonsense.
>   

OK, just to clarify (I have already mentioned that in previous posts):

I think it's "total nonsense" to treat self-signed certs the same as 
verified CA-issued certs (emphasis on verified ;-) ).

I *do* think that storing certs seen and demanding that they are used in 
the future for that site is a good idea, and would considerably improve 
SSL security, because it puts CAs out of the picture between repeat 
visitors (95+% of all usage), CAs only provide the *initial* trust, 
which I think reflects reality. It means that a Class 1 can't get 
between a user and a Class 3 bank cert, and VeriSign can't get between 
me and web.de which uses trustcenter.de or whatever.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
2/27/2007 12:29:28 AM
Jonadab the Unsightly One wrote:
> Naturally, there numerous are other banks in Ohio, let alone in the
> whole USA, called First Federal Bank or First Federal Savings & Loan,
> which have no affiliation with this one.  

Interesting. Do they get problems with people coming in and assuming 
they are a branch of another, unrelated by identically-named bank? Could 
you ask your friend about it?

Gerv
0
Gervase
2/27/2007 10:24:22 AM
Jonadab the Unsightly One schrieb:
> As noted, I think the Mozilla application suite ought to include one,
> and as far as I'm aware it really does not.

I'm fully with you. If someone wants to get this going in SeaMonkey, I 
guess we'd be pretty happy about that. Might make a good Summer of Code 
project if someone's interested.

Robert Kaiser
0
Robert
2/27/2007 3:28:32 PM
Gervase Markham wrote:
> Heikki Toivonen wrote:
>> My concern about hiding the domain was about potential situations where
>> the same company controls multiple domains. Maybe you can tell the
>> difference from the content, maybe not (I have tried to search Google
>> myself several times, without realizing I was on Google News).
> 
> Then that's a bug in Google's site. :-)

That is just one example I could think of. But anyway, seeing

Example Business, Inc. /

in the location bar when I typed https://badhairdaysrus.com and
https://flossrecycling.com is not helping me.

>> Also, if I were to take
>> a screenshot of a browser window showing
>>
>> Example Business Inc. / main.php
>>
>> and make a bug report saying that web page does not lay out properly in
>> Firefox, you'd be pretty frustrated...
> 
> Perhaps. But you will admit this is a very niche case.

I actually meant it as an example of a very common case: screenshots.
Magazines, newspapers, news broacdasts and movies to mention just few
examples have screenshots of browser windows open where you can see the
actual URL without needing to include it in the caption, article text or
narrative or show the user typing the actual URL or whatnot.

-- 
  Heikki Toivonen
0
Heikki
2/28/2007 8:33:54 AM
Gervase Markham <gerv@mozilla.org> writes:

> Jonadab the Unsightly One wrote:
> > Naturally, there numerous are other banks in Ohio, let alone in
> > the whole USA, called First Federal Bank or First Federal Savings
> > & Loan, which have no affiliation with this one.
> 
> Interesting. Do they get problems with people coming in and assuming
> they are a branch of another, unrelated by identically-named bank?

At the public library where I work we occasionally get people bringing
in their library card from other public libraries in other cities and
expecting to be able to use it.  Because, you know, it's a public
library, so naturally it must be related to all other public libraries
everywhere, don't you know.

This does not invalidate the fact that practically every city,
village, or rural township in the US has a public library, and many of
them have a bank called First Federal Bank (or something very similar)
as well.  ("First National Bank" is also quite common.)  Sometimes the
name of the city will be included in the name of the thing, sometimes
not.  Names of businesses are not required to be unique at the state
or national level.  

What I can't figure out is how this could be different in any country
that allows random citizens to start and name their own businesses.
You claim that in England the names of businesses are required to be
unique at the national level.  Does that mean you can't start a
business called "Gerv's Consulting" or "Markham's Pizza" without
checking with your national government to see if it's okay?

I can assure you that it's not that way everywhere in the world.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
2/28/2007 1:40:10 PM
Jonadab the Unsightly One wrote:
> Gervase Markham <gerv@mozilla.org> writes:
> 
>> Jonadab the Unsightly One wrote:
>>> Naturally, there numerous are other banks in Ohio, let alone in
>>> the whole USA, called First Federal Bank or First Federal Savings
>>> & Loan, which have no affiliation with this one.
>> Interesting. Do they get problems with people coming in and assuming
>> they are a branch of another, unrelated by identically-named bank?
> 
> At the public library where I work we occasionally get people bringing
> in their library card from other public libraries in other cities and
> expecting to be able to use it.  Because, you know, it's a public
> library, so naturally it must be related to all other public libraries
> everywhere, don't you know.
> 
> This does not invalidate the fact that practically every city,
> village, or rural township in the US has a public library, and many of
> them have a bank called First Federal Bank (or something very similar)
> as well.  ("First National Bank" is also quite common.)  Sometimes the
> name of the city will be included in the name of the thing, sometimes
> not.  Names of businesses are not required to be unique at the state
> or national level.  
> 
> What I can't figure out is how this could be different in any country
> that allows random citizens to start and name their own businesses.
> You claim that in England the names of businesses are required to be
> unique at the national level.  Does that mean you can't start a
> business called "Gerv's Consulting" or "Markham's Pizza" without
> checking with your national government to see if it's okay?
> 
> I can assure you that it's not that way everywhere in the world.
> 

In Belgium I /think/ business names have to be unique at the national level 
but maybe it's only at the "arrondissement" level (part of a province, 
jurisdiction of a "Tribunal de Premi�re Instance" and of a "Tribunal de 
Commerce"). Although "goods and people" are supposed to be able to cross 
intra-EU borders without restriction since, er, 1983 IIRC, I believe business 
names don't have to be unique at EU level (but maybe someday they will have to).

Starting a business in Belgium includes getting a registration. That used to 
mean both a "Register of Commerce" number at the clerk's office of the local 
Tribunal of Commerce and a national VAT (value-added tax) number from the 
Ministry of Finances but recently the system has been more fully computerized 
and the VAT number does double duty under a different name. That registration 
process will fail if, for instance, I try to use the same name as a different 
business in the same jurisdiction. In the case of franchises I think the 
franchisee's business is registered under a different name than the brand name 
on the sign.

Best regards,
Tony.
-- 
The optimum committee has no members.
		-- Norman Augustine
0
Tony
2/28/2007 2:49:10 PM
Nelson Bolyard wrote:
> yes.  It uses certs issued by a test CA, so first download/install the
> test root cert, then do the SNI tests, then remove trust from the root
> CA cert you downloaded.
> 
> The root CA cert is at https://bob.sni.velox.ch/root.crt
> the https virtual servers, which all share a common IP address and port,
> are at these URLs:
> 
> https://alice.sni.velox.ch/
> https://bob.sni.velox.ch/
> https://carol.sni.velox.ch/
> https://dave.sni.velox.ch/

Odd. Alice, Carol and Dave all work (wahey!), but Bob says:

"Unfortunately, your client [Mozilla/5.0 (X11; U; Linux i686; en-US; 
rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1]  did not send a TLS server 
name indication extension (RFC 4366) in its ClientHello (negotiated 
protocol: SSLv3), so you're probably getting warnings about certificate 
name mismatches."

....but I don't get warnings. Bug in the server or bug in Firefox? Should 
I email the admin?

Gerv
0
Gervase
3/1/2007 6:09:17 PM
Gervase Markham wrote:
> Nelson Bolyard wrote:
>> yes.  It uses certs issued by a test CA, so first download/install the
>> test root cert, then do the SNI tests, then remove trust from the root
>> CA cert you downloaded.
>>
>> The root CA cert is at https://bob.sni.velox.ch/root.crt
>> the https virtual servers, which all share a common IP address and port,
>> are at these URLs:
>>
>> https://alice.sni.velox.ch/
>> https://bob.sni.velox.ch/
>> https://carol.sni.velox.ch/
>> https://dave.sni.velox.ch/
> 
> Odd. Alice, Carol and Dave all work (wahey!), but Bob says:
> 
> "Unfortunately, your client [Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1]  did not send a TLS server
> name indication extension (RFC 4366) in its ClientHello (negotiated
> protocol: SSLv3), so you're probably getting warnings about certificate
> name mismatches."
> 
> ...but I don't get warnings. Bug in the server or bug in Firefox? Should
> I email the admin?

if you don't get a warning, it means you received a valid cert that
matches the host name in the URL.

when i tried this (again) I did not get that message.  I got the message:

> Great! Your client [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9a3pre) Gecko/20070227 SeaMonkey/1.5a] sent the following TLS server 
> name indication extension (RFC 4366) in its ClientHello:
> 
>   bob.sni.velox.ch

I think I know why you're seeing that error.
If you took more than 6 seconds to dismiss the cert dialog on your first
visit, PSM incorrectly concluded that the site is TLS-intolerant, and
marked it so that thereafter PSM would only use SSL3, not TLS, to talk
to it.  We only do SNI when talking TLS, not for SSL3.
See https://bugzilla.mozilla.org/show_bug.cgi?id=368126
0
Nelson
3/1/2007 8:09:11 PM
Nelson Bolyard wrote:
> beltzner wrote:
>> On 2/20/07, Gervase Markham <gerv@mozilla.org> wrote:
>>> Robert Kaiser wrote:
>>>> For the plain reason that they are at least immune against passive
>>>> sniffing, I think there should still be some indication that they are
>>>> different from real plain HTTP. Not sure though what indication is best
>>>> for that.
>>> The problem as I see it is that we need to come up with an indicator
>>> which does both of these things:
>>>
>>> - Does _not_ give 99% of users any sense of being more "secure"
>>> - Tells the 1% of users that the specific, limited non-eavesdroppability
>>> they wanted is in place.
>> The problem is that right now we only have one indicator of "secure"
>> and that's 1:1 related with SSL, which doesn't mean "secure".
> 
> Mike, the only people who claim that the lock means "secure" are the people
> who want to do away with it.

And the 800+ million people using the web who aren't involved in browser 
development, web development, or security research.

- A
0
Asa
3/2/2007 3:22:24 AM
"Jonadab the Unsightly One" <jonadab@bright.net> writes:

> This does not invalidate the fact that practically every city,
> village, or rural township in the US has a public library, and many
> of them have a bank called First Federal Bank (or something very
> similar) as well.  ("First National Bank" is also quite common.)
> Sometimes the name of the city will be included in the name of the
> thing, sometimes not.  Names of businesses are not required to be
> unique at the state or national level.

I thought of another example.  There two different public libraries in
the state of Ohio (and probably some in other states as well) called
Carnegie Public Library.  The only relationship that they have to one
another (besides both being libraries) is that they're both named
after Andrew Carnegie.

They each have their own unique domain name however:
http://www.carnegie.lib.oh.us/
http://www.cplwcho.org/

Those are just the ones, in Ohio, where "Carnegie Public Library" is
the whole entire name of the library.  (There are also numerous
libraries with names of the form "Fooville Carnegie Public Library".)

I know, public libraries aren't businesses, but nonetheless, I think
the point is made here.  Fully qualified internet domain names are
globally unique because DNS was *designed* that way, deliberately.

-- 

v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
0
Jonadab
3/2/2007 5:17:41 PM
Reply:

Similar Artilces:

Changing the firefox 3 location bar to firefox 2 behavior
Name: Clarence Product: Firefox Summary: Changing the firefox 3 location bar to firefox 2 behavior Comments: There is currently no simple way to change the "smart" location bar back to firefox 2 behavior. Changing the number of maxRichResults to 0 simply disables the dropdown completely but does not give the old firefox 2 behavior. Please consider adding the option of switching back to the old behavior as the new "smart" location bar is very intrusive for some. Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Fire...

I like the location bar from old Firefox better, Firefox 3 sucks
Name: Jon Ciarkowski Email: ciarkowskidotjonathanatgmaildotcom Product: Firefox Summary: I like the location bar from old Firefox better, Firefox 3 sucks Comments: I recently downloaded Firefox 3 and I am completely frustrated and unhappy with the new smart location bar. I like the old location bar where I could just type the websites into it and they would stay there until my history was erased. The old location bar did not show every web page and bookmarked site I had visited, just the ones I actually typed into the bar. This new location bar shows everything, which just ma...

"Awesome" bar has replaced location bar on Firefox 3
Name: Rob Muck Email: RobertMuckatgmaildotcom Product: Firefox Summary: "Awesome" bar has replaced location bar on Firefox 3 Comments: I frequently used the location bar on FF 2. In FF 3 all I have is this other thing which may or may not be useful. As a result I uninstalled version 3 until a fix is released that will allow me to disable this feature so that the location bar functions as it did in version 2. It would be even better if you could somehow use both. I would then try out the so called "Awesome" bar as long as I still had the functionality ...

firefox location bar
How does one clear the firefox location bar pull down menu? What is the name of the file that saves contents of that pull down menu? Tnx, Charles shift+del, use the right del if you are on Mac Charles wrote: > How does one clear the firefox location bar pull down menu? FF1.0_Linux: Edit/Prefs/Privacy/History -- Blinky Linux Registered User 297263 Blinky the Shark wrote: > Charles wrote: > > > How does one clear the firefox location bar pull down menu? > > FF1.0_Linux: Edit/Prefs/Privacy/History > > -- &...

Firefox 3 location bar
Name: Sanjay Email: sanjaydotsurendranatgmaildotcom Product: Gran Paradiso Summary: Firefox 3 location bar Comments: It would had been nice if the location bar can understand the bookmark names. For example if i save www.mozilla.org with the name "Moz" . and at a later point if i just enter Moz into the location bar it must open the site www.mozilla.org. Browser Details: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2 ...

Firefox location bar history
I don't want a drop down list of URLs in the location bar - how to get rid of it? There was an option in Mozilla perferences which isn't in Firefox, and I've tried setting browser.sessionhistory.max_entries to 0 or -1, to no avail. pete_griffint@hotmail.com (Pete Griffint) wrote: > I don't want a drop down list of URLs in the location bar - how to > get rid of it? There was an option in Mozilla perferences which > isn't in Firefox, and I've tried setting > browser.sessionhistory.max_entries to 0 or -1, to no avail. Clear desired infomation at: ...

Location Bar Proposal #2
[Note: also posted to my blog[0].] For the past few weeks, we've been playing with various ideas relating to the Location Bar here in mozilla.dev.apps.firefox[1]. Dao Gottwald has been doing a great job keeping up with the suggestions, and implementing them in the excellent LocationBar2 extension[2]. Having done the prototyping, and a UI review with Jonathan Nightingale and Mike Beltzer, we now propose that we do the following two independent things, as a start: 1) Remove the favicon from the URL bar. We want to make the URL bar totally trusted, and that means not allo...

Firefox 3 Location Bar
Name: Kevin Email: superkc9athotmaildotcom Product: Firefox Summary: Firefox 3 Location Bar Comments: The new location bar in Firefox 3 should have the option to only search URL's and not titles, as well as the option to search URL's before titles. For example, if I start typing mozi, mozilla.org or www.mozilla.org before it shows things with mozilla in the title or before addons.mozilla.org. The location bar is also more cluttered now with the titles showing. I have bookmarks and a history browser if want to look up titles. The location bar is where I type URL&#...

Go button remains in location bar after location bar changes are undone.
Name: Ethan Email: ethanisatgmaildotcom Product: Gran Paradiso Summary: Go button remains in location bar after location bar changes are undone. Comments: If you navigate to a page, then edit the contents of the location bar, the Go button replaces the star, as expected. But if you undo (Ctrl + z, Cmd + z, etc.) your changes and click elsewhere (take the focus off of the location bar), the Go button remains. It would make sense to check to see if the location bar has changed and if it has not to return the current page's icons (feed icon, star, etc.). This way if the user...

superreview canceled: [Bug 406894] Icons in the location bar and search bar need hover and depressed states (web feed)(star)(location bar)(bookmarks) : [Attachment 318028] patch
Kai Liu <kliu.bugzilla.3c9f@mail.kailiu.com> has canceled Kai Liu <kliu.bugzilla.3c9f@mail.kailiu.com>'s request for superreview: Bug 406894: Icons in the location bar and search bar need hover and depressed states (web feed)(star)(location bar)(bookmarks) https://bugzilla.mozilla.org/show_bug.cgi?id=406894 Attachment 318028: patch https://bugzilla.mozilla.org/attachment.cgi?id=318028&action=edit ...

superreview requested: [Bug 406894] Icons in the location bar and search bar need hover and depressed states (web feed)(star)(location bar)(bookmarks) : [Attachment 318028] patch
Kai Liu <kliu.bugzilla.3c9f@mail.kailiu.com> has asked Mike Beltzner <beltzner@mozilla.com> for superreview: Bug 406894: Icons in the location bar and search bar need hover and depressed states (web feed)(star)(location bar)(bookmarks) https://bugzilla.mozilla.org/show_bug.cgi?id=406894 Attachment 318028: patch https://bugzilla.mozilla.org/attachment.cgi?id=318028&action=edit ------- Additional Comments from Kai Liu <kliu.bugzilla.3c9f@mail.kailiu.com> Since nobody is taking this bug... In addition to adding hover states, this patch also addresses the issue...

firefox 3 address/location bar
Name: nara Product: Firefox Summary: firefox 3 address/location bar Comments: please provide an option to prevent the address bar from displaying bookmark matches. This is very annoying when one has personal bookmarks and everyone can see it.. Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/2.0;MEGAUPLOAD 1.0 From URL: http://hendrix.mozilla.org/ ...

Firefox V3 location bar SUCKS!!!!!!!!!!!!
Name: Mark C. Product: Firefox Summary: Firefox V3 location bar SUCKS!!!!!!!!!!!! Comments: I thought I would come home from work and install the latest and greatest from Mozilla. After the install I went to use my address bar as I have since browsers were invented and too my dismay it is using my bookmarks. If I want to use my bookmarks I will click on the bookmarks, but for a single address....WHY CAN'T I USE THE ADDRESS BAR? I am going to uninstall V3 and go back to 2 as V3 sucks Browser Details: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/20080529...

firefox 3 location bar autocomplete
Name: Chris Vasey Email: cvaseyatiinetdotnetdotau Product: Firefox Summary: firefox 3 location bar autocomplete Comments: I love firefox. but this is not on. within 2 minutes of use i'm nearly ready to roll back to FF2. All because of the location bar. :( Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0 From URL: http://hendrix.mozilla.org/ ...

Web resources about - Location Bar Proposal - mozilla.dev.apps.firefox

List of Massachusetts locations by per capita income - Wikipedia, the free encyclopedia
Text is available under the Creative Commons Attribution-ShareAlike License ;additional terms may apply. By using this site, you agree to the ...

Just a fortnight after fifth Beijing location, 28th Chinese Apple Store opening on Saturday
... for more breaking coverage of AAPL Company , Apple Store , and china . What do you think? Discuss "Just a fortnight after fifth Beijing location, ...

Google Shares Black Friday Location Data for Marketers
... releasing a host of updates and features for marketers and consumers leading up to the holiday season. Its latest offering will share location-based ...

‘Time’ Shares Most Instagrammed U.S. Locations by State
What were the most Instagrammed locations in all 50 U.S. states in 2015? Time used data from the Facebook-owned photo- and video-sharing network ...

Madrona Venture Groups invests $6M in location awareness startup
The Puget Sound region’s most active venture capital firm just made another multi-million dollar investment in a location awareness startup. ...

This new app lets you summon your friends to your location with an Uber ride that's already paid for
... friend you want to send an Uber to and the app sends them a request. When your friend accepts the request, their phone sends the app a location ...

Jon Bon Jovi Joins NFL, Bruin Sports Capital and RedBird Capital in On Location Experiences Partnership ...
On Location Experiences (previously NFL On Location), a premium experiential hospitality business jointly owned by RedBird Capital Partners, ...

Multiple McDonald’s Locations Forced To Close After Prank Callers Convince Workers To Test Fire System ...
... to activate fire suppression systems, spewing chemicals over kitchen appliances. The East Oregonian reports that five McDonald’s locations ...

Wagamama Ramen Chain to Open First New York Location Next Year
The London-based chain has 140 location across the world. Popular Japanese food chain Wagamama is finally making its New York debut, the Post ...

Temp tech tattoos can monitor your health and location
Chaotic Moon, a start-up known for conjuring fun projects like a shark-punching virtual game, has a wide range of applications in mind for the ...

Resources last updated: 12/10/2015 1:09:29 PM