Location Bar Proposal 1.2
Gervase Markham
attempt. No further big changes, just made the text consistent.]
Some excellent arguments in the previous thread have changed my mind on
certain issues. So I'm posting a revised proposal here. I thought a new
thread rather than a continuation would be better, so it's clear which
proposal people are addressing.
The changes do, of course, raise some further questions. And none of
them are set in stone - feel free to try and persuade me back again if
you think they aren't improvements :-)
Big changes:
A) Clicking the hostname no longer takes you to the root of the site. I
agree, this should remain an in-page navigation option. Lots of sites
provide it already, so it's not all that useful. This means that
clicking it allows editing, just as with the rest of the URL, which is
consistent. Also, removing it allows us to do:
B) URL bar changes to a text box on hover as well as on focus. (We
couldn't do this before, as otherwise the hostname button would be
unclickable.) This makes it much easier to click where you want to to
select part of the URL, because you are clicking where the caret will
actually end up, rather than clicking in one place, the form of the bar
changing on focus, and the caret actually appearing in another place
(albeit between the same, clicked letters).
We could even make it so that the URL bar changes mode when the mouse
was over any part of the chrome, not just the URL bar itself. That means
that if you moved the mouse from the content towards the URL bar, it
would have changed by the time you arrived, and you could aim at the
right spot. The exact algorithm would require some careful tuning.
Perhaps it could fade quickly between the two forms so as not to be too
visually jarring.
This means we can also say:
C) It's not so important that things don't shift around when the URL bar
changes modes - because the shift now happens on hover (even just
getting close), rather than on focus, so you can move the mouse, see the
shift, and then click where you want the caret to be and it'll stay there.
This means that:
D) We can show the scheme in the text version, without worrying about
the jumping around. This removes some concerns people had about hiding
the scheme totally. (It's still hidden in the non-text version.)
Removing "click the hostname" also means that:
E) We highlight Effective TLD + 1, not the entire hostname. There's no
need to highlight the entire hostname because "it might be where people
want to go when they click" - that rationale is removed. Sticking with
Effective TLD + 1 removes the spoofing possibilities of highlighting all
of microsoft.com.foo.bar.evil.com.
F) I have changed to Ben and Rimas's suggestion of _prepending_ the EV
information to the domain name. IE has it on the far right, but I think
prepending it works well, because it's then in the position the domain
name used to be, and yet the domain name is still visible (and
highlighted). But I'd particularly like further discussion on this,
because it raises its own issues.
Location Bar Proposal 1.1
-------------------------
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 when URL bar not focussed/hovered.
The scheme (e.g. "http://", "ftp://") should be hidden 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.
2) Hide username and password
If present. This is the "foo:bar" in http://foo:b...@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.
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 the Effective TLD + 1 and highlight it (in some way to be decided).
So either:
www. EXAMPLE.COM /foo/bar/baz?q=x
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.
4) Display EV business name and country
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
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 now have two things highlighted; we'd need to do UI experiments to
see if that was confusing, and whether we should highlight them the same
or different, or whether we should drop the highlighting of the domain
name, or something else. The name and flag need to appear non-editable.
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 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.
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. We'd need to replace that function somehow. To be decided.
6) Focus/hover turns bar back to a text box
On focus/hover, 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, or pressing
Ctrl-L or equivalent, focusses the URL bar and makes the following changes.
If the domain name is styled in such a way that it looks "uneditable",
then the style changes to remove that impression. We should try and keep
enough style to make sure the domain is still picked out, if possible.
Any hidden information, such as the scheme, returns. The EV business
name and country identifier remain (as they aren't editable, so there's
no need to do anything to them). The URL bar acts as much like a single
text box as possible. This will lead to things shifting about; we'd need
to do tests to see if this was too jarring. I hope that the fact that it
changes on hover means that it isn't.
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").
For reference, the current behaviour is:
With layout.word_select.stop_at_punctuation=false (default on Linux):
Single-click places caret
Double-click selects everything
Triple-click also selects everything
In other words, the selection never takes account of the different parts
of the URL.
With layout.word_select.stop_at_punctuation=true (default on Windows):
Single-click places caret
Double-click selects out to punctuation
Triple-click selects everything
URL bar selection behaviour has been discussed before in this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=190615
which requests that layout.word_select.stop_at_punctuation be set to
true on all platforms.
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
Asrail
> A) Clicking the hostname no longer takes you to the root of the site. I
I Strongly agreed here. Some places (as <http://people.mozilla.com>)
don't have a useful top level domain page.
> B) URL bar changes to a text box on hover as well as on focus. (We
> couldn't do this before, as otherwise the hostname button would be
> unclickable.) [...]
Selecting a piece of text without the need to another click is good.
I was thinking we could have a in-between plain view and pretty view here.
There is here a concern about decoding URLs at this stage.
If I read:
http://pt.wikipedia.org/wiki/Açcão
and want to change to:
http://pt.wikipedia.org/wiki/Acção
That's fairly easy.
But if I see:
http://pt.wikipedia.org/wiki/A%C3%A7c%C3%A3o
and wanna change to:
http://pt.wikipedia.org/wiki/Ac%C3%A7%C3%A3o
That's harder. For Japanese and other ruby ones, that's even harder.
The user couldn't see anymore the exact place of the mistake (or another
thing he wanted to change).
Our URL bar threats this:
<http://pt.wikipedia.org/wiki/Ação (física)> correctly, so the user
could see the decoded URL while editing.
Copying with the spaces would break it almost everywhere, so FX could
encode them.
That would be a huge benefit for non speakers of a lot of languages around.
> We could even make it so that the URL bar changes mode when the mouse
> was over any part of the chrome, not just the URL bar itself. That means
> that if you moved the mouse from the content towards the URL bar, it
> would have changed by the time you arrived, and you could aim at the
> right spot. The exact algorithm would require some careful tuning.
What about the mouse arriving there by change? Because of switching windows?
This could lead to having a plain view when the user didn't want and
that could be confusing.
> [...]
> C) It's not so important that things don't shift around when the URL bar
> changes modes - because the shift now happens on hover (even just
> getting close), rather than on focus, so you can move the mouse, see the
> shift, and then click where you want the caret to be and it'll stay there.
When you point to something and it moves, that's annoying. But that's
better than the old proposal.
> This means that:
>
> D) We can show the scheme in the text version, without worrying about
> the jumping around. This removes some concerns people had about hiding
> the scheme totally. (It's still hidden in the non-text version.)
I believe everyone is happy here, but that could be further studied (see
above).
> Removing "click the hostname" also means that:
>
> E) We highlight Effective TLD + 1, not the entire hostname. There's no
> need to highlight the entire hostname because "it might be where people
> want to go when they click" - that rationale is removed. Sticking with
> Effective TLD + 1 removes the spoofing possibilities of highlighting all
> of microsoft.com.foo.bar.evil.com.
It's a must. No other idea should change this proposal, IMHO.
> F) I have changed to Ben and Rimas's suggestion of _prepending_ the EV
> information to the domain name. IE has it on the far right, but I think
> prepending it works well, because it's then in the position the domain
> name used to be, and yet the domain name is still visible (and
> highlighted). But I'd particularly like further discussion on this,
> because it raises its own issues.
The same clue as above about "don't move too much the things away".
Rimas Kudelis
> There is here a concern about decoding URLs at this stage.
> If I read:
> http://pt.wikipedia.org/wiki/Açcão
> and want to change to:
> http://pt.wikipedia.org/wiki/Acção
>
> That's fairly easy.
> But if I see:
> http://pt.wikipedia.org/wiki/A%C3%A7c%C3%A3o
> and wanna change to:
> http://pt.wikipedia.org/wiki/Ac%C3%A7%C3%A3o
>
> That's harder. For Japanese and other ruby ones, that's even harder.
> The user couldn't see anymore the exact place of the mistake (or another
> thing he wanted to change).
> Our URL bar threats this:
> <http://pt.wikipedia.org/wiki/Ação (física)> correctly, so the user
> could see the decoded URL while editing.
> Copying with the spaces would break it almost everywhere, so FX could
> encode them.
One more thing about it. Though not sure if the devs should take it
into account or not. In previous thread you mentioned a Japanese link.
Windows users may have problems with links like that, because
Windows often includes only support for typography of relevant
regions/languages by default, and doesn't add support for other
regions. For example, I don't think I could actually see CJK
hieroglyphs on my Windows machine.
Not sure if it's a concern though, as if your computer doesn't support
those symbols, you should have no need to visit pages that have them
even in URL... But well...
RQ
Kim Sullivan
> One more thing about it. Though not sure if the devs should take it
> into account or not. In previous thread you mentioned a Japanese link.
> Windows users may have problems with links like that, because
> Windows often includes only support for typography of relevant
> regions/languages by default, and doesn't add support for other
> regions. For example, I don't think I could actually see CJK
> hieroglyphs on my Windows machine.
>
> Not sure if it's a concern though, as if your computer doesn't support
> those symbols, you should have no need to visit pages that have them
> even in URL... But well...
It was me who posted the link to the japanese wikipedia, and I have a
plain XP Pro version of windows (it is even possible to enable
japanese keyboard input, a lot of people learning e.g. Japanese do
this). Even notepad in windows XP works in UTF-8 by default. The only
problem might be japanese fonts (because I'm not sure I didn't install
those manually... but they should be avaliable on the install CD). Is
it possible for FF to detect wether a particular glyph can be
displayed, and if not, revert to the url-encoded version of the whole
address?
(just out of curiosity, can you see the characters in
http://ja.wikipedia.org/wiki/メインページ ?)
Rimas Kudelis
That would be a pretty good solution, if possible...
> (just out of curiosity, can you see the characters in
> http://ja.wikipedia.org/wiki/メインページ ?)
Yes, but I'm on Linux now. :)
I don't mean to sound like an IE lover, but again, I like the way IE7
handles IDN, and I think we could expand this for anything concerning
the URL. And what they do is explained in [1].
RQ
Rimas Kudelis
> 4) Display EV business name and country
>
> 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
>
> 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.
hehe, take a look at a screenshot here:
http://blogs.msdn.com/ie/archive/2006/10/20/ie7-and-high-assurance-at-rsa-europe.aspx
RQ
Kim Sullivan
characters in paths... I hope I don't omit anything:
To increase readability of URLs, the path part of the URL should be
displayed as characters, not as an url-encoded string (the query part
should remain url-encoded, because it is not sure it doesn't contain
binary data). The status bar should match the display of the location
bar (currently, it displays all characters decoded, even whitespace).
Some issues that come to mind (or have been mentioned in previous
discussions):
- Whitespace handling. Whitespace characters should probably not be
decoded (this might allow URLs to overflow the visible area without
indication that this happened). They can either left encoded (e.g. %20
for a space), or they could be displayed similarly to "show
whitespace" mode in text editors and word processors (e.g. using
something like a middle dot for spaces). The first approach is
probably much easier to implement and a reasonable compromise between
readable urls and safety.
- How to display the anchor/fragment part of the URL?
- Missing fonts: What happens when an URL contains characters that
don't have a glyph installed on the system? Can Firefox detect a
missing glyph, and fall-back to the all-encoded version, or is it OK
to display a "missing glyph" (on some systems, its ?, on others an
empty rectangle)
- Editing/selection behavior: should the content of the location bar
change to the encoded version on location bar hover/select? (this
would be very hard to do seamlessly) This ties in closely with the
next issue:
- copy/paste behavior: Should the encoded or decoded URL be copied and
pasted? Is it possible to say "the contents of the clipboard are a
hyperlink, the destination is this encoded url, and the name is this
decoded url"? What if only a part of the URL is selected?
My personal opinion on these two: try to use the decoded version as
much as possible, both for editing and for cutting and pasting. FF, IE
and Opera seem to cope well with html pages that contain non-ascii
characters in hyperlinks, and the w3c validator says it's valid (I
assume that all browsers are smart enough to encode the URL anyway for
the http protocol). Switching between the encoded and decoded version
is a bit annoying (try the current 0.7.2.1 version of the LocationBar2
extension to see what I mean), and it prevents editing of the URL (as
mentioned by Asrail).
- Which character set/encoding? I'm not sure if this really is an
issue (and only applies when decoded URLs will be used for copying and
pasting anyway). What happens if you copy an URL that's UTF-8 to a
page that is written in ISO-8859-1 - should FF convert the characters
to the target character encoding, or paste them byte-by-byte (no
transformation)? Firefox defaults to UTF-8 (this can be a problem when
using keyword searches on search engines that default to a different
encoding, and probably affects URLs typed directly too).
Kim
Kim Sullivan
> Our URL bar threats this:
> <http://pt.wikipedia.org/wiki/Ação (física)> correctly, so the user
> could see the decoded URL while editing.
I'm sorry, are you talking about LocationBar^2, or maybe the one in
SM? The version of LocationBar^2 I'm using switches to the encoded url
for editing (which is a bit annoying).
Kim
Asrail
I'm talking the Gerv's proposal.
I already have tested every URL bar version available since version 0.5.
Not only the ones available at addons.mozilla.org.
As of version 0.8 it don't decode the URLs. As of 0.8.2 spaces are
re-encoded (I've seen this one right after sending the mail above).
But the comments here are about the Gerv's proposal, please, that
extension is just to play with the proposals.
I meant: the last one LocationBar2 doing something does not mean anything.
Dao Gottwald
> Kim Sullivan, 19-02-2007 20:34:
>> On Feb 19, 7:29 pm, Asrail <asr...@gmail.com> wrote:
>>> Our URL bar threats this:
>>> <http://pt.wikipedia.org/wiki/Ação (física)> correctly, so the user
>>> could see the decoded URL while editing.
>>
>> I'm sorry, are you talking about LocationBar^2, or maybe the one in
>> SM? The version of LocationBar^2 I'm using switches to the encoded url
>> for editing (which is a bit annoying).
>>
>
> I'm talking the Gerv's proposal.
> I already have tested every URL bar version available since version 0.5.
> Not only the ones available at addons.mozilla.org.
> As of version 0.8 it don't decode the URLs.
Sure it does.
Asrail
My fault, sorry...
read:
"As of version 0.8 it doesn't re-encode the URLs in the plain view."
The second part of that sentence was right, though =(.
Rimas Kudelis
> - How to display the anchor/fragment part of the URL?
Just the same way as the rest of the URL, I suppose.
> - Editing/selection behavior: should the content of the location bar
> change to the encoded version on location bar hover/select? (this
> would be very hard to do seamlessly) This ties in closely with the
> next issue:
I think it shouldn't.
> - copy/paste behavior: Should the encoded or decoded URL be copied and
> pasted? Is it possible to say "the contents of the clipboard are a
> hyperlink, the destination is this encoded url, and the name is this
> decoded url"? What if only a part of the URL is selected?
Formatted text? I'm not sure it's needed. But the idea is interesting...
> My personal opinion on these two: try to use the decoded version as
> much as possible, both for editing and for cutting and pasting. FF, IE
> and Opera seem to cope well with html pages that contain non-ascii
> characters in hyperlinks, and the w3c validator says it's valid (I
> assume that all browsers are smart enough to encode the URL anyway for
> the http protocol).
I think this is exactly browsers job. Hence, the validator doesn't
care. Well, (X)HTML specifications could be of a help here.
> Switching between the encoded and decoded version
> is a bit annoying (try the current 0.7.2.1 version of the LocationBar2
> extension to see what I mean), and it prevents editing of the URL (as
> mentioned by Asrail).
I agree.
> - Which character set/encoding? I'm not sure if this really is an
> issue (and only applies when decoded URLs will be used for copying and
> pasting anyway).
I don't think it's a problem. This should be handled exactly the same
way any other non-ASCII text is currently handled.
> What happens if you copy an URL that's UTF-8 to a
> page that is written in ISO-8859-1 - should FF convert the characters
> to the target character encoding, or paste them byte-by-byte (no
> transformation)? Firefox defaults to UTF-8 (this can be a problem when
> using keyword searches on search engines that default to a different
> encoding, and probably affects URLs typed directly too).
And this part is unrelated, as it applies to any other text too. I
think what Fx currently does in such situation is encodes all
characters that don't fit into page charset as HTML entities.
RQ
Gervase Markham
> hehe, take a look at a screenshot here:
> http://blogs.msdn.com/ie/archive/2006/10/20/ie7-and-high-assurance-at-rsa-europe.aspx
Yes, IE puts it to the right. What are you trying to tell me? I'm
confused...
Gerv
Gervase Markham
> To increase readability of URLs, the path part of the URL should be
> displayed as characters, not as an url-encoded string (the query part
> should remain url-encoded, because it is not sure it doesn't contain
> binary data). The status bar should match the display of the location
> bar (currently, it displays all characters decoded, even whitespace).
It would be great if someone could go away and read whatever documents
exist on IRIs (internationalised URLs) and let us know what stage those
specifications are at, and how they affect this question, if at all.
I'm hesitant to make suggestions as to how this should work without
consulting those docs.
Gerv
Dao Gottwald
> 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.
It would also mean that you could bold the domain without shifting
everything that comes after (which would then move around on hover).
Then again, bolding is possibly not an option because of the mentioned
problems with complex scripts.
The downside for me isn't that monospace fonts look ugly but that they
take away space.
Kim Sullivan
> It would be great if someone could go away and read whatever documents
> exist on IRIs (internationalised URLs) and let us know what stage those
> specifications are at, and how they affect this question, if at all.
To tell the truth, I'm not familiar to the standardization process,
but it seems that the RFC 3987 (http://www.ietf.org/rfc/rfc3987.txt)
is mostly ready. The only open issue seems to be something about
comparing IRIs, and last month there was a message to the public
mailing list regarding a bidi issue. This info can be found at
http://www.w3.org/International/iri-edit/. Several specifications
already assume the existence of IRIs (although they don't directly
reference the specification, the underlying principles are the same,
encoding non-ascii characters as UTF-8 and then percent-encode them).
The parts of the RFC that most apply to the current issue are the
conversion from/to URIs, and the rendering of IRIs.
Mapping IRIs to URIs is relatively straightforward, unicode characters
are encoded using UTF-8 and then percent-encoded.
Decoding URIs is a bit more complicated, because (simply speaking)
only "strictly legal UTF-8 octet sequences" can be shown as
characters, the rest has to be kept percent-encoded. This applies to
some other characters as well. The RFC doesn't explicitly mention
spaces, but says that "characters in US-ASCII not allowed in URIs"
have to be kept percent-encoded - as far as I understand, this covers
spaces (and other whitespace and control characters). Some unicode
characters aren't permitted either. The RFC is a bit vague on that,
but basically it says that "look-alikes" should be left percent
encoded. Some are obvious, like half-width Katakana or "space look-
alike" characters. Some, like "many others" [sic] are not so obvious.
The RFC allows unicode characters almost everywhere - including
fragment and query, and it even touches the issue of IDNs and
security.
Another important issue is rendering IRIs, because unicode text can be
bi-directional. This issue seems to be quite complex (because it
imposes additional constraints on what can be displayed and what has
to be kept percent-encoded). Also, each component of the IRI may use a
different directionality. The general rule seems to be that if an IRI
component can't be reliably displayed, the whole component has to be
displayed percent-encoded.
So, the RFC definitely is worth having a look, if only to see the
range of issues that arise from trying to fully support
internationalized resource identifiers.
Kim
Steffen Wilberg
> http://ja.wikipedia.org/wiki/メインページ ?)
On a German Windows XP SP2, I can't.
See http://en.wikipedia.org/wiki/Help:Multilingual_support_%28East_Asian%29
That page links to instructions on how to install support for complex
script, right-to-left and East Asian languages in various Windows versions.
Steffen
Kroc Camen
there may be a lot of uproar from removing the favicon from the URL
bar, tab discoverability in Firefox is practically 0. Both IE7 and
Opera have up-front default new-tab buttons. Firefox is very behind in
this respect.
I say the tab strip should be on by default, and a new-tab button
positioned to the left of the tabstrip (like this extension
https://addons.mozilla.org/firefox/1456/ ). I believe that there are
too many icons already in the URL bar so removing the favicon would
help declutter.
I also think Mozilla should grow some bite and fix a lot of the
ancient UI in Firefox. The home button should be the leftmost link on
the bookmarks toolbar, and not an actual button anymore (Home is just
a glorified bookmark). It could be distinguished by being bold and
having a sperator line to the right.
Peter Lairo
> I'm very much in agreement with point 5 (hide the favicon).
I'm not! It is an excellent way to visually recognize a site.
> Whilst
> there may be a lot of uproar from removing the favicon from the URL
> bar, tab discoverability in Firefox is practically 0. Both IE7 and
> Opera have up-front default new-tab buttons. Firefox is very behind in
> this respect.
IE achieved this by without *wasting* a lot of vertical space by
creating a really weird menu/icon-bar/tab-layout. I don't think some
dubious 2discovery" of tabs (which n00bs will be rare to use anyhow) is
worth all that.
--
Regards,
Peter Lairo
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Robert Kaiser
> a new-tab button
> positioned to the left of the tabstrip (like this extension
> https://addons.mozilla.org/firefox/1456/ ).
> I also think Mozilla should grow some bite and fix a lot of the
> ancient UI in Firefox. The home button should be the leftmost link on
> the bookmarks toolbar, and not an actual button anymore (Home is just
> a glorified bookmark).
Umm, interestingly, the SeaMonkey suite has both of them - and some
people always complain about the latter one and want "home" in the main
toolbar, while others love it in the bookmarks toolbar. I think that's
something only toolbar customization can resolve, as people want it in
different ways.
Robert Kaiser
Kroc Camen
hardcore people who are set in their ways. Those people can easily
customize the browser back to how they're used to. But Mozilla need to
get rid of archaic UI that doesn't make proper design sense anymore.
The Home button should be moved to the bookmarks bar for the benefit
of regular people, those who want a home button can just customize
their toolabr - they know how to.
Jean-Marc Desperrier
> The Home button should be moved to the bookmarks bar for the benefit
> of regular people, those who want a home button can just customize
> their toolabr - they know how to.
Hum, why not have inside the bookmarks, using the home icon instead of
the favicon, and allowing to add it back to the toobar by drag&drop ?
Flenser
> favicon appears) is to be draggable to create e.g. bookmarks toolbar
> entries. We'd need to replace that function somehow. To be decided.
The favicon on tabs behaves in the same way, although when you hover
the mouse cursor over it it doesn't change to the hand cursor the way
the page-proxy-icon does, so it isn't as discoverable.
Greg Campbell
> The home button should be the leftmost link on the bookmarks toolbar,
> and not an actual button anymore (Home is just a glorified bookmark).
> It could be distinguished by being bold and having a sperator line to
> the right.
Except many users don't use bookmarks at all. They certainly have no use
for the bookmarks toolbar; having it enabled at all is just wasting
vertical space. Home isn't really a glorified bookmark to these folks;
it's the panic button. It's the button you press when you've gotten
somewhere that seems scary and you want to go somewhere safe and
familiar so you can start over.
(And yes, the home button--and every other button--should be able to be
placed on any toolbar you want.)
Greg
Tony Mechelynck
> Kroc Camen wrote:
>> The home button should be the leftmost link on the bookmarks toolbar,
>> and not an actual button anymore (Home is just a glorified bookmark).
>> It could be distinguished by being bold and having a sperator line to
>> the right.
>
> Except many users don't use bookmarks at all. They certainly have no use
> for the bookmarks toolbar; having it enabled at all is just wasting
> vertical space. Home isn't really a glorified bookmark to these folks;
> it's the panic button. It's the button you press when you've gotten
> somewhere that seems scary and you want to go somewhere safe and
> familiar so you can start over.
I have some bookmarks but I have no use for the bookmarks _toolbar_ ; I prefer
the bookmarks _menu_ . OTOH I have a use for the Home button.
>
> (And yes, the home button--and every other button--should be able to be
> placed on any toolbar you want.)
>
> Greg
As it is now, and (AFAIK) that capability is not going to be removed any time
soon: click right on any toolbar, then "Customize", and start dragging.
Best regards,
Tony.
--
If everything is coming your way then you're in the wrong lane.
Heikki Toivonen
> 1) Hide the scheme when URL bar not focussed/hovered.
I still don't like this.
> 3) Highlight hostname
Add the port (if non standard for the protocol) to the highlighted
hostname part.
> 6) Focus/hover turns bar back to a text box
I just realized that changing the location bar from edit control to
anything else can present a challenge to accessibility API and software.
It would be good to involve Aaron Leventhal or other accessibility
people in this discussion.
--
Heikki Toivonen
Gervase Markham
> Gervase Markham wrote:
>> 1) Hide the scheme when URL bar not focussed/hovered.
>
> I still don't like this.
Have you played with the latest Locationbar2?
>> 6) Focus/hover turns bar back to a text box
>
> I just realized that changing the location bar from edit control to
> anything else can present a challenge to accessibility API and software.
> It would be good to involve Aaron Leventhal or other accessibility
> people in this discussion.
It's still an edit control as far as the XUL DOM is concerned.
Gerv
Jonadab the Unsightly One
Jonadab the Unsightly One
> One more thing about it. Though not sure if the devs should take it
> into account or not. In previous thread you mentioned a Japanese
> link. Windows users may have problems with links like that, because
> Windows often includes only support for typography of relevant
> regions/languages by default, and doesn't add support for other
> regions. For example, I don't think I could actually see CJK
> hieroglyphs on my Windows machine.
>
> Not sure if it's a concern though, as if your computer doesn't
> support those symbols, you should have no need to visit pages that
> have them even in URL... But well...
Sometimes you follow links. And sometimes the content of the pages is
(at least partly) in English, even though the domain is in .tw or
someplace like that.
Even if my computer *can* display these characters in the URL, it
shouldn't, because, I CAN'T READ THEM. "%057F" is at least
pronounceable in a pinch as "percent zero five seven eff" (or, if I
know what it means, "Unicode character zero five seven eff"), but the
actual character, if it's displayed, is just an arbitrary scribble.
In the page content it's another thing, or even the page title, but I
don't want off-the-wall characters in the location bar.
Display of non-ASCII characters in the URI should be l10n-dependent.
For en-us, it should be OFF by default. (Yes, many users can read
more than one language, so there obviously has to be a way to turn it
on, easily. I'm not sure what the UI for that should look like, but
there has to be one.)
Even for most multilingual users, there are way more unicode
characters that they *can't* read then there are ones that they can.
Turning on languages they can read would thus be more sensible than
turning off the ones they can't.
--
v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
Tony Mechelynck
> 剩浡猠䭵摥汩猠㱲煀椮桡瑥灡浭敲献癥特畣栮ⴭ慫氮汴㸠睲楴敳㨊ਾ‾ 橵獴畴映捵物潳楴礬慮⁹潵敥⁴桥桡牡捴敲猠楮ਾ‾瑴瀺⼯橡楫楰敤楡牧⽷楫椯メインページ‿⤊㸠ਾ⁙敳Ⱐ扵琠䤧洠潮⁌楮畸潷⸠㨩ਊ䤠捡湮潴Ⱐ潮⁆牥敂卄⸊琧猠灲潢慢汹散慵獥⁉楤渧琠杯畴映浹⁷慹⁴漠楮獴慬氠景湴猠景爊瑨慴⁷物瑩湧祳瑥洠⡷桡琠楳琬⁋慮橩㼠潭整桩湧⁉慮❴敡搊慮票潷⤬畴瑩汬Ⱐ楴潯歳楫攠獩砠楤敮瑩捡氠敭灴礠牥捴慮杬畬慲潸敳敲攮ਊ䅮搠敶敮映楴潯步搠汩步⁊慰慮敳攠睲楴楮本⁴桡琠睯畬摮❴攊獩杮楦楣慮瑬礠扥瑴敲⸠⁉慶敮❴瑵摩敤⁊慰慮敳攠睲楴楮本漠楴ੰ牥瑴礠浵捨汬潯歳⁴桥慭攠瑯攮†䥮摥敤Ⱐ楮潮瑥硴楫攠瑨攊啒䰠扡爬⁷楴栠愠ç
��慬氠湵浢敲映捨慲慣瑥牳Ⱐ䤧洠湯琠捯湦楤敮琠䤠捯畬搊摩獴楮杵楳栠䩡灡湥獥⁷物瑩湧牯洠䍨楮敳攠睲楴楮朮†⡇楶敮畬氠灡来੯映瑥硴⁉潵汤Ⱐ獩湣攠䤠歮潷⁃桩湥獥猠楤敯杲慰桩挠扵琠䩡灡湥獥⁵獥猊愠獹汬慢慲礬漠瑨敲攠睯畬搠扥楧楦晥牥湣攠楮⁴桥⁶慲楥瑹昊捨慲慣瑥牳⸠⁂畴⁷楴栠潮汹楸桡牡捴敲猠瑯⁷潲欠晲潭楫攠慢潶攬癥渠楦礠捯浰畴敲楳灬慹敤⁴桥洬⁉潮❴⁴桩湫⁉潵汤⁴敬氠睨楣栊歩湤⁴桥礠睥牥㬠䤠潮汹略獳敤琠睡猠䩡灡湥獥渠瑨楳慳攠扥捡畳攊坩歩灥摩愠畳敳慮杵慧攭楮摩捡瑩湧潭慩渠灲敦楸⸩ਊ䕶敮⁷物瑩湧祳瑥浳⁴桡琠䤠⩣慮⨠牥慤 䱡瑩渠慬灨慢整⁷楴栠獯浥楡捲楴楣猬⁇牥敫汰桡扥琠睩瑨楡捲楴楣猬⁈敢牥眠慢橡搠睩瑨⁎楱煵搊癯睥氠ç
��楮瑳Ⱐ浯獴映瑨攠䍹物汬楣汰桡扥琬湤敷桡牡捴敲猠晲潭ੴ桥⁄敶慮慧慲椠慢畧楤愩Ⱐ䤠摯渧琠灡牴楣畬慲汹⁷慮琠瑯敥⁴桥洠楮⁴桥剌慲Ⱐ扵琠䤠慤浩琠瑨慴❳潳瑬礠景爠牥慳潮猠潦浢楧畩瑹⸊ਭⴠਊ瘳獷㕐桷㕬渵灲㕏⽆⽐⽣欲浡㡵㝌⽆眳洵氶⼷椶收琰户⼸敮㑧㌯㕔愳塲㕰㌠桡捫敲步礮捯洊
Jonadab, for some reason your message was sent with UTF-16be headers but UTF-8
or Latin1 content. The above is how that strange combination makes it look --
mostly Chinese to me. Let me quote it again below (which I can only do by
pasting after having changed the encoding):
> Rimas Kudelis <r...@i.hate.spammers.very.much.---.akl.lt> writes:
>
>>> > > (just out of curiosity, can you see the characters in
>>> > > http://ja.wikipedia.org/wiki/��0�0�0�0�0�0� ?)
that should have been http://ja.wikipedia.org/wiki/メインページ
>> >
>> > Yes, but I'm on Linux now. :)
>
> I cannot, on FreeBSD.
>
> It's probably because I didn't go out of my way to install fonts for
> that writing system (what is it, Kanji? something I can't read
> anyhow), but still, it looks like six identical empty rectanglular
> boxes here.
>
> And even if it looked like Japanese writing, that wouldn't be
> significantly better. I haven't studied Japanese writing, so it
> pretty much all looks the same to me. Indeed, in a context like the
> URL bar, with a small number of characters, I'm not confident I could
> distinguish Japanese writing from Chinese writing. (Given a full page
> of text I could, since I know Chinese is ideographic but Japanese uses
> a syllabary, so there would be a big difference in the variety of
> characters. But with only six characters to work from like above,
> even if my computer displayed them, I don't think I could tell which
> kind they were; I only guessed it was Japanese in this case because
> Wikipedia uses a language-indicating domain prefix.)
Japanese uses Chinese characters (called hanzi in Chinese, kanji in Japanese)
as well as two syllabaries (covering the same set of sounds with different
symbols, one used for foreign names (katakana) and the other for Japanese
"empty words" such as flexions, and for transliteration of difficult kanji
(hiragana). The hiragana are very different from the kanji, as they have a
much higher proportion of "rounded" line shapes. The six characters above are
all (IIUC) katakana (i.e., members of the other, more straight-lined, syllabary).
>
> Even writing systems that I *can* read (Latin alphabet with some
> diacritics, Greek alphabet with diacritics, Hebrew abjad with Niqqud
> vowel points, most of the Cyrillic alphabet, and a few characters from
> the Devanagari abugida), I don't particularly want to see them in the
> URL bar, but I admit that's mostly for reasons of ambiguity.
The current display (ASCII with percent-escapes) seems OK to me. Maybe an
additional menu item "Copy URL as UTF-8", which would resolve the
percent-escapes, could be added. And/Or a button to toggle "ASCII display" vs.
"Unicode display" of the Location Bar. But I'm not sure.
>
> -- v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
Best regards,
Tony.
--
Leibowitz's Rule:
When hammering a nail, you will never hit your finger if you
hold the hammer with both hands.
Heikki Toivonen
> Heikki Toivonen wrote:
>> Gervase Markham wrote:
>>> 1) Hide the scheme when URL bar not focussed/hovered.
>>
>> I still don't like this.
>
> Have you played with the latest Locationbar2?
I just installed it to try it out. I do like the highlighted colors, but
the changing content on hover/focus annoys the heck out of me.
I realized that I actually look at the scheme rather than the lock icon
in determining if I am on an SSL-enabled page (on some sites I check for
both). But because it is now hidden, I find I start reading the URL,
stop, look to the right to see if there is a lock, then jump back to the
beginning to start reading the hostname. Very irritating.
>>> 6) Focus/hover turns bar back to a text box
>>
>> I just realized that changing the location bar from edit control to
>> anything else can present a challenge to accessibility API and software.
>> It would be good to involve Aaron Leventhal or other accessibility
>> people in this discussion.
>
> It's still an edit control as far as the XUL DOM is concerned.
I am not so sure that is what screenreaders etc. use.
--
Heikki Toivonen
Gervase Markham
> I realized that I actually look at the scheme rather than the lock icon
> in determining if I am on an SSL-enabled page (on some sites I check for
> both). But because it is now hidden, I find I start reading the URL,
> stop, look to the right to see if there is a lock, then jump back to the
> beginning to start reading the hostname. Very irritating.
Yes, I can imagine. The lock is not ideally placed for a good "eye-flow"
in that sense. But hopefully we'll be looking at how that UI works as
part of the security UI review. Something to bear in mind.
Gerv
Jonadab the Unsightly One
> Jonadab, for some reason your message was sent with UTF-16be headers
> but UTF-8 or Latin1 content.
Very strange.
Ordinarily I don't post anything to usenet with more than 7 bits per
character, so it's entirely possible that Gnus is misconfigured with
regard to posting Unicode, and I might not have noticed until now.
OTOH, it is very unlikely that I ever took any deliberate action to
change the configuration of Gnus with regard to posting unicode, and I
certainly have no recollection of doing so.
Nonetheless, I do see the following header:
Content-Type: text/plain; charset=utf-16be
And yes, my post is totally illegible to me here, too.
That header is present in the copy that Gnus kept on my system when I
sent it, so it was already there then (i.e., was not added ex post
facto by e.g. a weird news server issue). So either the version of
Gnus that I have comes misconfigured out of the box (unlikely), or
something about my configuration has confused it (much more likely),
or something about the message I was replying to confused it (also
conceivable).
I don't know enough about Unicode to comment beyond that. Actually
what impresses me most about Unicode is the number of different
kinds of bugs it causes.
> Japanese uses Chinese characters (called hanzi in Chinese, kanji in
> Japanese) as well as two syllabaries (covering the same set of
> sounds with different symbols, one used for foreign names (katakana)
> and the other for Japanese "empty words" such as flexions, and for
> transliteration of difficult kanji (hiragana). The hiragana are very
> different from the kanji, as they have a much higher proportion of
> "rounded" line shapes. The six characters above are all (IIUC)
> katakana (i.e., members of the other, more straight-lined,
> syllabary).
Interesting. I didn't know all of that.
Japanese is not a language I have ever studied.
--
v3sw5Phw5ln5pr5O/F/P/ck2ma8u7L/Fw3m5l6/7i6e6t0b7/8en4g3/5Ta3Xr5p3 hackerkey.com
Philip Chee
> Japanese uses Chinese characters (called hanzi in Chinese, kanji in Japanese)
> as well as two syllabaries (covering the same set of sounds with different
> symbols, one used for foreign names (katakana) and the other for Japanese
> "empty words" such as flexions, and for transliteration of difficult kanji
> (hiragana). The hiragana are very different from the kanji, as they have a
> much higher proportion of "rounded" line shapes. The six characters above are
> all (IIUC) katakana (i.e., members of the other, more straight-lined, syllabary).
It's more complicated than that.
katakana is also used for emphasis, for example the way you would use
*bold* or /italics/ in English. For onomatopoeic words. And girls
sometimes write their names in katakana because they think it's kawaii,
er, I mean cute.
The kanji conveys semantic content, the kana only the pronunciation.
Sometimes in order to maintain a sense of ambiguity an author will spell
something out in kana so as not to reveal a plot element too early
(there are a lot of homophones in Japanese).
And sometimes the NHK stylebook mandates that certain words like subete
be written in hiragana and not kanji (I have no idea why, that's what my
Babelzilla translator told me when I asked him why he changed it).
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]I'm so broke I can't even pay attention
* TagZilla 0.059.4
Saurabh Minni
> [Sorry - 1.1 was not updated in several important places. Here's another
> attempt. No further big changes, just made the text consistent.]
>
> Some excellent arguments in the previous thread have changed my mind on
> certain issues. So I'm posting a revised proposal here. I thought a new
> thread rather than a continuation would be better, so it's clear which
> proposal people are addressing.
>
> The changes do, of course, raise some further questions. And none of
> them are set in stone - feel free to try and persuade me back again if
> you think they aren't improvements :-)
>
> Big changes:
>
> A) Clicking the hostname no longer takes you to the root of the site. I
> agree, this should remain an in-page navigation option. Lots of sites
> provide it already, so it's not all that useful. This means that
> clicking it allows editing, just as with the rest of the URL, which is
> consistent. Also, removing it allows us to do:
>
> B) URL bar changes to a text box on hover as well as on focus. (We
> couldn't do this before, as otherwise the hostname button would be
> unclickable.) This makes it much easier to click where you want to to
> select part of the URL, because you are clicking where the caret will
> actually end up, rather than clicking in one place, the form of the bar
> changing on focus, and the caret actually appearing in another place
> (albeit between the same, clicked letters).
>
> We could even make it so that the URL bar changes mode when the mouse
> was over any part of the chrome, not just the URL bar itself. That means
> that if you moved the mouse from the content towards the URL bar, it
> would have changed by the time you arrived, and you could aim at the
> right spot. The exact algorithm would require some careful tuning.
> Perhaps it could fade quickly between the two forms so as not to be too
> visually jarring.
>
> This means we can also say:
>
> C) It's not so important that things don't shift around when the URL bar
> changes modes - because the shift now happens on hover (even just
> getting close), rather than on focus, so you can move the mouse, see the
> shift, and then click where you want the caret to be and it'll stay there.
>
> This means that:
>
> D) We can show the scheme in the text version, without worrying about
> the jumping around. This removes some concerns people had about hiding
> the scheme totally. (It's still hidden in the non-text version.)
>
> Removing "click the hostname" also means that:
>
> E) We highlight Effective TLD + 1, not the entire hostname. There's no
> need to highlight the entire hostname because "it might be where people
> want to go when they click" - that rationale is removed. Sticking with
> Effective TLD + 1 removes the spoofing possibilities of highlighting all
> of microsoft.com.foo.bar.evil.com.
>
> F) I have changed to Ben and Rimas's suggestion of _prepending_ the EV
> information to the domain name. IE has it on the far right, but I think
> prepending it works well, because it's then in the position the domain
> name used to be, and yet the domain name is still visible (and
> highlighted). But I'd particularly like further discussion on this,
> because it raises its own issues.
>
> Location Bar Proposal 1.1
> -------------------------
>
> 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 when URL bar not focussed/hovered.
>
> 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.
>
> 2) Hide username and password
>
> If present. This is the "foo:bar" in http://foo:b...@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.
>
> 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 the Effective TLD + 1 and highlight it (in some way to be decided).
> So either:
>
> www. EXAMPLE.COM /foo/bar/baz?q=x
>
> 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.
>
> 4) Display EV business name and country
>
> 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
>
> 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 now have two things highlighted; we'd need to do UI experiments to
> see if that was confusing, and whether we should highlight them the same
> or different, or whether we should drop the highlighting of the domain
> name, or something else. The name and flag need to appear non-editable.
>
> 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 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.
>
> 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. We'd need to replace that function somehow. To be decided.
>
>
> important behaviours to do with URL bar hand-editing that we don't want
> to break. Therefore, clicking anywhere in the URL bar, or pressing
> Ctrl-L or equivalent, focusses the URL bar and makes the following changes.
>
> If the domain name is styled in such a way that it looks "uneditable",
> then the style changes to remove that impression. We should try and keep
> enough style to make sure the domain is still picked out, if possible.
> Any hidden information, such as the scheme, returns. The EV business
> name and country identifier remain (as they aren't editable, so there's
> no need to do anything to them). The URL bar acts as much like a single
> text box as possible. This will lead to things shifting about; we'd need
> to do tests to see if this was too jarring. I hope that the fact that it
> changes on hover means that it isn't.
>
> 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").
>
> For reference, the current behaviour is:
>
> With layout.word_select.stop_at_punctuation=false (default on Linux):
>
> Single-click places caret
> Double-click selects everything
> Triple-click also selects everything
>
> In other words, the selection never takes account of the different parts
> of the URL.
>
> With layout.word_select.stop_at_punctuation=true (default on Windows):
>
> Single-click places caret
> Double-click selects out to punctuation
> Triple-click selects everything
>
> URL bar selection behaviour has been discussed before in this bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=190615
> which requests that layout.word_select.stop_at_punctuation be set to
> true on all platforms.
>
> 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.
>
>
> without affecting others. This is not supposed to be a tightly-bound
> take-it-or-leave-it package.
>
> Gerv
Probably it will be great if the proposal is first implimented as an
extension for FF2.
100rabh
pile0nades
I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=372773 for
that.
Mardak
> 3) Highlight hostname
How about positioning the hostname in the same spot no matter what the
subdomain is? If the subdomain is too long, it'll be cutoff the left
edge just like a long path is cut off on the right edge. It'll still
be accessible when you click and move the cursor, but the default view
of an unfocused location bar will have the domain in the same spot
(left aligned?). This provides a consistent spot to look for the
domain and ensures it won't get shifted off by a long subdomain.
| eblogs.mozillazine.org
| foo.bar.evil.com
One way to differentiate the domain is to increase the letter-spacing.
The letter-spacing helps prevent double "v"s = "w". Adding extra left/
right margins in addition to increasing the font size would just
reinforce the importance of the domain. All domain names are
lowercase, but there could be benefits of text-transforming it to
uppercase - again to emphasize the domain name.
|weblogs. M O Z I L L A Z I N E . O R G /gerv/archives/2007/0
| groups. G O O G L E . C O M /group/mozilla.dev.apps.fi
| bugzilla. M O Z I L L A . O R G /show_bug.cgi?id=303183
Also, with the styling of increased spacing, I don't think it needs to
revert to "normal text" when the location bar is selected. If you're
typing in a domain, it'll immediately appear stylized as a domain
name. This would avoid the problem of text jumping when the whole url
is styled the same way on focus. The trouble here is how to determine
a domain name as it's being typed, as something that might have been a
domain name is actually the subdomain. e.g. "G R O U P S." ->
"groups. G O O". But then again, if you're typing in a url, you
typically aren't trying to click at the same time.
However, one downside to focusing on the domain name is that there are
some sites that use a trusted 3rd party to handle secure connections.
Users will see the domain name not of the site they're doing banking
with, and assume it's a fake site.
Ed
Gervase Markham
> How about positioning the hostname in the same spot no matter what the
> subdomain is? If the subdomain is too long, it'll be cutoff the left
> edge just like a long path is cut off on the right edge. It'll still
> be accessible when you click and move the cursor, but the default view
> of an unfocused location bar will have the domain in the same spot
> (left aligned?). This provides a consistent spot to look for the
> domain and ensures it won't get shifted off by a long subdomain.
>
> | eblogs.mozillazine.org
> | foo.bar.evil.com
Would this unduly penalise more verbose languages like German, whose
domain names might tend to be longer?
Also, hiding part of the subdomain might have the opposite effect to the
one intended, by concealing what needs to be made clear.
> One way to differentiate the domain is to increase the letter-spacing.
> The letter-spacing helps prevent double "v"s = "w".
Certainly an idea worth experimenting with. Of course, it doesn't work
for languages which have no letter spacing, like (I think) Thai and Arabic.
> Adding extra left/
> right margins in addition to increasing the font size would just
> reinforce the importance of the domain. All domain names are
> lowercase, but there could be benefits of text-transforming it to
> uppercase - again to emphasize the domain name.
Text-transforming to uppercase is bad. Lots of the anti-spoofing stuff
is based on normalisation to lowercase. Lowercase letters also tend to
be more distinct from each other, and around 10% easier to read, than
uppercase letters.
> Also, with the styling of increased spacing, I don't think it needs to
> revert to "normal text" when the location bar is selected.
There are currently technical issues with retaining any styling when the
location bar is selected. But yes, if we chose this idea, we could
certainly look at it.
> However, one downside to focusing on the domain name is that there are
> some sites that use a trusted 3rd party to handle secure connections.
> Users will see the domain name not of the site they're doing banking
> with, and assume it's a fake site.
One solution to that is for them to fix their DNS and have the third
party site use a subdomain of their domain. But this does present
problems because then you need a new certificate for each customer.
Something to think about.
Gerv
Tony Mechelynck
> Mardak wrote:
[...]
>> One way to differentiate the domain is to increase the letter-spacing.
>> The letter-spacing helps prevent double "v"s = "w".
>
> Certainly an idea worth experimenting with. Of course, it doesn't work
> for languages which have no letter spacing, like (I think) Thai and Arabic.
I don't know about Thai; any language using "combining characters" (roughly
speaking, characters which must be printed "superimposed" over the preceding
character) would require special handling. IIUC, this includes languages using
nagari script (i.e., several of the languages of the Indian subcontinent) and
some forms of Hebrew and Arabic; maybe others too.
Arabic does provide for increasing the space between letters, but there are
subtleties:
- Use U+0640 ARABIC TATWEEL between the letters making up a word in "normal"
cases (cases not mentioned below)
- Never separate a laam from a following alif
- Don't use tatweel after any of the letters alif, dal, dhal, reh, zay, waw
and their variants (such as alif with hamza above, hamza below, madda, or
wasla; waw with hamza), which are (except in one "very cursive" calligraphic
style) not joined to the letter following them in the same word
- Of course, never separate a combining character from the preceding "spacing"
character.
Syriac also uses the same tatweel for the same purpose, but I don't know its
"joining rules".
I don't think it would be worth programming these rules into the display
interface for the Location Bar; but the gurus might think otherwise.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
91. It's Saturday afternoon in the middle of may and you are on computer.
Mardak
average user doesn't look there. It might be because the UI doesn't
draw enough attention to that area. Users want to focus on doing their
task. Many phishing sites are very effective because they look and act
just like the real site.
** Assuming users know what the domain of the site they're using is
supposed to be.. **
There needs to be more active response to the user to show the domain
name. Highlighting it would be a good start, but that's located in the
periphery vision. Users follow links on sites to see if they work to
determine if the page is good or not.
One way to draw attention is to only style from time to time. For
example, when a user visits a domain that is different from the
current page, the location bar would style the domain differently. But
when they remain on the same site, nothing special will happen. This
would prevent a dulling effect of having something constantly
highlighted.
To take this one step further, we could show the domain to the user in
the content area that they're already looking at. (Users don't care
about the URL and don't focus on the location bar.)
This would work by showing the just the domain name in the content
area only when the page switches domains. It would only appear for a
moment, e.g. a second, and fade away. It's somewhat like an interrupt
to the user, but it doesn't require the user to dismiss a dialog. Even
if the user doesn't read the domain name in time, s/he gets a cue that
the domain has changed.
http://ed.agadak.net/firefox/locationbar/mozilla.png
http://ed.agadak.net/firefox/locationbar/google.png
http://ed.agadak.net/firefox/locationbar/mozillazine.png
This is especially useful for phishing sites that link to official
sites from the copied page to make it seem genuine. If a user clicks
those links and sees the domain constantly switching, e.g. between
mozilla.org and rnozilla.org (with letter spacing: r n o z i l l a . o
r g), s/he can determine something strange is happening.
This would also apply to embedded pages such as frames or iframes.
Phishing sites can embed links to the real page while leaving the
login box on the fake page. The user is tricked to think the content
is valid and enters the appropriate login information.
http://ed.agadak.net/firefox/locationbar/bugzilla.png
http://ed.agadak.net/firefox/locationbar/rnozilla.png
This 'flash-domain-in-content' would provide an active feedback in the
area users are looking at. And with its automatic dismissal (fading
away), users aren't annoyed compared to security prompts that require
user interaction.
An alternate design that isn't as intrusive would be to completely
hide the location bar by default. Only when the domain changes would
it temporarily appear and then disappear again. This movement draws
attention and lets the user know they've moved elsewhere. Of course,
keyboard shortcuts to focus the location bar or moving the cursor to
where the location bar should be would trigger it to show again. Or
instead of completely hiding the location bar, only have it show the
domain name.
** Average users typically don't know what the domain name is supposed
to be. For example, is mozilla.org the official site or
therealmozilla.org? Some users might notice the difference and still
think, oh, mozilla wasn't able to get mozilla.org, so they went with
therealmozilla.org. A site like a-partner-of-google.com might sound
fine for some people.
Tony Mechelynck
Please don't!
Are you really trying to scare all Firefox users away to IE, Safari or
Konqueror in order to avoid those irritating flashing domain names?
IMHO those pseudo-security measures would reduce Firefox to uselessness.
Best regards,
Tony.
--
The gods gave man fire and he invented fire engines. They gave him
love and he invented marriage.
Mardak
wrote:
> those pseudo-security measures would reduce Firefox to uselessness.
The domain would only show up when you switch domains and at the
beginning of the page load. I'm not sure how often you switch domains,
but the message would likely disappear before the page is even done
loading.
It won't be irritating if designed correctly so that it doesn't get in
the way of normal usage. For example, any user action could make it
disappear immediately if the remaining part of the second is too long.
I think regular users would even benefit from the additional
information in normal usage outside of phishing situations. It would
be useful to not only quickly see that you're on a different site but
also to see what the new site's domain is.
Some sites such as portals already spend a lot of effort to inform the
user that the user is leaving the current site. So there is a
precedence of a need to do something like this.
The reason for this active non-modal design is that the passive
notifications such as coloring the location bar or showing a locked
icon isn't effective for those that aren't looking in those areas.
With careful control of what goes into this "momentary prompt" that
appears where the user is currently looking, other additional useful
information can be added - almost subliminally. For example, the lock
icon can show up at a larger size. (Users feel safer on phishing sites
that show locks in the content of the page, but ignore locks that are
out of the way such as in the status bar.) Colored text/background
depending on the EV Certificates.
These ideas are sort of leading into the extensions domain. But the
question is if browser developers want to deliver a product with an
insufficiency the computer/human interface that causes problems for
average users.
Ed
Tony Mechelynck
I think it would be an almost unbearable pain on the nerves. Obviously, you
don't. Let's see what others have to say.
Best regards,
Tony.
--
A Plan for the Improvement of English Spelling
by Mark Twain
For example, in Year 1 that useless letter "c" would be dropped
to be replased either by "k" or "s", and likewise "x" would no longer
be part of the alphabet. The only kase in which "c" would be retained
would be the "ch" formation, which will be dealt with later. Year 2
might reform "w" spelling, so that "which" and "one" would take the
same konsonant, wile Year 3 might well abolish "y" replasing it with
"i" and Iear 4 might fiks the "g/j" anomali wonse and for all.
Jenerally, then, the improvement would kontinue iear bai iear
with Iear 5 doing awai with useless double konsonants, and Iears 6-12
or so modifaiing vowlz and the rimeining voist and unvoist konsonants.
Bai Iear 15 or sou, it wud fainali bi posibl tu meik ius ov thi
ridandant letez "c", "y" and "x" -- bai now jast a memori in the maindz
ov ould doderez -- tu riplais "ch", "sh", and "th" rispektivli.
Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud
hev a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld.
Greg Campbell
> I think it would be an almost unbearable pain on the nerves. Obviously,
> you don't. Let's see what others have to say.
Yes. A unbearable pain indeed.
The folks who won't be bothered to look at the location bar probably
will not bother to pay attention to a domain name flashed in their face.
Or they certainly would need longer than a second to understand the
information anyway.
As far as I see it, improvements to the location bar should be designed
for folks who *actually look at the location bar already* but are
occasionally confused or deceived by clever phishers.
For the folks who aren't willing to educate themselves to the level
where they can understand the location bar, the built-in safe browsing
features are about as good as it's going to get.
Greg
Saurabh Minni
for the phishers to fool the user with this model. Probably this is only
an extra effort which can be used by phisher more than any user.
100rabh
Mardak
> I dont think it gets on my nerves but I feel its not all that difficult
> for the phishers to fool the user with this model. Probably this is only
> an extra effort which can be used by phisher more than any user.
The thing is even if phishers copy the design of the banner that
appears, the purpose of the banner is to inform the user that the
domain *is* different. The content of the banner could be a smiley
face. As long as the user is sort-of interrupted by the fact something
appeared, their flow is stopped and they can take a look to see what's
amiss.
I've implemented a small demo that shows what the banner might look
like when you click on a link to a new domain.
http://ed.agadak.net/firefox/locationbar/domain.html
This demo shows when the banner is shown and when it disappears. Right
now I have it shown when you click a link and fades away in 1.5
seconds or if the target page finishes loading. It's possible for the
banner to fade away even before the target page begins loading.
Some artifacts of my simple demo that shouldn't be the target of
discussion: the links at the bottom are just to trigger a page load in
the iframe and wouldn't really be there; the fading might be jumpy but
that's just how I naively implemented fading; domains only show up
when clicking the provided links but the lack of domain appearing on
same-domain links is consistent of what actually should be done.
Ed
Anatolij Kupriyanov
> 3) Highlight hostname
>
> Take the Effective TLD + 1 and highlight it (in some way to be decided).
> So either:
>
> www. EXAMPLE.COM /foo/bar/baz?q=x
There are many addresses which have meaningful name in the third component. E.g. example.co.uk, example.gov.uk,
example.org.ru and so on. It will be awful if domains would look like
hmrc. CO.UK /foo/bar
How do you expect to recognise all these cases?
JP. Baker
Anatolij Kupriyanov <kan...@gmail.com> wrote:
>I did not read whole the discussion, but I don't remember if somebody mentioned it.
>Effective TLD is not so trivial thing.
>There are many addresses which have meaningful name in the third component. E.g.
>example.co.uk, example.gov.uk,
>example.org.ru and so on. It will be awful if domains would look like
>hmrc. CO.UK /foo/bar
>How do you expect to recognise all these cases?
For Firefox 3 there is a service that does the work based on (a large number of)
rules.
http://wiki.mozilla.org/Gecko:Effective_TLD_Service
there is also a bug to provide a helper for TLD+1
https://bugzilla.mozilla.org/show_bug.cgi?id=367446
john
--
John P Baker
Gervase Markham
> One way to draw attention is to only style from time to time. For
> example, when a user visits a domain that is different from the
> current page, the location bar would style the domain differently. But
> when they remain on the same site, nothing special will happen. This
> would prevent a dulling effect of having something constantly
> highlighted.
That's a nice idea. But you'd have to be careful how you implemented it.
For example, when do you remove the highlighting? If it's just on the
next page load, the attacker might send you through a redirect or an
immediate reload to get rid of the telltale highlighting as soon as
possible.
> This would work by showing the just the domain name in the content
> area only when the page switches domains. It would only appear for a
> moment, e.g. a second, and fade away. It's somewhat like an interrupt
> to the user, but it doesn't require the user to dismiss a dialog. Even
> if the user doesn't read the domain name in time, s/he gets a cue that
> the domain has changed.
Another interesting idea. I like the way you think :-) I wonder, though,
if this would be intrusive. Also, the problem with anything in the
content area is that it can be faked by a web page. Exactly the same
effect, but with an invalid domain name (e.g. paypal.com) could be
constructed by the attacker, to fire after the first one went away.
> This would also apply to embedded pages such as frames or iframes.
So if I had a page with ten different sites, each in an iframe, how
would we show that? Remember, iframes can be quite small.
> Phishing sites can embed links to the real page while leaving the
> login box on the fake page. The user is tricked to think the content
> is valid and enters the appropriate login information.
>
> http://ed.agadak.net/firefox/locationbar/bugzilla.png
> http://ed.agadak.net/firefox/locationbar/rnozilla.png
Well, unless you can lay the login box over the top, this sort of thing
doesn't look very convincing. And also, it doesn't really matter whether
the supposed-to-look-real content is hosted by the real site or the
phisher; the point is that the outermost page belongs to the phisher,
and that's where the risk is.
> An alternate design that isn't as intrusive would be to completely
> hide the location bar by default. Only when the domain changes would
> it temporarily appear and then disappear again. This movement draws
> attention and lets the user know they've moved elsewhere. Of course,
> keyboard shortcuts to focus the location bar or moving the cursor to
> where the location bar should be would trigger it to show again. Or
> instead of completely hiding the location bar, only have it show the
> domain name.
I'm not sure that would be an improvement. It's removing an indicator
people think is important. I know I don't check where I am until I'm
about to enter my credit card number; and I could have been on the site
for half an hour by then.
Gerv
Gervase Markham
> It won't be irritating if designed correctly so that it doesn't get in
> the way of normal usage. For example, any user action could make it
> disappear immediately if the remaining part of the second is too long.
Another point is that the user often isn't looking at the page when it's
loading. For example, if you open something in a background tab. Or,
more to the point, if you click a link in your email program, by the
time you've switched to the browser, the indicator will have gone.
> These ideas are sort of leading into the extensions domain.
They are. Why not write one to test the idea out? :-)
Gerv
Gervase Markham
> How do you expect to recognise all these cases?
Because the browser now has an enormous list.
http://wiki.mozilla.org/Gecko:Effective_TLD_Service
Gerv
Saurabh Minni
100rabh
Heikki Toivonen
> I've implemented a small demo that shows what the banner might look
> like when you click on a link to a new domain.
>
> http://ed.agadak.net/firefox/locationbar/domain.html
I kind of like this. I think it could be tweaked a little to highlight
the location bar more if, when fading it would move up to the location
bar and flash it.
--
Heikki Toivonen
Heikki Toivonen
> Another interesting idea. I like the way you think :-) I wonder, though,
> if this would be intrusive. Also, the problem with anything in the
> content area is that it can be faked by a web page. Exactly the same
> effect, but with an invalid domain name (e.g. paypal.com) could be
> constructed by the attacker, to fire after the first one went away.
FF could do it in a way that can not be faked by a page, as long as the
location bar is visible: the domain area banner could move to the
location bar and flash it.
But like you said, won't help if the user is not watching the page load
as in tabs etc.
--
Heikki Toivonen
Mardak
> I kind of like this. I think it could be tweaked a little to highlight
> the location bar more if, when fading it would move up to the location
> bar and flash it.
Or alternatively, because only the browser can really know where the
domain text is located in the location bar, there there could be a
similar banner background behind the domain name when you switch to a
new domain with guiding lines to the bigger in-page domain banner.
fixed width ascii art:
subdomain. ( domain ) /path/to/other/stuff
/ \
/ \
/ \
/ \
/ \
( | _ _ . _ )
( O| O | | | O| | | | )
Tricky part is keeping it low key enough to not be annoying. This
could possibly be done with the new SVG support, but I'm not familiar
with that area.
About loading pages from other programs or in background tabs.. The
domain could just show up when you actually switch to the tab or focus
on the browser window (if opening from another app). Alternatively,
tabs in background can have a similar guide-line-to-domain-banner
coming from the background tab.
Slight updates to demo:
- banner fades faster instead of immediately disappearing on page load
- new "location bar" with simple domain guessing
- banner only appears when you change domains (from actions outside of
the iframe)
http://ed.agadak.net/firefox/locationbar/domain.html
1. load the link
2. click on Mozilla Home (bottom); see the banner
3. type in "firefox" in the input to get "www.mozilla.com/firefox" and
press enter; don't see banner
4. click on Mozilla Home again; don't see banner
Ed
Saurabh Minni
> fixed width ascii art:
>
> subdomain. ( domain ) /path/to/other/stuff
> / \
> / \
> / \
> / \
> / \
> ( | _ _ . _ )
> ( O| O | | | O| | | | )
>
>
> Tricky part is keeping it low key enough to not be annoying. This
> could possibly be done with the new SVG support, but I'm not familiar
> with that area.
>
>
I think this is an idea which surely refines the previous setup. I think
it will be a good thing to do. Probably some expert in the new SVG
Support can tell if this is really possible or not.
Remember
100rabh
Nelson B
> One problem with focusing changes to the location bar is that the
> average user doesn't look there.
And even the ones that do look there may not see it,
because FF lets the phishers turn off the location/address bar!
I consider that to be the biggest phisher-friendly feature in FF.
You can fix it, though, and some other phisher-friendly problems,
by setting these prefs to TRUE in about:config
dom.disable_window_open_feature.location
dom.disable_window_open_feature.titlebar
dom.disable_window_open_feature.toolbar
dom.disable_window_status_change
? It might be because the UI doesn't
> draw enough attention to that area. Users want to focus on doing their
> task. Many phishing sites are very effective because they look and act
> just like the real site.
Right. Users who decided whether they're on the intended/legitimate
site, or not, based solely on the site's CONTENT will always be
vulnerable to phishing.
I've seen http sites that put lock icons in the page content, and I know
users who completely believe that the page is "secure" because of that.
As long as they believe that, they are vulnerable.
> ** Assuming users know what the domain of the site they're using is
> supposed to be.. **
That's always the big most-fundamental issue. You can't help assure the
user that he's at the right site if he has no idea what the right site is!
> There needs to be more active response to the user to show the domain
> name.
Simply having it always be visible would be a good start. :)
? Highlighting it would be a good start, but that's located in the
> periphery vision. Users follow links on sites to see if they work to
> determine if the page is good or not.
OY! Another form of judging a site's authenticity by its content!
> To take this one step further, we could show the domain to the user in
> the content area that they're already looking at. (Users don't care
> about the URL and don't focus on the location bar.)
IMO, it's really wrong to further reinforce the idea that authenticity
can be judged by ANY ASPECT of site contents.
> This would work by showing the just the domain name in the content
> area only when the page switches domains. It would only appear for a
> moment, e.g. a second, and fade away.
Sites could simulate it, spoof it.
> This 'flash-domain-in-content' would provide an active feedback in the
> area users are looking at.
The <BLINK> tag lives! :-/
> An alternate design that isn't as intrusive would be to completely
> hide the location bar by default.
OMG!
> ** Average users typically don't know what the domain name is supposed
> to be. For example, is mozilla.org the official site or
> therealmozilla.org? Some users might notice the difference and still
> think, oh, mozilla wasn't able to get mozilla.org, so they went with
> therealmozilla.org. A site like a-partner-of-google.com might sound
> fine for some people.
I think phishing will never be solved while that remains true.
Which is why I think phishing will never be solved.
--
Nelson B
Nelson B
> I've implemented a small demo that shows what the banner might look
> like when you click on a link to a new domain.
>
> http://ed.agadak.net/firefox/locationbar/domain.html
That fact that you can do it means any web site can do it.
So, a phisher could take you from one page to another to his web site at
www.phishers.r.us but flash up a big "www.bankofamerica.com", and users
who judge based on content would be fooled.
Repeat after me: authenticity CANNOT be judged from site content!!
--
Nelson B