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
Tony Mechelynck
Nelson, I agree with all you're saying. If someone really wants to flash the
new domain name on site changes, it should be in the chrome area, either in
the Location Bar itself or at some not-yet-overcrowded location such as the
menubar, statusbar, or both. However, Mardak says that won't work because
that's not where the user is looking. Maybe an area suddenly appearing with
red background and blinking text in big fat white letters, and not
disappearing until the next link is clicked (though maybe the blink might stop
after three times or so), would _draw_ the user's gaze to itself; otherwise
(and like you) I'd say drop it.
Another (partial) solution, though not perfect since it's based on content,
would be to convince "sensitive" sites to have several possible "skins",
user-settable but with the default being determined at random on first signon
for a given user: thus site spoofers wouldn't know which skin to spoof.
However it would not completely avert the risk (the phisher might try
imitating one skin at random and still hit on average one Nth of the time),
and it relies on evangelism not programming.
Best regards,
Tony.
--
Now I lay me down to sleep
I pray the double lock will keep;
May no brick through the window break,
And, no one rob me till I awake.
Mardak
> > 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. :)
The problem with having it always visible leads to habituation, so
people ignore it.
> > An alternate design that isn't as intrusive would be to completely
> > hide the location bar by default.
> OMG!
The full idea of hiding the location bar is so that it appears on a
domain change. This motion of having it appear tends to make it more
noticable.
> > To take this one step further, we could show the domain to the user in
> > the content area that they're already looking at.
> IMO, it's really wrong to further reinforce the idea that authenticity
> can be judged by ANY ASPECT of site contents.
The reason for displaying it in the content area is because the user
is most likely looking at that top 1/3 of the screen already.
> > This would work by showing the just the domain name in the content
> > area only when the page switches domains.
> Sites could simulate it, spoof it.
The updated idea (that I can't implement in my simple demo) is that
lines will connect the location bar's domain text with the domain
banner. This would be impossible to spoof... except for hiding the
navigation bar and displaying an image.
> > This 'flash-domain-in-content' would provide an active feedback in the
> > area users are looking at.
> The <BLINK> tag lives! :-/
Did you try out the demo?
http://ed.agadak.net/firefox/locationbar/domain.html
Multiple people have mentioned not even realizing there was a banner.
There were suggestions to make it last even longer. One interesting
comment was that the banner is shaped like existing banner ads that
people so naturally ignore already.
It's nowhere close to <BLINK> because it fades away quickly and stays
away.
> > ** Average users typically don't know what the domain name is supposed
> > to be.
> I think phishing will never be solved while that remains true.
> Which is why I think phishing will never be solved.
Even if it's never solved, there's still big improvements that can be
done right now. Only when the incremental benefits of implementing a
better anti-phishing are less than the productivity/money lost through
the poor interface would it then be time to think about other things
to improve.
--
Ed
Saurabh Minni
Mardak
http://ed.agadak.net/firefox/locationbar/lines.png
http://ed.agadak.net/firefox/locationbar/lines.2.png
On Mar 10, 12:32 pm, Saurabh Minni <the100r...@gmail.com> wrote:
> 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.
Well, after unsuccessfully trying to find people in #svg...
Mardeg of #firefox came up with an even better idea. The svg banner
consisting of the lines and banner could move towards the location bar
as another way to elicit "oh, this is where that big text came from."
But even better is, we might not even need SVG, although that might
increase performance. A more subtle effect is that lines might not
even be needed either because as the banner shrinks and moves towards
the location bar, it forms its own implicit lines.
--
Ed
Jesper Kristensen
> I made a couple [ugly :p] prototypes of the lines..
>
> http://ed.agadak.net/firefox/locationbar/lines.png
> http://ed.agadak.net/firefox/locationbar/lines.2.png
Websites will be able to spoof the lines. They may not be able to spoof the
lines all the way to the location bar, but who will notice the last couple of
millimeters?
This banner is more annoying than it is useful.
Talking about phishing and security: All dom.disable* should default to true
to reduce annoyance and security risk.
Gervase Markham
> 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.
Firefox 2 prevents removal of the status bar, which has domain
information for secure sites. It would certainly be possible - and, if
we make the location bar the canonical place for the relevant
information, wise - to switch it over so the status bar can be removed
but the location bar cannot.
>> ** 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.
Indeed. There will always be phishing; you can't eliminate any other
sort of fraud either. But you can reduce it, and give people the tools
and training they need to avoid it. Of course, the more effort it is to
avoid, the less avoidance will be done. So you need to balance minimal
effort with maximal effectiveness. The UI designer's dilemma.
Gerv
Dao
> Multiple people have mentioned not even realizing there was a banner.
> There were suggestions to make it last even longer. One interesting
> comment was that the banner is shaped like existing banner ads that
> people so naturally ignore already.
>
> It's nowhere close to <BLINK> because it fades away quickly and stays
> away.
And it's even less accessible.
Saurabh Minni
> Mardak skrev:
>> I made a couple [ugly :p] prototypes of the lines..
>>
>> http://ed.agadak.net/firefox/locationbar/lines.png
>> http://ed.agadak.net/firefox/locationbar/lines.2.png
>
> Websites will be able to spoof the lines. They may not be able to
> spoof the lines all the way to the location bar, but who will notice
> the last couple of millimeters?
>
more than anything else.
> This banner is more annoying than it is useful.
>
> Talking about phishing and security: All dom.disable* should default
> to true to reduce annoyance and security risk.
ca we talk of this being an optional feature. If u really find it
annoying. I actually find it eyecatching.
Remember
100rabh
David Regev
without the usability issues. If any of this has already been
suggested, please forgive the repetition. A LOT has already been said
about the subject, and it's hard to follow it all.
To recap, the problem with the button idea is that it decreases the
current usability of the location bar for the purposes of editing or
selecting part of the URL. Specifically, there are three issues: (1)
Clicking on a piece of text can either select it or activate it.
Buttons and text seem mutually exclusive. (2) If one tries to select
text that was previously displayed in button form, the text jumps
around from its previous location. This is a big usability no-no, as
it disrupts one's attention and steals focus from the task at hand to
figuring out where the a certain string of text went. (3) Buttons
would make selecting a piece of the URL simply by clicking on it
impossible.
To solve (1), let me point out that clicking and selecting are
different gestures that do not overlap. If I click on a button, I have
not moved my pointer, whereas, if I select part of the URL, I have.
The two gestures do not conflict, and I should be able to do both with
equal ease. Buttons and text are not, in fact, mutually exclusive. The
way Locationbar² currently works, the "buttons" appear as links. If
they were, in fact links, the issue would remain. Links can be
dragged, and the dragging gesture is identical to the selection
gesture. Thus, one cannot have draggable links that can be selected.
However, since the location bar buttons would not actually be
draggable, they should still be both selectable and clickable.
The obvious solution for (2) is to ensure that the text does not jump
around. The only way to do this while keeping buttons around is to
maintain the same formatting when the location bar is focused. Thus,
anything that is typed would have to be formatted on the fly,
including spacing, weight, colour, etc. This would only apply to
strings that begin with the protocol scheme. Thus, modifying a URL
would keep it formatted, since it begins with, e.g., 'http://', but,
entering 'www' or 'google' into a clean location bar would not trigger
the formatting. Also, although the formatting of the text would not
depend on the location bar's focus, the "button look" would. As soon
as the location bar is focused, the special "button" formatting would
fade away, the text would no longer be clickable as buttons, and all
that would remain is the regular formatting that separates the various
parts of the URL.
I would like to add that the favicon should definitely be replaced by
a different informative icon, which would replace the protocol scheme
in the URL when not being edited. Currently, one can middle-click
paste the favicon and automatically go to the pasted URL. This
functionality should not be removed and should remain with whatever
replaces the favicon.
Issue (3) does not have a perfect solution. However, I do have what I
hope would be a tolerable solution. Since the URL is always formatted,
there would always be some gap between each element in the URL, right
after the '/'. I propose that clicking on that gap automatically
select the following element. Moreover, clicking anywhere beyond the
full URL would select it in its entirety, identical to the current
behaviour.
Sorry for the long post. I think having buttons would be extremely
useful, and I hope that my ideas can help make that happen. Again,
please forgive the repetition if any of this has been said before.
Thank you.
Tony Mechelynck
The current behaviour, at least in "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.8.1.4pre) Gecko/20070408 BonEcho/2.0.0.4pre", is that if you click once
to the right of the URL text, you get an insertion point at the end of an
UNselected URL. Click twice in quick succession and _then_ the URL is selected.
>
> Sorry for the long post. I think having buttons would be extremely
> useful, and I hope that my ideas can help make that happen. Again,
> please forgive the repetition if any of this has been said before.
>
> Thank you.
>
I don't like the idea of "space that isn't there" in the middle of selectable
URL bar text. If you want buttons when the URL bar doesn't have focus, have
them appear as buttons, with borders, round corners, drop shadows and
what-not; not as text. Then Ctrl-L or maybe some new "Edit Location Bar"
button would *replace* those buttons by an input bar, which would have the URL
as one piece of plaintext, with no bogus blanks, and be editable. Then the
Enter key or the Go button would activate the edited URL just like now. I
don't care if the text jumps about when the buttons become an input bar or
vice-versa: after all, it's one kind of widget being replaced by a different kind.
Best regards,
Tony.
--
Philogyny recapitulates erogeny; erogeny recapitulates philogyny.
Gervase Markham
> To solve (1), let me point out that clicking and selecting are
> different gestures that do not overlap. If I click on a button, I have
> not moved my pointer, whereas, if I select part of the URL, I have.
> The two gestures do not conflict, and I should be able to do both with
> equal ease.
The problem with this suggestion, which seems logical, is that many
people (including me) click in the URL bar to focus it before then doing
a drag-select. Educating me and them out of this behaviour would be very
hard.
> Sorry for the long post. I think having buttons would be extremely
> useful,
You need to expand on this. I don't actually think they'd be much use at
all. Page authors need to provide navigation in-page - that's what the
page is for. Providing compulsory navigation just makes their lives more
complicated, because they have to make sure it all goes somewhere.
Gerv
Ka-Ping Yee
There appear to still be many open issues on the wiki page at
http://wiki.mozilla.org/Firefox3/Location_Bar .
I generally think this discussion has been headed toward too
much change and complexity in the UI. (Removing the favicons
is a notable exception in favour of simplicity, and I like it.)
I suspect that, as designers and programmers, it's easy to
underestimate the degree to which users develop habits and
find change difficult.
I'm against having two very different-looking modes for the
location bar. The location bar can look slightly different
when it is being edited and when it isn't, but the bigger the
difference, the more confusing and startling the switch will be.
Ideally the change would be subtle enough not to really look
like a "mode switch" at all.
Let's start with something simple and go from there:
1. When not focused, the TLD+1 stays black and the rest
of the URL is grey. Otherwise the location bar looks just
like it does now.
2. When focused, the location bar looks and works just
like it does now.
3. No favicon in the location bar, as Gerv proposed.
That's it. The benefits to the user are clear and the costs to
the user are minimal for these changes, I think. No problems
with things appearing and disappearing, things moving
around, timing of mouse movements, accessibility and
screen-readers, etc. Focus and text styling are simple and
well understood concepts by browser developers, extension
writers, third-party developers, and users alike.
We can separately debate hiding the scheme, username,
and password. For what it's worth, I'm against these changes
as well. Hiding the scheme doesn't win us anything, and
just makes it more difficult for users to distinguish between
URLs that really are different. Hiding the username and
password doesn't win anything either (it's not like someone
is going to put a password in the URL, then be surprised
that it appears in a screenshot of their browser). The primary
motive for hiding the username and password -- domain name
spoofing -- is already addressed.
It is important to preserve a clear relationship among:
- links in the page
- what appears in the status bar on link hover
- what is typed into the location bar
- what appears in the location bar
- which page the browser fetches
Hiding or rearranging the URL only serves to confuse these
fundamental relationships.
-- ?!ng
Gervase Markham
> I see a lot of proposals here, but is there a consensus?
Quite possibly not. That's the purpose of the UI review stage. We've
brainstormed, thrown a lot of ideas around, and reduced them to a set of
what I, at least, think are good ones. That doesn't mean we want them
all, or that other ideas are out.
> I'm against having two very different-looking modes for the
> location bar. The location bar can look slightly different
> when it is being edited and when it isn't, but the bigger the
> difference, the more confusing and startling the switch will be.
> Ideally the change would be subtle enough not to really look
> like a "mode switch" at all.
I agree; the more we can make them look like each other, the better.
> Let's start with something simple and go from there:
>
> 1. When not focused, the TLD+1 stays black and the rest
> of the URL is grey. Otherwise the location bar looks just
> like it does now.
>
> 2. When focused, the location bar looks and works just
> like it does now.
>
> 3. No favicon in the location bar, as Gerv proposed.
>
> That's it. The benefits to the user are clear and the costs to
> the user are minimal for these changes, I think.
Is there really a benefit if the visibility difference between TLD+1
(which we can both agree to use as a shorthand; we know what we mean :-)
and the rest of the URL is merely a matter of black vs. grey?
We can't make the grey too light, otherwise people can't read it. But we
can't make it too dark or there's too little difference.
> We can separately debate hiding the scheme, username,
> and password. For what it's worth, I'm against these changes
> as well.
Usernames and passwords are already hidden, actually.
Gerv
Ka-Ping Yee
> > Ideally the change would be subtle enough not to really look
> > like a "mode switch" at all.
>
> I agree; the more we can make them look like each other, the better.
Okay, great.
> > That's it. The benefits to the user are clear and the costs to
> > the user are minimal for these changes, I think.
>
> Is there really a benefit if the visibility difference between TLD+1
> (which we can both agree to use as a shorthand; we know what we mean :-)
> and the rest of the URL is merely a matter of black vs. grey?
I believe so. In the mockup at http://zesty.ca/mozilla/locbar.html
the
eTLD+1 stands out pretty well. (I used 33% grey.) What do you think?
> We can't make the grey too light, otherwise people can't read it. But we
> can't make it too dark or there's too little difference.
I agree that the URL has to still be visible, but it doesn't have to
be super
readable. It's sufficient if it can be seen well enough to position
the
cursor for editing. Most of the time, when looking at page content,
it isn't
necessary to read the URL anyway; the only part that users really need
to see easily is the eTLD+1, and if they want to examine the rest they
can look a little more closely or click on it.
The intended effect is that on a quick glance all you see is the eTLD
+1,
but if you focus your attention you can still read the rest. At the
level of
grey in the mockup, reading the rest is slower because of the reduced
contrast, but still quite feasible, I think.
> Usernames and passwords are already hidden, actually.
Oops. I guess that shows you how often I use that feature. :)
-- ?!ng
Sailfish
<snip/>
>
> 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.
>
One anti-phishing approach I've recently seen at some secure logon sites
(primarily financial institutions) is for the consumer to select some
small image when they register. Then, whenever they go to the legitimate
site in the future, they are displayed the image they selected at the
login screen. The thought being that a phishing site wouldn't be aware
nor have access to your specific image.
I'm not sure if this image technique is some type of industry standard
but if so and the browser could reliably access the image (via some XML
tag?) then maybe using it for the favicon (when present) might be helpful.
--
Sailfish - Netscape/Mozilla Champion
Netscape/Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
mozilla-based Themes: http://www.projectit.com/freestuff.html
Dão
>> Is there really a benefit if the visibility difference between TLD+1
>> (which we can both agree to use as a shorthand; we know what we mean :-)
>> and the rest of the URL is merely a matter of black vs. grey?
>
> I believe so. In the mockup at http://zesty.ca/mozilla/locbar.html
> the
> eTLD+1 stands out pretty well. (I used 33% grey.) What do you think?
Too faint. Don't even try to pick a gray tone; it won't work with
different OS themes. Currently (since opacity for text doesn't work
either), you have to use the native color named "graytext".
--Dao
Dão
> We can separately debate hiding the scheme, username,
> and password. For what it's worth, I'm against these changes
> as well.
It appears that you belong to a minority then. There were very few who
opposed the protocol hiding.
> Hiding the scheme doesn't win us anything, and
> just makes it more difficult for users to distinguish between
> URLs that really are different.
It allows us to emphasize the host without bolding it (which would cause
several already-discussed problems) and without making the rest of the
URL gray. It also reduces the risk that users confuse "https" with
"secure" or even "trustable".
--Dao
Jeff Walden
> One anti-phishing approach I've recently seen at some secure logon sites
> (primarily financial institutions) is for the consumer to select some
> small image when they register. Then, whenever they go to the legitimate
> site in the future, they are displayed the image they selected at the
> login screen. The thought being that a phishing site wouldn't be aware
> nor have access to your specific image.
There's a paper on this analyzing its use by Bank of America; the conclusion was that it wasn't helpful.
On the other hand, Bank of America's explanation of the *why* behind this idea was basically non-existent when I first had to deal with it. The idea seemed pointless to me for a few weeks, until I thought about it more and realized that it wasn't targeted at people like me who type the URL manually (not paranoia, just that typing "fleet.com" [bank name before BoA bought it] is faster for me than clicking a link in a notification email). I think there's a case to be made that the results reflect their user evangelism of the feature as much as or more than anything else. On the other hand, I'm not sure you could explain it and its benefits quickly enough for people to actually read/understand it.
Also, it's definitely not an industry standard yet, so it can't be incorporated in Firefox yet.
Jeff
Sailfish
little sense to pursue it. As an aside, my institution was Lockheed
Federal Credit Union whose url is lockheedfcu.org, lots of room for
typos where phishers may be trawling in that one.
fwiw, here's an excerpt from their FAQ explaining the new security measures:
What are the new security enhancements?
The new security enhancements add a layer of protection to your online
account by authenticating LFCU’s Online Banking site you know it’s
really us, and by allowing us to authenticate you and your computer so
we know it’s really you.
Authenticating LFCU so you know it’s really us – Personalized Image and Name
§ You pick one of thousands of images and then name that image to help
identify it to you
§ Every time you attempt to log into your LFCU account, the image and
name you chose will appear before you enter your password
§ Identifying your image and its name will let you know that you are at
LFCU’s legitimate Online Banking site and not a fake or fraudulent site.
This means it is safe to enter your password
§ If the correct image and name do not appear, DO NOT enter your password
Remember: Once you have signed up, NEVER enter sensitive information
such as your password without first seeing your personal security image
and text.
Authenticating you and your computer so we know it’s really you
§ You will be asked to set up three security questions for which only
you should know the answers
§ The security system will recognize the computers you normally use to
access Online Banking
§ If you or someone other than you attempts to sign in from a new or
unrecognized computer, your security question(s) will need to be
answered before being allowed to continue. This further ensures that
the person requesting access to your account is in fact you
Ka-Ping Yee
> > Hiding the scheme doesn't win us anything, and
> > just makes it more difficult for users to distinguish between
> > URLs that really are different.
>
> It allows us to emphasize the host without bolding it (which would
> cause several already-discussed problems) and without making
> the rest of the URL gray.
We still need to distinguish the eTLD+1 from the rest of the URL
somehow. Fading it out is by far the simplest way to do this, because
nothing moves at all. (Shading the background would be an equally
simple option.)
> It also reduces the risk that users confuse "https" with
> "secure" or even "trustable".
I don't think that's a fear we should address here. (Should we
hide ".com" for fear that users confuse it with "commercial"?
I think not.)
This feature should not be a vehicle for redefining what people
think URLs are. URLs are URLs; https is https; all these things
are well established conventions that we should follow. We are
not going to change the way URLs are entered into the location
bar, the way they appear in the status bar, or the way they are
entered in HREF attributes, and we are certainly not going to
change how they are printed in magazines, newspapers, and
business cards.
It all comes down to consistency.
Let's keep the feedback loop simple and keep the location bar's
mode-switch as minimal as possible.
-- ?!ng
John Bird
Favicons - If some sites try to put "spoof" lock icons there, that is enough
reason to remove it. Its naturally hard to otherwise check against that.
The favicon is sort of useful there, but can be omitted. It is MUCH more
useful in tabs and bookmarks, as there it's a fantastic way for the eye to
spot the desired icon in a large group quickly.
Protocol - in general don't care whether the https: or ftp: is there or not
- but if not there then something as informative should replace it. Whether
or not the https etc is shown, The favicon could be replaced by a protocol
icon. You need a few, just enough to cover the main types (http: https:
ftp: file: help: etc....). For secure sites, you need more than one, eg
a lock with say 3 green ticks on it if all aspects of https, certificate
validation etc are present. If not, the lock gets one or two red x's to
show not all is well instead of the green ticks. This icon could well be a
clickable or hoverable button - it can open a small window that shows more
information about the site security. I think the status bar or even the
right of the location bar is too far away for such an icon - it needs to be
right there at the start of the address, very prominent to give
unmistakeable visual info on the type of site one is at. It's an important
"trust" or reassurance icon, and I think will be becoming more and more
important the more e-commerce is doen through browsers.
Highlighting the top level domain - Black and grey fonts is OK but not
great. More ideal would be having the TLD domain name in bold. However
technically that probably makes using any standard programming components
impossible and adds a lot of complexity and issues for editing. Other
possibilities are having colour pairs - eg the address in black, the TLD in
Maroon or Navy. However the differences would not always be that obvious
for every character. I think the best would be to have the background of
the TLD slightly shaded, eg in light blue or light red. This has already
been done with https sites shaded in yellow, and this could still be
retained. A Bank site with the whole address shaded in yellow, and the TLD
shaded within that in a matching colour, eg blue or a slightly darker
yellow, would be visually about the easiest to spot I can think of.
How about a small indicator somewhere meaning "this page is already in your
bookmarks". I probably add some pages many times...as even when adding
bookmarks there is no way to see if a page is already there, so I just add
it again to be sure.
Location bar text font - as screens get higher resolution, the letters in
the location bar are getting smaller. I find quite a lot if I misspell a
site name, I end up at one of those irritating sites where a misspelled name
is an advertising site - eg wwww.yuotube.com. This happens a lot with the
letters "i" and "l" getting out of order, and it is very hard to spot
because they are so small before I press enter. So the font size and type
is important to avoid user errors. I think for my screen its too small...
John
David Regev
> The problem with this suggestion, which seems logical, is that many
> people (including me) click in the URL bar to focus it before then doing
> a drag-select. Educating me and them out of this behaviour would be very
> hard.
Really? I can select any bit of text in the bar immediately without
first focusing it, regardless how browser.urlbar.clickSelectsAll is
set. As I've explained, my proposal would not affect that. The only
difference is that one would have to click (or triple-click, depending
on clickSelectsAll) to the right of the URL to select it all, rather
than anywhere in the location bar.
> You need to expand on this. I don't actually think they'd be much use at
> all. Page authors need to provide navigation in-page - that's what the
> page is for. Providing compulsory navigation just makes their lives more
> complicated, because they have to make sure it all goes somewhere.
>
> Gerv
Well, shouldn't it all go somewhere anyway? Regardless, I find myself
editing the URL quite often. From the discussion surrounding this
proposal and the Locationbar² extension, this seems to be a fairly
common activity for those familiar with how URLs work. I admit that
this is probably a small percentage of the web-browsing population,
and, thus, I don't think the button aspect of the initial proposal is
the biggest must-have feature. However, I do think such a feature
would increase visibility and understanding of what "that text at the
top of the window" is. Moreover, if the buttons are fairly subtle,
such as in your mock-up at http://weblogs.mozillazine.org/gerv/archives/images/2007/urlbar1.png,
the feature will not get in the way for those who don't use it, but
will be quite helpful for those who do (or have discovered that they
do due to the existence of the feature).
Regarding the concern of adding too much complexity to the location
bar, I think that a proper implementation would actually appear pretty
simple to the user. Just as replacing the favicon and scheme with one,
more informative, icon would be a simplification, if the style of the
modified URL is subtle and looks coherent, the new location bar will
not be complex to the user but actually helpful. As it is, most users
mostly ignore the location bar, so this "complexity" would actually be
informative for them. Moreover, I've been thinking about how I most
often edit the URL, and I've found that I most often either 1) go "up"
one directory, 2) go to the base directory (such as
groups.google.com), or 3) go to the host (such as google.com).
Consequently, if the URL were split into a mere three buttons, that
would reduce the added complexity as well, leaving the less common
changes to editing by hand (which, again, would remain as easy as it
is now).
In the end, my biggest concern is the usability of formatting the URL.
If the user sees the host name in bold, it should not suddenly lose
that formatting, whether on focus or on hover. This steals attention
away from browsing to domesticating the location bar. It will annoy
users, and draw many complaints. If the host name will be formatted
(which it should, at the very least), the only usable way of doing
this is to keep it formatted when it's being edited. Such
functionality should make autoformatting possible, for consistency,
and also allow adding some background for unfocused "buttons" (similar
to your mock-up). But, even if buttons are never added, this usability
issue should not be neglected.
Thank you,
David.
Gervase Markham
> It appears that you belong to a minority then. There were very few who
> opposed the protocol hiding.
Although Ping is a respected usability/security researcher. So his
opinion is worth considering, assuming he supplies rationale :-).
> It allows us to emphasize the host without bolding it (which would cause
> several already-discussed problems) and without making the rest of the
> URL gray. It also reduces the risk that users confuse "https" with
> "secure" or even "trustable".
To be accurate: it allows us to emphasise the host by placing whitespace
on both sides, which is one form of emphasis. Bold is another, which as
problems that we've discussed. Ping is proposing yet another, which is
to de-emphasise the rest of the URL, an option we haven't really
considered yet.
Gerv
Gervase Markham
> We still need to distinguish the eTLD+1 from the rest of the URL
> somehow. Fading it out is by far the simplest way to do this, because
> nothing moves at all. (Shading the background would be an equally
> simple option.)
Aesthetically, I don't like the idea of changing the background colour.
I could perhaps be convinced if I saw a pleasing mock-up. And, of
course, if the two are in conflict then security needs to beat
aesthetics, so if there's no other suitable way, we'd need to consider it.
>> It also reduces the risk that users confuse "https" with
>> "secure" or even "trustable".
>
> I don't think that's a fear we should address here. (Should we
> hide ".com" for fear that users confuse it with "commercial"?
> I think not.)
The two situations are not analagous, because confusing .com with
"commercial" is not a mistake with security implications.
However, greying the scheme along with the rest of the non-TLD+1 URL
provides a certain amount of the benefit given by hiding it anyway.
Gerv
Gervase Markham
> Gervase Markham wrote:
>> The problem with this suggestion, which seems logical, is that many
>> people (including me) click in the URL bar to focus it before then doing
>> a drag-select. Educating me and them out of this behaviour would be very
>> hard.
>
> Really? I can select any bit of text in the bar immediately without
> first focusing it, regardless how browser.urlbar.clickSelectsAll is
> set.
Yes, you _can_. That doesn't mean that I _do_.
> Well, shouldn't it all go somewhere anyway?
You may think that; others may disagree; regardless, the plain fact of
the matter is that at the moment, on many websites, it doesn't. So we
would basically be adding a bunch of "take me to a 404 or 500 error"
buttons to our UI.
> If the host name will be formatted
> (which it should, at the very least), the only usable way of doing
> this is to keep it formatted when it's being edited.
I certainly agree that this is very important.
Gerv
Gervase Markham
> One anti-phishing approach I've recently seen at some secure logon sites
> (primarily financial institutions) is for the consumer to select some
> small image when they register. Then, whenever they go to the legitimate
> site in the future, they are displayed the image they selected at the
> login screen. The thought being that a phishing site wouldn't be aware
> nor have access to your specific image.
>
> I'm not sure if this image technique is some type of industry standard
> but if so and the browser could reliably access the image (via some XML
> tag?) then maybe using it for the favicon (when present) might be helpful.
Even if this were possible, favicon size is too small for such an image.
Gerv
Robert Kaiser
> Ping is proposing yet another, which is
> to de-emphasise the rest of the URL, an option we haven't really
> considered yet.
And which is quite interesting, as we can even use system colors (I
believe there's probably a system color for deactivated text) and it
keeps the whole URLs there for advanced users to edit it, and things
can't jump when going into edit mode, etc.
Robert Kaiser
Dão
> Dão wrote:
>> It allows us to emphasize the host without bolding it (which would
>> cause several already-discussed problems) and without making the rest
>> of the URL gray. It also reduces the risk that users confuse "https"
>> with "secure" or even "trustable".
>
> To be accurate: it allows us to emphasise the host by placing whitespace
> on both sides, which is one form of emphasis. Bold is another, which as
> problems that we've discussed. Ping is proposing yet another, which is
> to de-emphasise the rest of the URL, an option we haven't really
> considered yet.
>
> Gerv
The whitespace and the gray color (that I already use) makes two levels
of emphasis. That gave us the opportunity to make the entire host more
visible (not just TLD+1), emphasize path segments (by making slashes
gray) and degrade URL hashes and query strings. I don't see the benefit
of losing all that.
Two more things to consider:
* Protocol hiding can be turned off with a pref and the appearance can
be changed through CSS, so my implementation is in a way compatible
with Ping's proposal.
* You said the gray that I used (the native color) would be to faint.
Thus, using it for the entire URL is even more critical.
--Dao
Gervase Markham
> The whitespace and the gray color (that I already use) makes two levels
> of emphasis.
This is true.
> That gave us the opportunity to make the entire host more
> visible (not just TLD+1),
Is this actually a good thing? It seems to me that we either want to
emphasise TLD+1 or we don't. We don't want to emphasise it but then say
"oh, but we want to emphasise the entire host, too".
> emphasize path segments (by making slashes
> gray)
I feel this is actually a backwards step. The separators between
different parts of a URL are _more_ important than the parts themselves,
not less - particularly when phishing is concerned.
> * Protocol hiding can be turned off with a pref and the appearance can
> be changed through CSS, so my implementation is in a way compatible
> with Ping's proposal.
Sure.
> * You said the gray that I used (the native color) would be to faint.
> Thus, using it for the entire URL is even more critical.
It may well be too faint. But I did say it originally in the context of
greying out the separators, which are thin lines and hard to see at the
best of times.
Gerv
Dão
>> That gave us the opportunity to make the entire host more visible (not
>> just TLD+1),
>
> Is this actually a good thing? It seems to me that we either want to
> emphasise TLD+1 or we don't. We don't want to emphasise it but then say
> "oh, but we want to emphasise the entire host, too".
The host is the most important part of a location (the address) and
TLD+1 is the most important part of the host. I don't see a problem with
representing both in the GUI. Making the host recognizable is not
security-related like emphasizing TLD+1, but nevertheless useful to help
users understand URLs.
>> emphasize path segments (by making slashes gray)
>
> I feel this is actually a backwards step. The separators between
> different parts of a URL are _more_ important than the parts themselves,
> not less - particularly when phishing is concerned.
To me highlighting segments has the same effect as highlighting
separators: help users to parse URLs (e.g. in order to expose phising).
The reason why I chose the former is readability.
--Dao
Gervase Markham
> The host is the most important part of a location (the address) and
> TLD+1 is the most important part of the host. I don't see a problem with
> representing both in the GUI. Making the host recognizable is not
> security-related like emphasizing TLD+1, but nevertheless useful to help
> users understand URLs.
Having users "understand URLs" is not a goal. URLs are complicated
identifiers which were never really meant to be exposed to users anyway;
the fact that they are is unfortunate. But, given that they are, users
are required to have a small understanding of how they work. But there
is no point in attempting to extend that understanding past what is
necessary.
>>> emphasize path segments (by making slashes gray)
>>
>> I feel this is actually a backwards step. The separators between
>> different parts of a URL are _more_ important than the parts
>> themselves, not less - particularly when phishing is concerned.
>
> To me highlighting segments has the same effect as highlighting
> separators: help users to parse URLs (e.g. in order to expose phising).
I don't agree that they are the same; your grey slashes are very easy to
overlook or read as spaces.
Gerv
Dão
> Dão wrote:
>> The host is the most important part of a location (the address) and
>> TLD+1 is the most important part of the host. I don't see a problem
>> with representing both in the GUI. Making the host recognizable is not
>> security-related like emphasizing TLD+1, but nevertheless useful to
>> help users understand URLs.
>
> Having users "understand URLs" is not a goal. URLs are complicated
> identifiers which were never really meant to be exposed to users anyway;
> the fact that they are is unfortunate. But, given that they are, users
> are required to have a small understanding of how they work. But there
> is no point in attempting to extend that understanding past what is
> necessary.
First, I think enabling users to (better) understand URLs goes hand in
hand with anti-phishing.
Secondly, I want to remind you of your proposal to highlight TLD+2,
which was (imho) not security-related at all but based on the
acknowledgement of the host's general value.
>>>> emphasize path segments (by making slashes gray)
>>>
>>> I feel this is actually a backwards step. The separators between
>>> different parts of a URL are _more_ important than the parts
>>> themselves, not less - particularly when phishing is concerned.
>>
>> To me highlighting segments has the same effect as highlighting
>> separators: help users to parse URLs (e.g. in order to expose phising).
>
> I don't agree that they are the same; your grey slashes are very easy to
> overlook or read as spaces.
OK, I certainly respect that objection. But then again, given the
current implementation, changing the appearance would be trivial. I
don't think it should hold up the progress now. A more productive
approach would be to open a new bug like "decide what to do with
separators" and request / make it blocking-firefox3.
--Dao
Ka-Ping Yee
> Ka-Ping Yee wrote:
> > We still need to distinguish the eTLD+1 from the rest of the URL
> > somehow. Fading it out is by far the simplest way to do this, because
> > nothing moves at all. (Shading the background would be an equally
> > simple option.)
>
> Aesthetically, I don't like the idea of changing the background colour.
> I could perhaps be convinced if I saw a pleasing mock-up.
I agree with your aesthetic preference here. Also, shading the
background
may give the impression that there is a text selection when there
isn't.
-- ?!ng
Ka-Ping Yee
> To be accurate: it allows us to emphasise the host by placing whitespace
> on both sides, which is one form of emphasis. Bold is another, which as
> problems that we've discussed. Ping is proposing yet another, which is
> to de-emphasise the rest of the URL, an option we haven't really
> considered yet.
Let's see if we can summarize the various options.
(I'm getting tired of typing eTLD + 1 so let me use a shorter
abbreviation:
RDN for "registered domain name".)
1. RDN in bold.
2. RDN in alternate font.
3. RDN with space on both sides.
4. RDN with shaded background.
5. Non-RDN in grey.
6. RDN in special colour.
7. RDN underlined.
Feel free to add to this list other options I haven't thought of.
Of these options, #1 through #3 affect layout, which means that either
the text will move when switching between editing and viewing modes,
or the text will have to be kept specially formatted during editing.
Of these, #1 is probably the least strange formatting to keep during
editing, and #3 the most strange. #4 through #7 do not affect layout.
Also, #7 may impair the readability of the RDN, depending on the
placement of the underline.
Differences in colour are pre-attentive, so #5 and #6 probably make
the RDN stand out the quickest, with #1 closely following, depending
on how much heavier the bold text is compared to regular text.
#3, #4, and #7 come next. With #3 the only added cognitive effort is
to decide which of the three separated pieces is the interesting one.
With #4 and #7, the extra required effort consists of associating the
new element (background or underline) with the text. And finally,
#2 is likely to be the most difficult for distinguishing the RDN.
In summary:
Ranked by layout, we have: 4, 5, 6, 7; then 1; then 2, 3.
Ranked by perception, we have: 5, 6; then 1; then 3, 4, 7; then 2.
It would appear from this analysis that #5 and #6 fare best; also #6
gets a penalty due to colour-blind users and possible clashing if the
background colour is going to change for other purposes. Thus,
my favourite is #5, though #6, #1, #4, and #7 are also possibilities
with various trade-offs.
By the way, if you want to try out #5 and get a sense of how it feels,
I've implemented it as a tweak to Locationbar2:
http://zesty.ca/lj/locbar2ping.xpi
-- ?!ng
Sailfish
Robert Kaiser
> It would appear from this analysis that #5 and #6 fare best; also #6
> gets a penalty due to colour-blind users and possible clashing if the
> background colour is going to change for other purposes.
And #6 should get another (or the same) penalty for non-color-blind
users that have different-than default OS themes and may get urlbar
background and text colored differently then the default, which may
clash with the special color for the RDN. There's always a standard
gray/disabled text system color though, which can be used for #5 though.
Robert Kaiser