Firefox3/Location Bar: Difference between revisions

m
no edit summary
mNo edit summary
Line 22: Line 22:
===Hide the scheme when URL bar not focussed/hovered===
===Hide the scheme when URL bar not focussed/hovered===


The schemes "http://", "https://", "ftp://" and "file://" should be hidden when the URL bar is not focussed. 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 for such certificates, which is just to throw an error.
The schemes "<code>http://</code>", "<code>https://</code>", "<code>ftp://</code>" and "<code>file://</code>" should be hidden when the URL bar is not focussed. 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 for such certificates, which is just to throw an error.


===Hide username and password===
===Hide username and password===


This is the "foo:bar" in http://foo:bar@hostname.com. 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.
This is the "<code>user:pass</code>" in <code>&#104;ttp://user:pass@example.com</code>. 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.
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.
Line 34: Line 34:
Take the [[Gecko:Effective_TLD_Service|Effective TLD]] +1 (or +2 - to be decided) and highlight it in some way to be decided, which may have to be locale-dependent. So:
Take the [[Gecko:Effective_TLD_Service|Effective TLD]] +1 (or +2 - to be decided) and highlight it in some way to be decided, which may have to be locale-dependent. So:


www. EXAMPLE.COM /foo/bar/baz?q=x
www. EXAMPLE.COM /pathname?query#fragment


where capital letters indicate some sort of styling such as bold, underline, italic, colour or border. (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 either side of the highlighted text.
where capital letters indicate some sort of styling such as bold, underline, italic, colour or border. (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 either side of the highlighted text.


For file:// URLs, you'd have no highlighting, as there's no domain.
For <code>file://</code> URLs, you'd have no highlighting, as there's no domain.


If the port is non-standard, it is also included in the highlighted part, separated as normal by a colon.
If the port is non-standard, it is also included in the highlighted part, separated as normal by a colon.
Line 46: Line 46:
For HTTPS connections with EV certificates, prepend the hostname with the O (Organisation) and C (Country) fields from the certificate. So:
For HTTPS connections with EV certificates, prepend the hostname with the O (Organisation) and C (Country) fields from the certificate. So:


[* Paypal, Inc.] - www. PAYPAL.COM /foo/bar/baz?q=x
[* Paypal, Inc.] - www. PAYPAL.COM /dir/filename?key=value


We replace the hostname in geographical space, while still making it visible further to the right. This means there's a really big difference between the real site and an attempted spoof, which would have a domain name in that space rather than a textual name.
We replace the hostname in geographical space, while still making it visible further to the right. This 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.
Line 60: Line 60:
Favicons in the URL bar are dangerous, because they represent the website having some control over what's in the chrome. This danger 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. We would keep the favicon on tabs, of course.
Favicons in the URL bar are dangerous, because they represent the website having some control over what's in the chrome. This danger 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. We would keep the favicon on tabs, of course.


This could lead to 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. Perhaps this issue needs to be separated out.
This could lead to making the tab bar always visible - i.e. setting <code>browser.tabs.autoHide</code> 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. Perhaps this issue needs to be separated out.


I believe that the only function of the page-proxy-icon (where the favicon appears) is to be draggable to create e.g. bookmarks toolbar entries. We'd need to replace that function somehow. To be decided.
I believe that the only function of the page-proxy-icon (where the favicon appears) is to be draggable to create e.g. bookmarks toolbar entries. We'd need to replace that function somehow. To be decided.
Line 96: Line 96:
* Triple-click selects everything
* Triple-click selects everything


URL bar selection behaviour has been [https://bugzilla.mozilla.org/show_bug.cgi?id=190615 discussed before], in a bug which requests that layout.word_select.stop_at_punctuation be set to true on all platforms.
URL bar selection behaviour has been [https://bugzilla.mozilla.org/show_bug.cgi?id=190615 discussed before], in a bug which requests that <code>layout.word_select.stop_at_punctuation</code> be set to true on all platforms.


===Analyse font choice carefully===
===Analyse font choice carefully===
5

edits