Location Bar Proposal
Gervase Markham
For the past few weeks, we've been playing with various ideas relating
to the Location Bar here in mozilla.dev.apps.firefox[1]. Dao Gottwald
has been doing a great job keeping up with the suggestions, and
implementing them in the excellent LocationBar2 extension[2].
Having done the prototyping, and a UI review with Jonathan Nightingale
and Mike Beltzer, we now propose that we do the following two
independent things, as a start:
1) Remove the favicon from the URL bar. We want to make the URL bar
totally trusted, and that means not allowing sites to control parts of
it to spoof locks or things like that. We can either remove it entirely
or replace it with a generic page icon/folder icon/whatever under our
control.
I note that mockups posted recently for the Places UI use this icon for
a menu, and so we may need to negotiate as to what happens.
2) Change the URL bar so that everything except "Public Suffix + 2" is
greyed out. If the URL bar is focussed or hovered over, the colour
switches back to black throughout. This should be possible using CSS
only. The "greyed-out" colour is a pref; people who don't like this
feature can set it to "black".
Public Suffix (also called Effective TLD[3]) is the part of the URL not
owned by a registrant. E.g. ".com", ".co.uk", "hokkaido.co.jp". 2 is the
default for a pref; we think this is the right number, but want real
world experience. So Public Suffix + 2 is e.g. http://WWW.MOZILLA.ORG,
http://www.IBANK.BARCLAYS.CO.UK/foo/bar/login.do,
http://www.FRED.BLOGSPOT.COM/archive/2007/04/06/mypost.
This will look basically as mocked up by Ka-Ping Yee here:
http://zesty.ca/mozilla/locbar.html
We may also do other things from the LocationBar2 UI experiments.
However, these two things are where we want to start, and then we can
look at further changes.
I'd like to finish by pointing out that it seems to me that the process
we've just gone through is a textbook example of how open source
development and UI prototyping _should_ work in our world. We had loads
of cool ideas, implemented them in an extension, kicked them around a
lot in discussion, realised some were too radical, and have now come out
with a considered proposal. This rocks. Thank you to everyone who took part.
Gerv
[0]
http://weblogs.mozillazine.org/gerv/archives/2007/05/location_bar_proposal_1.html
[1]
http://groups.google.com/group/mozilla.dev.apps.firefox/search?group=mozilla.dev.apps.firefox&q=location+bar&qt_g=Search+this+group
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=366797
[3] http://wiki.mozilla.org/Gecko:Effective_TLD_Service
Edward Lee
> we now propose that we do the following two things *as a start*
> 1) Remove the favicon from the URL bar
Sounds good for a start for those who already look at the location bar
and understand domains.
Are there plans on how to get average users to look at the location bar
in the first place and show them something they can easily process?
I did a little user study of random people in the University's Student
Union to visit websites while using 1 of 3 versions of Firefox: standard
browser, LocationBar 2, in-your-face domain display.
The participants were provided a scenario of a scavenger hunt to visit
various linked websites to find a piece of information; about half of
the sites used a spoofed domain. None of the people in the study noticed
the small changes (facebook.com -> facelook.com), the odd changes
(www.google.com -> 1.2.3.4.5.6.7.8.9), or the big changes
(en.wikipedia.org -> en.wikiwikiland.net).
Even though some of them frequently visit those website (some daily, so
they should recognize the domain), they did not comment on anything
strange. Even when a third of participants usually manually enter
websites in the location bar when opening a browser (meaning they know
of domains), they did not notice the domain name changes. Half of them
avoid domains when opening the browser to go to websites by using
favorites/bookmarks or Google.
However, users do have some level of trust for various websites. For
each each answer, participants ranked a level of trust from 1 (low) to 5
(high). Interestingly, MySpace was consistently lower than others like
Google and YouTube.
Ed
Sohail Mirza
> 1) Remove the favicon from the URL bar. We want to make the URL bar
> totally trusted, and that means not allowing sites to control parts of
> it to spoof locks or things like that. We can either remove it entirely
> or replace it with a generic page icon/folder icon/whatever under our
> control.
By losing the favicon from the URL bar, we also lose the ability to
drag/drop the favicon to bookmark, etc. I'm not certain how many
Firefox users actually bookmark in this fashion, but I imagine a good
number of people could be bookmarking sites in this manner.
I'm aware that one can just as easily drag and drop the tab, but is
the average user aware of this? Downsides to this are that the
default behaviour of Firefox is to hide the tab bar when only one tab
is present, and that the favicons on the tab bar don't look drag/
droppable (much like the Fx icon in the window titlebar).
Has the ability to drag/drop the favicon been given due consideration
or affected the decision in any way?
Jesse Ruderman
would fix the "throbber is always visible" problem that annoys Mac
purists (without creating odd-looking blank space), and it would be
consistent with what we do on tabs.
Gervase Markham
I think we want to keep site-controlled content corralled as much as
possible into the content area and tabs.
Also, I think the above is a solution in search of a problem. If we
remove the favicon from the URL bar, is it now invisible? No, it's on
the tabs. Why does it need greater visibility?
Gerv
Gervase Markham
> By losing the favicon from the URL bar, we also lose the ability to
> drag/drop the favicon to bookmark, etc. I'm not certain how many
> Firefox users actually bookmark in this fashion, but I imagine a good
> number of people could be bookmarking sites in this manner.
It's an open question as to whether it vanishes, or whether you get a
generic page icon in its place. This is an argument for the latter,
certainly.
Gerv
Robert Kaiser
> I think we want to keep site-controlled content corralled as much as
> possible into the content area and tabs.
Does this include text in the window's title bar, status bar (I guess
this is off by default anyways), etc.?
And then there's this recent proposal of site-controlled sidebars and
toolbars, which goes directly against this statement...
> Also, I think the above is a solution in search of a problem. If we
> remove the favicon from the URL bar, is it now invisible? No, it's on
> the tabs. Why does it need greater visibility?
Because there are people who might hide those [cursing language
stripped] tabs and not use them ;-)
But then, they can use a browser that still has this feature, like, say,
IE^H^HSeaMonkey, just to name one.
Robert Kaiser
Gervase Markham
> Gervase Markham schrieb:
>> I think we want to keep site-controlled content corralled as much as
>> possible into the content area and tabs.
>
> Does this include text in the window's title bar, status bar (I guess
> this is off by default anyways), etc.?
We switched off the ability for the site to change the status bar text
for this reason as well.
> And then there's this recent proposal of site-controlled sidebars and
> toolbars, which goes directly against this statement...
Not necessarily. These would appear in the content area. It would be
important to style these so they appeared like content rather than chrome.
> But then, they can use a browser that still has this feature, like, say,
> IE^H^HSeaMonkey, just to name one.
Quite.
Gerv
rainierw...@gmail.com
difference between the black and grey used in the mockup; I don't
think the grey should be so faint).
Removing the favicon would mean that you should simply remove any icon
in the location bar altogether. What's the point of wasting space to
show a white page 100% of the time? However, I hope that you do not
remove it because the padlock icon doesn't appear to the left of the
URL and always appears to the right. Besides which, the location bar
also changes colour, which is what I pay more attention to, so if
there are some dummies that are being fooled by a padlock favicon,
then should Firefox users with brains have their browser stripped bare
in an attempt to protect idiots from themselves? I surely hope not...
dusa...@gmail.com
>
> 1) Remove the favicon from the URL bar. We want to make the URL bar
> totally trusted, and that means not allowing sites to control parts of
> it to spoof locks or things like that. We can either remove it entirely
> or replace it with a generic page icon/folder icon/whatever under our
> control.
Why lose a feature? This will not add anything to the actual security.
Just a "feel good" measure and cramping the creativity. Absolutely
wrong. Majority of sites use favicon for creative content, not for
spoofing locks.
We can either remove it entirely
> or replace it with a generic page icon/folder icon/whatever under our
> control.
...
Why should it be generic and/or under your control? Give us more
freedom in the URL bar. Allow site to use different font, style,...
That is progressive. Control it against the "lies", not against the
design.
>
> 2) Change the URL bar so that everything except "Public Suffix + 2" is
> greyed out. If the URL bar is focussed or hovered over, the colour
> switches back to black throughout. This should be possible using CSS
> only. The "greyed-out" colour is a pref; people who don't like this
> feature can set it to "black".
>
More "overcontroling"... URL is there to give complete description of
the page
location. User have a great interest to know what it is. Do not
interrupt
between the user and the content! Do make security features that
prevent spoofing
but do not obstruct the user in any way or highlight parts of your
choice.
>
> This will look basically as mocked up by Ka-Ping Yee here:http://zesty.ca/mozilla/locbar.html
>
>
Please provide the real security and do not cramp the creativity of
designers. Stay away
from filtering the content in any way. That would summarize my
opinion.
Hope this helps,
Dusan Maletic
marty...@gmail.com
Removing the favicon from the location bar seems wrong, but I can't
put my finger on why. Perhaps because I can't think of another
logical place for it. It also serves as a bookmark drag target, so it
shouldn't move far from where it has been since it was created. On
second thought, if the URI is going to have visual clues about itself,
moving the favicon is probably unnecessary.
In my opinion, the main reason why phishing works is because the
average user doesn't know how a URI is constructed. Give them some
hints. Highlighting the domain + TLD is a good start, however I
suggest this feature launch in its complete form: differentiate all 6
(7) segments of the URI by color:
- protocol
- hostname (ie, www)
- domain + TLD
- path
- filename
- GET string (names and values could be colored differently)
- anchor
In the mockup, the rest of the URI has been grayed out too much.
Perhaps make domain + TLD bold, and colorize the other segments?
Not that the average user ever looks at URI's in the bottom toolbar
when hovering over links, but I also suggest applying the same
highlighting scheme there as well.
dan...@glazman.org
1. I see more cons to the loss of the favicon in the adressbar than
pros.
2. using a grey font color in the address bar is a HUGE accessibility
and readability issue... I burnt my right eye a long ago and lost a
bit of sensibility to reds and yellows. The screenshot shown in Alex
Faaborg's blog is already VERY hard to read for me. Do **NOT**
implement this feature w/o spending hours thinking on the
accessibility problems it implies. Thanks.
</Daniel>
Robert Sayre
> I think both proposals are dangerous as they are.
>
> 1. I see more cons to the loss of the favicon in the adressbar than
> pros.
This could be true. Perhaps you could list the pros and cons?
>
> 2. using a grey font color in the address bar is a HUGE accessibility
> and readability issue...
I agree that there are issues. I also found it pretty hard to look at.
Another issue is that the path component of URIs can sometimes be very
useful:
http://www.technorati.com/posts/tag/restful+web+services
and the grey coloring of the location bar makes that harder to read.
- Rob
Peter Lairo
> I hope that you do not
> remove it because the padlock icon doesn't appear to the left of the
> URL and always appears to the right. Besides which, the location bar
> also changes colour, which is what I pay more attention to, so if
> there are some dummies that are being fooled by a padlock favicon,
> then should Firefox users with brains have their browser stripped bare
> in an attempt to protect idiots from themselves? I surely hope not...
+1
--
Regards,
Peter Lairo
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Peter Lairo
> Majority of sites use favicon for creative content, not for
> spoofing locks.
Make that: *vast* majority...
Anders Vindberg
I second that!
A suggestion, how about extending the URI with some intellisence,
taking data from Google Sitemaps if a page has made such available.
Tony Mechelynck
[...]
> Removing the favicon from the location bar seems wrong, but I can't
> put my finger on why. Perhaps because I can't think of another
> logical place for it. It also serves as a bookmark drag target, so it
> shouldn't move far from where it has been since it was created.
The favicon is already duplicated on the current tab; but I'd like it to
remain on the URL bar too: after all, the window title is duplicated on the
tab, does that mean we should remove one or the other?
> On
> second thought, if the URI is going to have visual clues about itself,
> moving the favicon is probably unnecessary.
I don't see why. The URI could have some parts bolded or grayed and still be
preceded by a site icon.
>
> In my opinion, the main reason why phishing works is because the
> average user doesn't know how a URI is constructed. Give them some
> hints. Highlighting the domain + TLD is a good start, however I
> suggest this feature launch in its complete form: differentiate all 6
> (7) segments of the URI by color:
>
> - protocol
> - hostname (ie, www)
> - domain + TLD
> - path
> - filename
> - GET string (names and values could be colored differently)
> - anchor
>
> In the mockup, the rest of the URI has been grayed out too much.
> Perhaps make domain + TLD bold, and colorize the other segments?
>
> Not that the average user ever looks at URI's in the bottom toolbar
> when hovering over links, but I also suggest applying the same
> highlighting scheme there as well.
>
I'd prefer the URL in the status bar to remain the "raw" HREF. It may be
something else that an HTTP or FTP URL, remember (mailto:, javascript: or even
about: come to mind; from a local page it could also be file: ).
Best regards,
Tony.
--
"You've got to think about tomorrow!"
"TOMORROW! I haven't even prepared for *_yesterday_* yet!"
Gervase Markham
> Why lose a feature? This will not add anything to the actual security.
> Just a "feel good" measure and cramping the creativity. Absolutely
> wrong. Majority of sites use favicon for creative content, not for
> spoofing locks.
And the majority of sites aren't malicious. That doesn't in itself mean
we should do nothing about those that are.
> Why should it be generic and/or under your control? Give us more
> freedom in the URL bar. Allow site to use different font, style,...
> That is progressive. Control it against the "lies", not against the
> design.
That's a terrible idea. It would make misleading users far easier if
sites could control the font used in the URL bar. We have enough trouble
finding one font that makes a good distinction between 1, i, l and I
without having to find a whole bunch.
> More "overcontroling"... URL is there to give complete description of
> the page
> location. User have a great interest to know what it is.
A user really cares that their JSESSIONID is 35FAGKE453F?
Gerv
Gervase Markham
> In my opinion, the main reason why phishing works is because the
> average user doesn't know how a URI is constructed. Give them some
> hints. Highlighting the domain + TLD is a good start, however I
> suggest this feature launch in its complete form: differentiate all 6
> (7) segments of the URI by color:
And how would the user know which ones are the important ones?
Surely the solution to "users don't know how a URL is constructed" is
not "teach them" but "make it so they don't have to know".
If your user model and your program model don't fit together, change the
program model. It's much easier than changing the user model.
Gerv
Gervase Markham
> 2. using a grey font color in the address bar is a HUGE accessibility
> and readability issue... I burnt my right eye a long ago and lost a
> bit of sensibility to reds and yellows. The screenshot shown in Alex
> Faaborg's blog is already VERY hard to read for me. Do **NOT**
> implement this feature w/o spending hours thinking on the
> accessibility problems it implies. Thanks.
It's not supposed to be as obvious. That's the _point_. If you want to
read the other parts of the URL, press Ctrl-L. The highlight difference
goes away whenever the URL bar is focussed or hovered.
Gerv
gfr...@adaptavist.com
http://en.design-noir.de/mozilla/locationbar2/
The key things I like about it are:
* Convert URL to a breadcrumb trail
* Options for customising the design of the URL - eg. whether to hide
protocol, etc
Michael Lefevre
> dan...@glazman.org wrote:
>> 2. using a grey font color in the address bar is a HUGE accessibility
>> and readability issue...
> It's not supposed to be as obvious. That's the _point_. If you want to
> read the other parts of the URL, press Ctrl-L. The highlight difference
> goes away whenever the URL bar is focussed or hovered.
Maybe it's not supposed to be obvious, but is it supposed to be readable?
If it supposed to show just the domain and give an indication that there
is some other stuff there, then is there a way of doing that without
making people try to read something that's hard to read?
If people's brains have to make a quick choice between straining their
eyes for a couple of seconds and moving their hands about, they will
probably go with the eye straining every time and give themselves a
headache.
On the other hand, I guess it won't be too hard to remove the greying-out
effect with an addon (or maybe even a couple of lines in the chrome CSS
file), for those people that understand URLs and want to read them all the
time.
--
Michael
ben.ja...@gmail.com
I personally agree with many others when I say that the graying out is
a bit much. It's a good idea, but the way it's been implemented is
entirely wrong. Why are you fading out the rest of the url? Couldn't
you highlight the important part instead? Instead of making it stand
out by fading the rest of the address, why not just highlight it.
Also I'm a huge fan of favicons, and since on mac the bookmark bar
doesn't show them, I'd really rather not lose them in the url.
I think phishing will continue to be a problem, but this appears to
be a knee jerk reaction.
mark2...@gmail.com
be such a big deal that you would remove part of what makes each site
unique. That's disruption of the user experience. A Microsoft style
baby with the bath water precaution.
Peter Kasting
The proposal is to remove the favicon from the location bar, not from
tabs/bookmarks/etc.
"Don't Panic" - Douglas Adams
PK
Thomas Stache
People, the proposal removes favicons from the location bar, but not
from the browser tabs. There you will see them in full glory.
Gervase Markham
> Maybe it's not supposed to be obvious, but is it supposed to be readable?
> If it supposed to show just the domain and give an indication that there
> is some other stuff there, then is there a way of doing that without
> making people try to read something that's hard to read?
Well, if something needs to be emphasised, that means that other things
have to be deemphasised. We tried things like bold, but characters (e.g.
i and l) are less different in bold fonts.
> On the other hand, I guess it won't be too hard to remove the greying-out
> effect with an addon (or maybe even a couple of lines in the chrome CSS
> file), for those people that understand URLs and want to read them all the
> time.
Indeed. There will probably be a pref.
Gerv
Gervase Markham
> I personally agree with many others when I say that the graying out is
> a bit much. It's a good idea, but the way it's been implemented is
> entirely wrong. Why are you fading out the rest of the url? Couldn't
> you highlight the important part instead? Instead of making it stand
> out by fading the rest of the address, why not just highlight it.
In what way? We have, thusfar, not been able to come up with a method of
highlighting which is both readable and accessible. (I suggest you read
about what we've tried before proposing one.)
> Also I'm a huge fan of favicons, and since on mac the bookmark bar
> doesn't show them, I'd really rather not lose them in the url.
They will still appear on the tabs.
> I think phishing will continue to be a problem, but this appears to
> be a knee jerk reaction.
What makes you say that? Have you analysed our reasons for making this
change?
Gerv
Gervase Markham
> * Convert URL to a breadcrumb trail
We've tried this - it just doesn't work from a usability perspective,
and it doesn't work from a website structure perspective. It's basically
the equivalent of adding a load of buttons to the interface which half
the time, when pressed, take you to a 404 Not Found page.
> * Options for customising the design of the URL - eg. whether to hide
> protocol, etc
Are you really suggesting that this be something Firefox has UI for by
default?
Gerv
Gervase Markham
Have you actually bothered to familiarise yourself with what we are
actually proposing? We are not proposing the "removal of favicons".
(Anyway, even if we were, people coped fine without them up until a
couple of years ago.)
Gerv
Robert Kaiser
> Surely the solution to "users don't know how a URL is constructed" is
> not "teach them" but "make it so they don't have to know".
To me, this sounds of resolving drivers not understanding street signs
and traffic rules by abolishing cars instead of requiring people to get
a drivers license.
I think the real solution is "ease users to learn themselves what is
important" and not "remove everything from the UI that somehow could get
complicated". That's what I always have disliked about MS's misguided
"usability improvements" in Windows with hiding everything that was
actually useful and replacing it with useless eye candy.
We shouldn't go down that path generally. But then, Firefox sometimes
tries to just imitate MS's UI style too much for me anyways, so maybe my
view of this is just one of the reasons why I'm not a Firefox user
myself. ;-)
Robert kaiser
cruo...@gmail.com
> However, these two things are where we want to start, and then we can
> look at further changes.
>
> I'd like to finish by pointing out that it seems to me that the process
> we've just gone through is a textbook example of how open source
> development and UI prototyping _should_ work in our world. We had loads
> of cool ideas, implemented them in an extension, kicked them around a
> lot in discussion, realised some were too radical, and have now come out
> with a considered proposal. This rocks. Thank you to everyone who took part.
>
> Gerv
>
> [0]http://weblogs.mozillazine.org/gerv/archives/2007/05/location_bar_pro...
> [1]http://groups.google.com/group/mozilla.dev.apps.firefox/search?group=...
> [2]https://bugzilla.mozilla.org/show_bug.cgi?id=366797
> [3]http://wiki.mozilla.org/Gecko:Effective_TLD_Service
That's bulll****.
1.) the favicon helps in recognizing where I'm in fact. A nice little
image is often easier to remember than a quirky domain name. I propose
to make the favicon optional. Make the default setting whatever you
want, but don't remove it entirely, for goodness sake!
2.) As of me, I differentiate two kinds of browsing: cross-domain, and
intra-domain browsing. It's very common to browse dozens of pages on a
single domain. In most cases, it's the end of the domain which
actually tells you where you are: look at blogs, semantic urls, etc.
Firefox has a bunch of nice features. If there aren't much to do,
there aren't. Focus on security, memory management (which imo got
certainly better with 2.x), and ease of use. Do not reinvent the
wheel. Don't behave like Microsoft: respect what's commonly accepted
(here I mean the usage of favicons, for example).
Kevin
> 1) Remove the favicon from the URL bar.
> greyed out.
I'm opposed to this idea for a few reasons:
* as mentioned, some people use the favicon in the URL bar for
bookmarking things (I've done that often) and for determining which
site the user is on. Designers use it for branding.
The argument that this icon will still show up on the tabs is moot
when only one page is being viewed -- there are no tabs then.
* it addresses an edge case (spoofed lock icons)
* alternative methods could be used to point out the domain (if domain
spoofing is the main concern here). If highlighting and bold don't
pass user experience tests, maybe flashing a background color (behind
a span for the public suffix +2) when the domain changes. It seems
that we're really only concerned with the times when a domain is
changing, not persistently.
* there is no easy way to tell the user that if they click on the URL
they'll be able to see the whole string, and the grayed-out text is
really difficult to read without focusing the URL bar.
* those users who ignore the URL now may notice the dimming the first
few times, but since it isn't in their main field of view, they will
probably ignore it after a few site visits, and they won't benefit
from having the color contrast there. (if they're not looking at the
domain now, how will dimming the text ensure that they'll look in the
future, if none of the text elements are becoming more visible?)
Removing or replacing the favicon doesn't directly solve the issue of
spoofing, nor does it offer any real benefits. It seems to have more
disadvantages than benefits, even if users do start noticing that
they're being spoofed (and informed users know where the proper place
for a SSL icon is, and the change in URL background color).
Furthermore, it seems that the malware detection feature could act as
a suitable method for informing the user that they are on a
questionable site. It would be more apparent to the end user and
doesn't remove any functionality in doing so.
Alternatively, there is my earlier suggestion that a brief
highlighting or spotlight effect on the TLD + domain would bring
enough attention when the site has changed (especially if the user
doesn't expect a change in the site name), which also doesn't require
eliminating the existing favicon functionality.
Alex Faaborg
Favicon:
To quote a statement beltzner made earlier today: "if the problem is
a 16x16 pixel favicon can look like our 16x16 pixel security
indicator, why don't we change the security indicator?" I completely
agree, and I think Johnathan is working on some new security UI mockups.
Grey URL bar text:
I am in favor of the changing the formating of the URL bar, since I
believe the domain name is simply more important than the rest of the
information, and for the vast majority of users, the domain name is
the only understandable piece of the URL.
However, I don't think this will have any effect of protecting users
from phishing attacks. Consider this study done at MIT:
> (60%) used rationalizations to justify the
> indicators of the attacks that they experienced. Nine
> subjects explained away odd URLs with comments like:
>
> www.ssl-yahoo.com is a subdirectory of Yahoo!, like
> mail.yahoo.com.
>
> sign.travelocity.com.zaga-zaga.us must be an
> outsourcing site for travelocity.com.
>
> Sometimes the company [Target] has to register a
> different name [www.mytargets.com] from its brand.
>
> What if target.com has already been taken by another
> company?
>
> Sometimes I go to a website and the site directs me to
> another address which is different from the one that I
> have typed.
>
> I have been to other sites that used IP addresses [instead
> of domain names].
http://groups.csail.mit.edu/uid/projects/phishing/chi-security-
toolbar.pdf
So, even if we go nuts and color code every part of the URL, AND
magically everyone understands the color coding, people are still
going to rationalize.
But I still think we should grey out the rest of the URL, not because
it will help with phising, but because the visual design matches the
relative importance of each piece of information.
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Gervase Markham
> To me, this sounds of resolving drivers not understanding street signs
> and traffic rules by abolishing cars instead of requiring people to get
> a drivers license.
I don't think that analogy holds. A better analogy would be resolving
drivers not understanding traffic rules by engineering the cars to know
how not to crash into each other, so they don't have to learn.
Is understanding a URL vital to being able to browse the web today? No,
but you can be at risk in some circumstances. So either we can teach
people to understand URLs (a very difficult task) or we can work to
eliminate the risk.
http://weblogs.mozillazine.org/gerv/archives/2007/06/choice_considered_harmful.html
Gerv
Gervase Markham
> 1.) the favicon helps in recognizing where I'm in fact. A nice little
> image is often easier to remember than a quirky domain name. I propose
> to make the favicon optional. Make the default setting whatever you
> want, but don't remove it entirely, for goodness sake!
Are you actually reading? We aren't removing it entirely.
Gerv
Gervase Markham
> The argument that this icon will still show up on the tabs is moot
> when only one page is being viewed -- there are no tabs then.
>
> * it addresses an edge case (spoofed lock icons)
All security problems are "edge cases", because the vast majority of
sites are legitimate. Regardless, it's not just about spoofed lock
icons, it's about "this UI is trusted" vs "this UI is not trusted".
Are people more likely to be fooled if they see the Bank of America
favicon next to www.bankofamericapayments.com? If so, that's a bad thing.
> * alternative methods could be used to point out the domain (if domain
> spoofing is the main concern here). If highlighting and bold don't
> pass user experience tests, maybe flashing a background color (behind
> a span for the public suffix +2) when the domain changes. It seems
> that we're really only concerned with the times when a domain is
> changing, not persistently.
That's an interesting idea. However, it would also be distracting.
There's a fine line, particularly with security UI, between making sure
the information is there when the user needs it, and irritating them. I
think this may be the wrong side.
> * there is no easy way to tell the user that if they click on the URL
> they'll be able to see the whole string,
No, but I anticipate that they'll work it out pretty darn quickly. It's
not the world's most complicated relationship.
> * those users who ignore the URL now may notice the dimming the first
> few times, but since it isn't in their main field of view, they will
> probably ignore it after a few site visits, and they won't benefit
> from having the color contrast there. (if they're not looking at the
> domain now, how will dimming the text ensure that they'll look in the
> future, if none of the text elements are becoming more visible?)
The idea is not about being in-your-face with it, the point is that
currently users don't understand how to parse URLs. Which is the
relevant domain in the following?
www.microsoft.com.foo.com/bankofamerica.com?ibm.com=google.com#sun.com
You might know, but most people don't. The highlighting is a massive
parsing hint.
> Removing or replacing the favicon doesn't directly solve the issue of
> spoofing,
No, but neither does any single measure.
Gerv
Gervase Markham
> To quote a statement beltzner made earlier today: "if the problem is a
> 16x16 pixel favicon can look like our 16x16 pixel security indicator,
> why don't we change the security indicator?" I completely agree, and I
> think Johnathan is working on some new security UI mockups.
That's not the only problem. As I just wrote in another post, it's about
whether the URL bar is trusted UI or not. The current situation, where
some bits are trusted and some aren't, is bad. We need to go one way or
the other.
> Grey URL bar text:
> I am in favor of the changing the formating of the URL bar, since I
> believe the domain name is simply more important than the rest of the
> information, and for the vast majority of users, the domain name is the
> only understandable piece of the URL.
>
> However, I don't think this will have any effect of protecting users
> from phishing attacks.
I think it will have an effect, but I don't think it will solve the
problem alone. But then, no single measure will.
>> sign.travelocity.com.zaga-zaga.us must be an
>> outsourcing site for travelocity.com.
Given the existence of CNAMEs, sites should be discouraged from this
sort of idiocy.
>> Sometimes the company [Target] has to register a
>> different name [www.mytargets.com] from its brand.
>>
>> What if target.com has already been taken by another
>> company?
-> EV certificates and identity :-)
> So, even if we go nuts and color code every part of the URL, AND
> magically everyone understands the color coding, people are still going
> to rationalize.
Right. But if you say we can't help the people who rationalise, then
let's help the people who don't.
Gerv
Michael Lefevre
> Michael Lefevre wrote:
[snip]
>> On the other hand, I guess it won't be too hard to remove the greying-out
>> effect with an addon (or maybe even a couple of lines in the chrome CSS
>> file), for those people that understand URLs and want to read them all the
>> time.
>
> Indeed. There will probably be a pref.
I didn't mention the possibility of adding a pref, as I thought that might
provoke some kind of mob/torch/pitchfork thing...
--
Michael
raven.o...@gmail.com
anything in my address bar. You can kill the favicons and most people
wouldn't care - except for those of us who use the favicon with a
blank bookmark name to de-clutter our bookmark toolbars - but please,
please, if you must screw with the address bar, please give me a way
to turn it off!
Peter Lairo
Well, you would be removing it for the above important usage case for
the vast majority of users who don't have tabs visible.
I just don't think the cost (loss of favicon near URL) outweighs the
benefit (fake lock as favicon). I've *never* seen such an attempt, and I
doubt people who fall for phishing sites would even notice whether a
fake lock where there or not.
--
Regards,
Peter Lairo
Lame attempt to get rich: http://www.lairo.com/donations.html
pcab...@gmail.com
> I just don't think the cost (loss of favicon near URL) outweighs the
> benefit (fake lock as favicon). I've *never* seen such an attempt, and I
> doubt people who fall for phishing sites would even notice whether a
> fake lock where there or not.
I haven't followed the entire discussion (which spans many more
threads than this one) but I understand the point is not only the
padlock favicon which is just a case. The main point is that users may
feel they are where they want to be just by looking at the favicon.
The idea is to drive users attention to the URL and base their
decision on it instead of the favicon.
Users may even feel that since the favicon is outside of the actual
content area, it may be some kind of Firefox confirmation,consent or
whatever.
Concerns:
- users may not have a way to drag the favicon for bookmarking,
shortcutting or whatever. According to Alex's mockups there will be a
dedicated button for this and tagging. I know it's no decision so far,
but
- the favicon is part of the design. Certainly. But how much of the
design can be lost because of 256px2? The actual loss is the sense
that "my site" is integrated with "your browser". Which is precisely
what we're trying to break. 1024x600px2 is not enough for branding and
design?
What I don't understand is why keep the favicon in the tab? Isn't it
the same problem? I guess the rationale is that not may users use
tabs. Do we have any numbers? I wouldn't think they are so few.
I for sure would miss the favicon, and if (hopefully) there is a
preference to put it back I'll certainly use it. I guess it's just
another time power users should give it up for the normal ingenuous
users. A "greatest good" kind of thing. Just like with other default
settings: hidden tab bar, FAYT activated with / and the home button to
name a few.
Robert Kaiser
> Robert Kaiser wrote:
>> To me, this sounds of resolving drivers not understanding street signs
>> and traffic rules by abolishing cars instead of requiring people to
>> get a drivers license.
>
> I don't think that analogy holds. A better analogy would be resolving
> drivers not understanding traffic rules by engineering the cars to know
> how not to crash into each other, so they don't have to learn.
No, as crashes are only an edge case. You propose to make cars drive by
themselves without needing a steering wheel, breaks or whatever else,
and that's not only utopic but also impossible, IMHO.
> Is understanding a URL vital to being able to browse the web today?
Actuall,y I strongly believe it is.
> So either we can teach
> people to understand URLs (a very difficult task) or we can work to
> eliminate the risk.
1) I think more people understand the basics of URLs than you seem to
believe.
2) I think we never can really eliminate the risk.
Robert Kaiser
Robert Kaiser
> Alex Faaborg wrote:
>> To quote a statement beltzner made earlier today: "if the problem is a
>> 16x16 pixel favicon can look like our 16x16 pixel security indicator,
>> why don't we change the security indicator?" I completely agree, and
>> I think Johnathan is working on some new security UI mockups.
>
> That's not the only problem. As I just wrote in another post, it's about
> whether the URL bar is trusted UI or not. The current situation, where
> some bits are trusted and some aren't, is bad. We need to go one way or
> the other.
OK, then remove the URL, as this is probably the most untrusted element
of them all. Oh, and remove the page title from the window title and
task bar, as those are OS elements and even more trusted than a mere
browser.
I think you rationale must lead there, if we fully go with it - I'm not
convinced this is right, though.
IMHO, many users don't trust the UI more than the page content (which is
why phishing works on them, regardless what the location bar is
displaying), and the vast majority does know that the favicon comes with
the page and is connected with the URL next to it, and quite a lot of
users know that any indicator from the browser would be shown at the
right of the location bar, not at the left.
> Right. But if you say we can't help the people who rationalise, then
> let's help the people who don't.
People who don't rationalize do not exist IMHO. Some might rationalize
in a wrong way, and we should help them to the right way to do it. But
everyone will draw his or her conclusions from what (s)he sees in the
browser (UI or content), and think about it in one way or the other.
The only thing we can do is to help them draw the right conclusions.
Robert Kaiser
Robert Kaiser
> The idea is not about being in-your-face with it, the point is that
> currently users don't understand how to parse URLs. Which is the
> relevant domain in the following?
>
> www.microsoft.com.foo.com/bankofamerica.com?ibm.com=google.com#sun.com
>
> You might know, but most people don't. The highlighting is a massive
> parsing hint.
Right. Guiding users to understand the URL and/or the UI is a very good
thing. Helping to educate users is the way we should go.
Oh, and giving advanced users, who are educated, a chance to learn even
more and/or giving them the possibility to customize the hints (e.g.
turning off that highlighting as they know they don't need it any more)
Robert Kaiser
MikeIL
Gervase Markham
> No, as crashes are only an edge case. You propose to make cars drive by
> themselves without needing a steering wheel, breaks or whatever else,
> and that's not only utopic but also impossible, IMHO.
In the car world, it's entirely possible. The only difficulty is having
such cars co-exist on roads with other cars that don't have the technology.
But we're off topic, because there are no network effects here. My
understanding (or lack of it) of URLs does not affect you.
>> Is understanding a URL vital to being able to browse the web today?
>
> Actuall,y I strongly believe it is.
There are hundreds of millions of people out there who manage just fine
without, so I think you are wrong.
> 1) I think more people understand the basics of URLs than you seem to
> believe.
> 2) I think we never can really eliminate the risk.
OK, you give up. We'll keep working :-)
Gerv
Gervase Markham
> I didn't mention the possibility of adding a pref, as I thought that might
> provoke some kind of mob/torch/pitchfork thing...
I should have been clear. I meant a hidden pref.
Gerv
Gervase Markham
> OK, then remove the URL, as this is probably the most untrusted element
> of them all.
In a sense, we are. We are greying out the parts the attacker has most
control over, and thereby highlighting the bit which gives clear
confirmation of your current location, and which attackers can't spoof.
> IMHO, many users don't trust the UI more than the page content (which is
> why phishing works on them, regardless what the location bar is
> displaying),
Phishing works because either users don't look at the location bar, or
don't understand it. (Because if they looked at it and understood it,
they wouldn't get phished.) Why do they not look at it? One reason is
that they never have understood it, so they've stopped even looking -
i.e. it's partly the same problem. Making it easier to understand will
help reverse that.
Also, of course, some people don't look because they just trust what the
website says blindly. Helping those people is more difficult. Hopefully,
Larry the Passport Guy will help.
Gerv
Robert Kaiser
>> 1) I think more people understand the basics of URLs than you seem to
>> believe.
>> 2) I think we never can really eliminate the risk.
>
> OK, you give up. We'll keep working :-)
I don't give up - we surely can reduce the risk, and that's definately
something to look into. We just can't completely eliminate it, IMHO.
Robert Kaiser
Michael Lefevre
I guess you may not have been clear, but I did understand you to mean a
hidden pref. People also have objections to those... untested code paths
and stuff. :)
Anyway, as long as there is some way of turning off the new behaviour,
that should make the people who don't like it happier (even if not
entirely happy). I know that lots of people don't understand URLs, and I
can see that the change would make sense for them. I may well turn it off
myself though (or not, depending how unreadable the dimmed part is).
--
Michael
Alex Dahl
> we now propose that we do the following two things as a start
> 1) Remove the favicon from the URL bar
I actually agree with #1, but it seems like a lot of people don't. I'd
have the icon in its place vary depending on the circumstances:
http://img510.imageshack.us/img510/4404/locbariconsll6.jpg - but this
is radical (especially moving the throbber), so feel free to ignore
this suggestion.
For #2, I think emphasizing the domain name is a great idea. The issue
is how to emphasize it: legibility is very important. As such, I don't
like greying out everything else, and I understand that bold text is
hard to read. Putting a color behind it can introduce contrast
problems, so the next step is to change the domain name text to light-
on-dark - something like this: http://img264.imageshack.us/img264/8396/domainhighlightpg6.jpg
(I've also added some spacing around the domain name). Because this is
quite attention getting, perhaps the highlighting should only appear
for secure sites*, or have an option to that effect. Finally, I have
no idea how technically feasible this kind of highlighting is.
* Rationale for only using highlighting for secure sites is that users
(hopefully) have learned not to trust insecure sites, so the remaining
issue is confirming that they trust the secure site they are at.
Dão
> Michael Lefevre wrote:
>> On the other hand, I guess it won't be too hard to remove the greying-out
>> effect with an addon (or maybe even a couple of lines in the chrome CSS
>> file), for those people that understand URLs and want to read them all
>> the
>> time.
>
> Indeed. There will probably be a pref.
I'm against a pref. I want the formatted view to be themeable, so
userChrome.css would be the obvious choice for customizations (should be
a single rule in this case).
Dao
Dão
> 2. using a grey font color in the address bar is a HUGE accessibility
> and readability issue...
We're using the native graytext color. If that's unreadable, the
corresponding OS theme might have issues.
Dao
Tony Mechelynck
At least two rules would have to apply, since the highlighted part and the
"lowlighted" part would, I expect, belong to different classes. And maybe a
third one for #urlbar.
Best regards,
Tony.
--
"I just need enough to tide me over until I need more."
-- Bill Hoest
Dão
> However, I don't think this will have any effect of protecting users
> from phishing attacks. Consider this study done at MIT:
>
>> (60%) used rationalizations to justify the
>> indicators of the attacks that they experienced. Nine
>> subjects explained away odd URLs with comments like:
>>
>> www.ssl-yahoo.com is a subdirectory of Yahoo!, like
>> mail.yahoo.com.
Well, highlighting yahoo.com (i.e. not "mail.") solves that
theoretically. At least it affords the opportunity to say that the
highlighted part should be yahoo.com and absolutely nothing but
yahoo.com -- without requiring users to parse host names or even entire
addresses mentally. But it's still likely that that users who don't get
the message think ssl-yahoo.com is legitimate or just ignore it completely.
It boils down to what Gerv wrote: "I think it will have an effect, but I
don't think it will solve the problem alone. But then, no single measure
will."
Dao
Dão
> Dão wrote:
>> Gervase Markham schrieb:
>>> Michael Lefevre wrote:
>>>> On the other hand, I guess it won't be too hard to remove the
>>>> greying-out
>>>> effect with an addon (or maybe even a couple of lines in the chrome CSS
>>>> file), for those people that understand URLs and want to read them
>>>> all the
>>>> time.
>>>
>>> Indeed. There will probably be a pref.
>>
>> I'm against a pref. I want the formatted view to be themeable, so
>> userChrome.css would be the obvious choice for customizations (should
>> be a single rule in this case).
>>
>> Dao
>
> At least two rules would have to apply, since the highlighted part and
> the "lowlighted" part would, I expect, belong to different classes. And
> maybe a third one for #urlbar.
Something like this should work:
#urlbar .textbox-presentation-segment > * {
color: inherit !important;
}
I wonder if "presentation" is the right choice for the class name ...
maybe "textbox-formatted-segment" would be better/clearer.
Dao
Greg Campbell
> People, the proposal removes favicons from the location bar, but not
> from the browser tabs. There you will see them in full glory.
Then I also assume the default for "Always show the tab bar" be changed
to "true"? Or the setting changed to true and the pref removed altogeher
(only a hidden pref)?
Considering the default UI doesn't even include the "Add Tab" button, I
imagine there are lots of users who never use tabs at all. (Please,
please put the "add tab" button in the default UI. Put it to the right
of the search bar--easy to hit with windows maximized.)
Greg
Tony Mechelynck
You could use
/*
* Disable highlighting of URL segments
*/
#urlbar *
{ font: inherit !important
; color: inherit !important
; background: inherit !important
}
but not if you wanted to _change_ the way it was highlighted. Then you might need:
/*
* Give the URL bar a fixed font, and highlight its parts
* by color and underline, not background or font-weight
*/
#urlbar
{ font-family: monospace !important
}
#urlbar *.url-highlight
{ font: inherit !important
; color: #600 !important
; text-decoration: underline !important
; background-color: white !important
}
#urlbar *.url-lowlight
{ font: inherit !important
; color: #666 !important
; background-color: white !important
}
(the classes are of course imaginary at this stage), which makes three rules.
Best regards,
Tony.
--
If all the world's economists were laid end to end, we wouldn't reach a
conclusion.
-- William Baumol
Gervase Markham
> hard to read. Putting a color behind it can introduce contrast
> problems, so the next step is to change the domain name text to light-
> on-dark - something like this: http://img264.imageshack.us/img264/8396/domainhighlightpg6.jpg
Interesting idea. But how would it interact with attempts to select
text? I can see this getting confusing, because the user might think
there was a selection when there wasn't.
> * Rationale for only using highlighting for secure sites is that users
> (hopefully) have learned not to trust insecure sites, so the remaining
> issue is confirming that they trust the secure site they are at.
We want to make the domain more prominent for all sites.
Gerv
Alex Faaborg
the URL has been preventing phishing attacks, and helping novice
users correctly parse the URL. There seems to be an implicit
assumption that this change doesn't help advanced users, people who
already know what "effective TLD" means. However, I believe this
change improves the overall usability of the location bar, even for
advanced users.
First, a quick description of the human visual system: we have a very
high resolution fovea, and low resollution peripheral vision. Our
fovea takes up 1-2% of our visual field (if our peripheral vision had
the same resolution as the fovea, an eyeball would be about the same
size as a human head). To view particular areas of the screen, our
eyes make very fast movements (called saccades) to direct the high
resolution fovea to different targets that we acquire using our low
resolution peripheral vision.
Here is why I think this change to the location bar will help
advanced users:
1) The vast majority of time people look at the location bar they are
doing so to read the domain name. Now, of course I know this
percentage probably goes down a bit for very advanced users (who
might be trying to view the protocol in certain cases, or the port,
etc.) But it's still the case that advanced users regularly look at
the location bar to see the domain name.
2) By providing contrast for the public suffix +2, users will be
able to read this information with a single saccade to the center of
the darker text. Without the visual change, our eyes will make a
saccade to the start of the URL, and then will jump back and forth
inside the location bar, identifying the relevant parts of the URL.
It's too bad we don't have an eye tracking system set up, because
then we could get some real data on the average number of saccades it
currently takes to parse a URL. But either way, I believe this
change to the location bar is going to decrease both the number of
eye movements, and the time it takes the user to figure out which
domain they are on, regardless of how technical they are.
We are talking about milliseconds, and this isn't the kind of thing
the user will be consciously aware of. But these types of
improvements to (human) performance make a difference.
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Myk Melez
> 1) The vast majority of time people look at the location bar they are
> doing so to read the domain name. Now, of course I know this percentage
> probably goes down a bit for very advanced users (who might be trying to
> view the protocol in certain cases, or the port, etc.) But it's still
> the case that advanced users regularly look at the location bar to see
> the domain name.
This seems like a reasonable assumption.
> We are talking about milliseconds, and this isn't the kind of thing the
> user will be consciously aware of. But these types of improvements to
> (human) performance make a difference.
Indeed, especially when considered in context of the very large set of
such improvements that are possible in Firefox. Taken individually,
each one is insignificant, but their cumulative effect is not, so it's
valuable to optimize even these minor interactions, especially those
that occur frequently, as this one does.
-myk
Axel Hecht
stuff.
I stopped after a few minutes, after my head started aching. As it is
currently implemented, the location bar disables parts of the URL, and
for those sites that I was visiting (lxr, news.bbc.co.uk, mdc, wikimo),
there is valid information in the non-site parts.
Disabled text in the location bar is terribly hard to read at all, that
is, it takes an mental effort, and in my case, a change in distance to
the monitor to do.
That's not an option for me, so I closed Minefield. More below.
Alex Faaborg wrote:
> Previously in this thread the main arguments for greying out parts of
> the URL has been preventing phishing attacks, and helping novice users
> correctly parse the URL. There seems to be an implicit assumption that
> this change doesn't help advanced users, people who already know what
> "effective TLD" means. However, I believe this change improves the
> overall usability of the location bar, even for advanced users.
>
> First, a quick description of the human visual system: we have a very
> high resolution fovea, and low resollution peripheral vision. Our fovea
> takes up 1-2% of our visual field (if our peripheral vision had the same
> resolution as the fovea, an eyeball would be about the same size as a
> human head). To view particular areas of the screen, our eyes make very
> fast movements (called saccades) to direct the high resolution fovea to
> different targets that we acquire using our low resolution peripheral
> vision.
>
> Here is why I think this change to the location bar will help advanced
> users:
>
> 1) The vast majority of time people look at the location bar they are
> doing so to read the domain name. Now, of course I know this percentage
> probably goes down a bit for very advanced users (who might be trying to
> view the protocol in certain cases, or the port, etc.) But it's still
> the case that advanced users regularly look at the location bar to see
> the domain name.
I really rarely ever do. If I'm not sure where I'm going, I check the
status bar before clicking on a link, I try very hard to not visit URLs
without knowing the site before I click.
> 2) By providing contrast for the public suffix +2, users will be able
> to read this information with a single saccade to the center of the
> darker text. Without the visual change, our eyes will make a saccade to
> the start of the URL, and then will jump back and forth inside the
> location bar, identifying the relevant parts of the URL.
>
> It's too bad we don't have an eye tracking system set up, because then
> we could get some real data on the average number of saccades it
> currently takes to parse a URL. But either way, I believe this change
> to the location bar is going to decrease both the number of eye
> movements, and the time it takes the user to figure out which domain
> they are on, regardless of how technical they are.
>
> We are talking about milliseconds, and this isn't the kind of thing the
> user will be consciously aware of. But these types of improvements to
> (human) performance make a difference.
To me, reading the non-domain part requires physical and mental work and
is a nono.
I really don't think this should be on as it is. I at least can't
recommend it as such, not even for something like "give it a try for a
while". Again, it made my head hurt, physically. That's not good.
Axel
sjwh...@gmail.com
> I stopped after a few minutes, after my head started aching. As it is
> currently implemented, the location bar disables parts of the URL, and
> for those sites that I was visiting (lxr, news.bbc.co.uk, mdc, wikimo),
> there is valid information in the non-site parts.
>
> Disabled text in the location bar is terribly hard to read at all, that
> is, it takes an mental effort, and in my case, a change in distance to
> the monitor to do.
>
> That's not an option for me, so I closed Minefield. More below.
>
>
+1
It's impossible to read at the distance I'm most comfortable at and I
still don't understand how this change is beneficial at all. URL paths
these days are becoming more, not less readable (Digg for example) -
there's even a new "friendly url" movement in web development
community because designers are learning from experience that simple,
user-friendly URLs result in more navigable sites and more return
visits - so to say users don't care about the path is more or less
unfounded, IMO.
I've also heard that this is has a measurable performance impact
(nearly as much as the new theme had last year) and that the current
stance is that it's acceptable. I'm not sure how fancy font color
changes result in a regression in performance, but that really doesn't
sit well with me - where's it going to end? Is it going to require
that Firefox take noticeably longer to load and open new windows
before regressions in performance are no longer acceptable?
Even with an option to turn this off, it's still nothing you want to
expose users to by default. Please just get rid of it, Mr. Hecht's
head and my own will thank you!
- Scott W.
Tony Mechelynck
> I just tried Minefield in WinXP, as I wanted to look at Neil's <panel>
> stuff.
>
> I stopped after a few minutes, after my head started aching. As it is
> currently implemented, the location bar disables parts of the URL, and
> for those sites that I was visiting (lxr, news.bbc.co.uk, mdc, wikimo),
> there is valid information in the non-site parts.
>
> Disabled text in the location bar is terribly hard to read at all, that
> is, it takes an mental effort, and in my case, a change in distance to
> the monitor to do.
>
> That's not an option for me, so I closed Minefield. More below.
I agree that the "deemphasized" color chosen is much, *much* too light, almost
undistinguishable from the white background; but rather than junk Minefield I
changed its userChrome.css as follows (quoting the relevant part):
/*
* This file can be used to customize the look of Mozilla's user interface
* You should consider using !important on rules which you want to
* override default settings.
*/
/*
* For more examples see http://www.mozilla.org/unix/customizing.html
*/
/*
* Do not remove the following line, it is required for correct functioning
*/
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
/****************************************************************
* FONTS *
****************************************************************/
/*
* Give the Location (URL) Bar a fixed-width font
* and disable deemphasising of its parts
*/
#urlbar
{ font-family: "Andale Sans Mono"
, "B&H LucidaTypewriter"
, "Courier New"
, Courier
, monospace !important
; font-size: 8pt !important
; color: black !important
}
#urlbar *
{ color: black !important
}
Best regards,
Tony.
--
"What I think is that the F-word is basically just a convenient nasty-
sounding word that we tend to use when we would really like to come up
with a terrifically witty insult, the kind Winston Churchill always
came up with when enormous women asked him stupid questions at
parties.
-- Dave Barry, "$#$%#^%!^%&@%@!"
Mike Beltzner
experiment, and it's good to get feedback, so while the experiment's
result might well be "yeah, that doesn't work, let's pull it out" I
think the fact that we're playing with our sacred cows (now *that* is
a mixed metaphor!) is pretty great.
OK, back to your regularly scheduled feedback!
cheers,
mike
Tony Mechelynck
> Just as a meta-comment, we knew that this was going to be an experiment,
> and it's good to get feedback, so while the experiment's result might
> well be "yeah, that doesn't work, let's pull it out" I think the fact
> that we're playing with our sacred cows (now *that* is a mixed
> metaphor!) is pretty great.
>
> OK, back to your regularly scheduled feedback!
>
> cheers,
> mike
IMO the problem is the too-little contrast between the deemphasised text and
the background. If some _dark_ grey color such as #333 or #666 had been chosen
(instead of whichever almost-white grey was actually chosen), IMHO it would
have been much more acceptable.
Best regards,
Tony.
--
Schlattwhapper, n.:
The window shade that allows itself to be pulled down,
hesitates for a second, then snaps up in your face.
-- Rich Hall, "Sniglets"
Mike Beltzner
> Mike Beltzner wrote:
>> Just as a meta-comment, we knew that this was going to be an
>> experiment,
>> and it's good to get feedback, so while the experiment's result might
>> well be "yeah, that doesn't work, let's pull it out" I think the fact
>> that we're playing with our sacred cows (now *that* is a mixed
>> metaphor!) is pretty great.
>>
>> OK, back to your regularly scheduled feedback!
>>
>> cheers,
>> mike
>
> IMO the problem is the too-little contrast between the deemphasised
> text and
> the background. If some _dark_ grey color such as #333 or #666 had
> been chosen
> (instead of whichever almost-white grey was actually chosen), IMHO
> it would
> have been much more acceptable.
Cool. Posting your userChrome.css hack is great, too, as it allows
people to play around with it.
cheers,
mike
pcab...@gmail.com
several previous long threads, but I would like to ask for the
reasoning for discarding other options for highlighting the domain
like:
- bold text
- bold text with fixed width fonts
- reverse background and text colors
- larger font
- different color
Some I know others not very sure but I think it would help to, once
again, recapitulate what has been tried. I guess there are other
options but hopefully these will bring up most considerations.
Thanks.
Percy
On Jul 6, 3:48 pm, Tony Mechelynck <antoine.mechely...@belgacom.net>
wrote:
Tony Mechelynck
Note that I didn't bother to find out the appropriate selectors for the
"parts" of the URL text, since "#urlbar *" is good enough to force everything
back to black. People wanting to change the shade of grey can do so easily
with the help of the DOM Inspector component.
Best regards,
Tony.
--
"One thing they don't tell you about doing experimental physics is that
sometimes you must work under adverse conditions ... like a state of
sheer terror."
-- W. K. Hartmann
Mike Beltzner
> I am somewhat sorry to ask this as I know it was largely discussed in
> several previous long threads, but I would like to ask for the
> reasoning for discarding other options for highlighting the domain
> like:
>
> - bold text
This one was tried back in an earlier version of the extension, and I
liked it, but it ended up blurring some letters and taking undue
focus away from the rest of the toolbar UI, tabstrip UI, etc. It was
almost over-emphasizing the domain name.
> - bold text with fixed width fonts
Mostly because fixed width fonts are pretty ugly and end up looking
broken when next to all the smoothed-edge goodness of scalable fonts.
> - reverse background and text colors
Text colours were played with, you get into some colour-blindness
issues here, though, and again, it causes almost too much emphasis.
Reverse background is pretty out of the question, because we didn't
want to cause ocular bleeding ;)
> - larger font
> - different color
>
> Some I know others not very sure but I think it would help to, once
> again, recapitulate what has been tried. I guess there are other
> options but hopefully these will bring up most considerations.
There were a lot of variables being played with (and that can still
be played with by installing Dao's previous LocationBar^2
extensions), and then Ka-Ping Yee suggested simplifying and starting
from there.
To be honest, I think some of the more interesting experimentations
had less to do with colours and fonts, and more to do with spacing
the URI out like so:
www.wherever.com /somedir/somepath/somefile.html
cheers,
mike
Michael Lefevre
[snip]
>
> Disabled text in the location bar is terribly hard to read at all, that
> is, it takes an mental effort, and in my case, a change in distance to
> the monitor to do.
Well, from the previous discussion, being hard to read is the idea. Your
reaction is not supposed to be to try and read it anyway - you're either
supposed to ignore it, or take some action to make it readable (e.g. hover
over the URL or turn the feature off).
I guess the question is whether a lot of users will think their browser is
a bit broken and strain at trying to read something unreadable, instead of
doing what the design of this feature intends them to do. Maybe the text
could be made completely unreadable with some other indication that there
is more "underneath" - a ... indication or something?
It may be because I haven't followed the discussion, but I thought the
plan was to highlight the domain rather than the whole host name?
Currently if I visit www.microsoft.com.evil.co.uk it seems like the whole
thing will be highlighted?
--
Michael
Gavin Sharp
> It may be because I haven't followed the discussion, but I thought the
> plan was to highlight the domain rather than the whole host name?
> Currently if I visit www.microsoft.com.evil.co.uk it seems like the whole
> thing will be highlighted?
That's bug 386727.
Gavin
Tony Mechelynck
De-emphasizing the protocol and subdirectories is one thing, making them
almost invisible is another. The "deemphasized" text was such a pale shade of
grey that it made me take steps to force it to black via userChrome.css --
which defeats it totally. If, instead of #EEE or whatever, it had been some
"dark" shade of grey like #333 or #666 -- distinct from the black of the
domain but still readable -- I might have left it alone.
As for hovering the mouse over the Location Bar to re-emphasize the whole URL,
IMHO it is just as "undiscoverable" as the ill-famed throbber link used to be.
Best regards,
Tony.
--
One Page Principle:
A specification that will not fit on one page of 8.5x11 inch
paper cannot be understood.
-- Mark Ardis
Jesper Kristensen
#urlbar .textbox-presentation-protocol {
color: white !important;
/* display: none; */
}
#urlbar .textbox-presentation-subdomain,
#urlbar .textbox-presentation-port,
#urlbar .textbox-presentation-path,
#urlbar .textbox-overflow-ellipsis {
color: black !important;
}
#urlbar .textbox-presentation-domain {
color: white !important;
background: black !important;
/* margin: 0 1em !important; */
}
Axel Hecht skrev:
Tony Mechelynck
> If someone wants to play with colors, here is some code for userChrome.css:
>
> #urlbar .textbox-presentation-protocol {
> color: white !important;
> /* display: none; */
> }
hides the protocol completely, so you don't know ftp from http from https...
Is that very wise?
>
> #urlbar .textbox-presentation-subdomain,
> #urlbar .textbox-presentation-port,
> #urlbar .textbox-presentation-path,
> #urlbar .textbox-overflow-ellipsis {
> color: black !important;
> }
>
> #urlbar .textbox-presentation-domain {
> color: white !important;
> background: black !important;
> /* margin: 0 1em !important; */
> }
reverse-video for the domain
[...]
OK, let me suggest something else:
#urlbar *
{ color: #666 !important /* 40% grey */
}
#urlbar .textbox-presentation-domain /* keep domain black always */
{ color: black !important
}
#urlbar .textbox-input-box, /* re-emphasise when focused */
#urlbar *:hover /* or at mouseover */
{ color: black !important
}
This takes advantage of the fact that when two (or more) conflicting rules
apply to a single element, and they both have !important, the last rule wins.
The pale-yellow, etc., backgrounds used by default for some "secure" sites are
still shown.
One problem: On URLs starting with "file:///" or "about:" everything is greyed
out. On chrome URLs only the top-level "folder" is in black (e.g. "mozapps" in
chrome://mozapps/content/extensions/extensions.xul , the addons manager when
shown in a tab)
I tried the Moz-proprietary at-rule @-moz-document url-prefix() {} but it
didn't work. I guess it doesn't apply to the browser chrome.
Try it out guys, other suggestions welcome.
Best regards,
Tony.
--
"Calvin Coolidge looks as if he had been weaned on a pickle."
-- Alice Roosevelt Longworth
Jesper Kristensen
== Who are we trying to help? ==
Users that doesn't understand URLs at all?
- They probably wouldn't look at the location bar at all, so this is no help
to them.
Users that understand a little about URLs?
- They are the ones we can really help. They try to parse the URL, but may
get it wrong. Styling the URL makes it easier for them to get it right.
Power users?
- By color coding the URL, these users may be able to parse the URL faster.
== Do we need to emphasize the domain, or do we just need to make the
different parts of the URL destinct? ==
- The users we are trying to help already know a little about the URL. I
don't think the domain part should be more visible than the other parts, the
different parts would just have to look different to aid in parsing.
Maybe (userChrome.css):
#urlbar .textbox-presentation-protocol { color: gray !important; }
#urlbar .textbox-presentation-subdomain { color: red !important; }
#urlbar .textbox-presentation-domain { color: green !important; }
#urlbar .textbox-presentation-port { color: red !important; }
#urlbar .textbox-presentation-path { color: blue !important; }
#urlbar .textbox-overflow-ellipsis { color: black !important; }
If emphasizing the domain is important, it can be done in many ways:
#urlbar * { color: black !important; }
#urlbar .textbox-presentation-domain { border-bottom: 1px solid red; }
or
#urlbar * { color: black !important; }
#urlbar .textbox-presentation-domain { background: yellow; }
or
#urlbar * { color: black !important; }
#urlbar .textbox-presentation-domain { color: red !important; }
or something else.
I like the red underline the most. It emphasizes the domain, it doesn't cause
too much visual disturbance on hover, it doesn't make the url harder to read,
is is not easily confused with other things (e.g. a black or blue underline
would be easy to confuse with a link).
Axel Hecht
> On 2007-07-06, Axel Hecht <ax...@pike.org> wrote:
> [snip]
>> Disabled text in the location bar is terribly hard to read at all, that
>> is, it takes an mental effort, and in my case, a change in distance to
>> the monitor to do.
>
> Well, from the previous discussion, being hard to read is the idea. Your
> reaction is not supposed to be to try and read it anyway - you're either
> supposed to ignore it, or take some action to make it readable (e.g. hover
> over the URL or turn the feature off).
>
> I guess the question is whether a lot of users will think their browser is
> a bit broken and strain at trying to read something unreadable, instead of
> doing what the design of this feature intends them to do. Maybe the text
> could be made completely unreadable with some other indication that there
> is more "underneath" - a ... indication or something?
I don't have the time to read the original thread, sadly. Anyway, if the
intent of the location bar was to remove URLs from the browser, then it
fails to do so. If it wasn't, it's doing something else that's non-good.
I'm not sure why we're thinking about emphasizing domains, anyway.
They're just as open to spoofing as the rest of the URL. If we worry
about identity here, that's Larry's job, not the job of the location bar.
Axel, who's not sure on whether to laugh or cry hearing arguments like
"oh, we used light grey because color is bad for color blind people".
Robert Sayre
>
> I'm not sure why we're thinking about emphasizing domains, anyway.
> They're just as open to spoofing as the rest of the URL.
Fully agree.
> If we worry
> about identity here, that's Larry's job, not the job of the location bar.
I'm not sure why we think chrome UI is going to help. Only a quarter of
users even parse the padlock correctly.
<http://people.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf>
I think we're spending time on UI that will degrade the user experience
when visiting legitimate websites by adding cruft to the location bar.
We're also increasing "secure" indicators when there has been no
corresponding strengthening of security mechanisms.
Phishing websites will just start using Larry and our CA Cert display in
content. Unsophisticated users will fall for that, so good enough.
- Rob
Adam Kowalczyk
> I don't have the time to read the original thread, sadly. Anyway, if the
> intent of the location bar was to remove URLs from the browser, then it
> fails to do so. If it wasn't, it's doing something else that's non-good.
>
> I'm not sure why we're thinking about emphasizing domains, anyway.
As far as I understand, spoofing was only one of the reasons. The other
was readability. URLs are fundamentally not very user-friendly and we
want to make them easier to parse by distinguishing different parts of
them. Domain is by far the most important and most commonly understood
part - it is "the name of the site" you are on.
Let's look at it this way. What meaning does an URL convey? The type of
the connection (HTTP is plain, HTTPS is secure), the address of the
website (domain) and the specific page you are on. OK, it's all good and
useful. But what sort of idea is to deliver this information using a
long, cryptic string with some interjected colons and slashes?! We learn
to live with it but the bottom line is: it's a bad user experience. It's
too technical and it should (and hopefully can) be improved.
- Adam
Gervase Markham
> I stopped after a few minutes, after my head started aching. As it is
> currently implemented, the location bar disables parts of the URL, and
> for those sites that I was visiting (lxr, news.bbc.co.uk, mdc, wikimo),
> there is valid information in the non-site parts.
Could you be more specific about which parts of which URLs you wanted to
read?
Gerv
Gervase Markham
> Axel Hecht wrote:
>>
>> I'm not sure why we're thinking about emphasizing domains, anyway.
>> They're just as open to spoofing as the rest of the URL.
>
> Fully agree.
I really don't think that's right. Only one website (DNS spoofing aside)
can be at www.paypal.com, and that's Paypal. (Now if it's possible for
another domain to look very like paypal.com but not be it, that's a
problem we need to fix regardless of this feature.)
By contrast, all the other parts of the URL are completely under the
control of the site.
>> If we worry about identity here, that's Larry's job, not the job of
>> the location bar.
>
> I'm not sure why we think chrome UI is going to help. Only a quarter of
> users even parse the padlock correctly.
>
> <http://people.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf>
I'm sure this paper and others like it have been taken into account in
Larry's design.
> I think we're spending time on UI that will degrade the user experience
> when visiting legitimate websites by adding cruft to the location bar.
> We're also increasing "secure" indicators when there has been no
> corresponding strengthening of security mechanisms.
The highlighting of the domain name says nothing about security. It's an
identity indicator.
> Phishing websites will just start using Larry and our CA Cert display in
> content. Unsophisticated users will fall for that, so good enough.
They won't be able to fake it exactly, as Larry's box overlaps content
and chrome.
But, let's say you are right, and there is no UI we can use that will
improve the situation. What's your plan?
Gerv
Gervase Markham
> == Who are we trying to help? ==
>
> Users that doesn't understand URLs at all?
> - They probably wouldn't look at the location bar at all, so this is no
> help to them.
There are almost no users in this category as you have defined it.
Almost everyone who has ever used the web has typed in "www.foo.com",
for some value of foo. They might have got the URL off the side of the
bus, or off a cereal box or advertisement.
This change to the URL bar means that they don't need any more knowledge
than they have already to understand what it's telling them.
> Users that understand a little about URLs?
> - They are the ones we can really help. They try to parse the URL, but
> may get it wrong. Styling the URL makes it easier for them to get it right.
I think the number of users who parse URLs in this way is also extremely
small, but at the other end of the skill spectrum.
> - The users we are trying to help already know a little about the URL. I
> don't think the domain part should be more visible than the other parts,
> the different parts would just have to look different to aid in parsing.
The more different styles we have, the greater the number of UI elements
and so the greater the visual confusion. If everything is special,
nothing is special.
Gerv
Axel Hecht
Which page I'm on on MDC, and any other wiki for that matter. On bbc,
taking a similar example,
http://news.bbc.co.uk/2/hi/asia-pacific/6290302.stm, 'asia-pacific'
catches my eye on a browser with URLs.
Axel
Robert Sayre
>
>>> If we worry about identity here, that's Larry's job, not the job of
>>> the location bar.
>>
>> I'm not sure why we think chrome UI is going to help. Only a quarter
>> of users even parse the padlock correctly.
>>
>> <http://people.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf>
>
> I'm sure this paper and others like it have been taken into account in
> Larry's design.
I'm not, unless by "taken into account", you mean considered and rejected.
>
>> I think we're spending time on UI that will degrade the user
>> experience when visiting legitimate websites by adding cruft to the
>> location bar. We're also increasing "secure" indicators when there has
>> been no corresponding strengthening of security mechanisms.
>
> The highlighting of the domain name says nothing about security. It's an
> identity indicator.
For me, that is an information-free sentence.
>
>> Phishing websites will just start using Larry and our CA Cert display
>> in content. Unsophisticated users will fall for that, so good enough.
>
> They won't be able to fake it exactly, as Larry's box overlaps content
> and chrome.
Yes, my claim is that will be good enough, just like the little lock gif
my bank puts next their insecure form.
>
> But, let's say you are right, and there is no UI we can use that will
> improve the situation. What's your plan?
I have a lot of ideas, but we don't need to morph the thread into a
discussion of those--my claim is that the proposed UI is actually worse
than what we have now, because it makes the location bar visually noisier.
-Rob
Gervase Markham
> Gervase Markham wrote:
>> The highlighting of the domain name says nothing about security. It's
>> an identity indicator.
>
> For me, that is an information-free sentence.
Maybe that's why there's a disconnect here.
Over the last few months, I have certainly come to realise (and I
believe Jonathan and Mike have too, but I can't speak for them, and I'm
not putting myself first in this list to suggest that I thought of it
first) that we need to be clear about the difference between security
and identity.
Security is about "can my communications by read in transit?"; identity
is about "who am I talking to?". The padlock is a security indicator.
The domain name is an identity indicator.
Phishing is an identity problem, not a security problem. You think you
are talking to person A, but in fact you are talking to person B. The
conversation could be secure or not; it doesn't matter.
The reason we don't like IE's green bar is that it perpetuates this
binary idea of "site good"/"site bad" - like the lock. However, the
important question is "Who am I talking to?", which doesn't have a
Yes/No answer.
Ideally, all secure sites would use EV certificates, allowing us to
present detailed identity information. Until that time, domain names are
the best indicator of identity we have. Hence raising them to greater
prominence, and making it harder to pretend to be a site you are not.
Gerv
Gervase Markham
> Which page I'm on on MDC, and any other wiki for that matter.
Isn't there a big <h1> at the top of the page to tell you that?
> On bbc,
> taking a similar example,
> http://news.bbc.co.uk/2/hi/asia-pacific/6290302.stm, 'asia-pacific'
> catches my eye on a browser with URLs.
"Asia Pacific" is also in the title, and is highlighted in the sidebar.
We are not saying that the non-domain parts of URLs never contain any
useful information, we are saying that any useful information they
contain should be (and almost always is) reflected in the page itself,
which is a much better place to read it.
Gerv
Benjamin Smedberg
What has this got to do with the fact that we're highlighting the domain
name in the location bar for sites with no SSL at all?
In that case, we have no guarantees of identity, and we're highlighting
information that we know may be incorrect or faked.
--BDS
Dão
> Axel, who's not sure on whether to laugh or cry hearing arguments like
> "oh, we used light grey because color is bad for color blind people".
I don't think anybody made such a statement.
The color currently used is 'graytext', by the way.
Dao
Robert Sayre
> Robert Sayre wrote:
>> Gervase Markham wrote:
>>> The highlighting of the domain name says nothing about security. It's
>>> an identity indicator.
>>
>> For me, that is an information-free sentence.
>
> Maybe that's why there's a disconnect here.
...
>
> Phishing is an identity problem, not a security problem.
Fully disagree.
> You think you
> are talking to person A, but in fact you are talking to person B. The
> conversation could be secure or not; it doesn't matter.
>
> The reason we don't like IE's green bar is that it perpetuates this
> binary idea of "site good"/"site bad" - like the lock. However, the
> important question is "Who am I talking to?", which doesn't have a
> Yes/No answer.
I think the important question is "Do I have proof of who I'm talking
to?". We should turn wallet-like on and off based on technical aspects
of HTTP response messages.
Any talisman we stick in chrome will be subverted by phishing sites and
placed content. This works because many users don't understand that
small chrome icons appearing in content have a different provenance.
>
> Ideally, all secure sites would use EV certificates, allowing us to
> present detailed identity information. Until that time...
E.V. certificates don't help with this problem.
I agree that highlighting structural characteristics of the domain name
could help users identify sites if we have reasons to trust that
information. However, I don't think it is an acceptable UI trade-off
because:
1.) It makes the location bar more visually complicated when it's
static. [0]
2.) The highlighted section of the text will move when navigating
between sites. This increases twitchy UI perceptions.
3.) It deemphasizes parts of the URL that could be very important to
the user.
4.) There is no UI precedent. Users aren't going to know what it means.
All that said, I think it was worth trying.
- Rob
[0] http://blog.mozilla.com/faaborg/2007/06/26/quantitative-design/
Axel Hecht
This is running in circles. I could argue that pretty pictures on the
page are a much better indication of identity, as are favicons, and we'd
be back at the discussion on whether the difference in effort to spoof
one or the other is significant or not.
The fact remains, the location bar as it is is a dogfood blocker for me.
If it'd stay that way, I couldn't even fix that for my friends and
family over the phone, and I couldn't recommend the browser. Like, who
could explain userChrome.css over the phone?
Axel
Dão
> OK, let me suggest something else:
>
> #urlbar *
> { color: #666 !important /* 40% grey */
> }
> #urlbar .textbox-presentation-domain /* keep domain black
> always */
> { color: black !important
> }
> #urlbar .textbox-input-box, /* re-emphasise when
> focused */
> #urlbar *:hover /* or at
> mouseover */
> { color: black !important
> }
>
... which means that you're ignoring the OS theme's colors.
> One problem: On URLs starting with "file:///" or "about:" everything is
> greyed out.
That's not true for "about:".
> On chrome URLs only the top-level "folder" is in black (e.g.
> "mozapps" in chrome://mozapps/content/extensions/extensions.xul , the
> addons manager when shown in a tab)
nsIURI says "mozapps" is the host in that case, so that's what is
highlighted.
Is that a problem?
> I tried the Moz-proprietary at-rule @-moz-document url-prefix() {} but
> it didn't work. I guess it doesn't apply to the browser chrome.
|.textbox-presentation-protocol[value="file://"] +
.textbox-presentation-subdomain| should work as a selector.
Dao
Dão
> What has this got to do with the fact that we're highlighting the domain
> name in the location bar for sites with no SSL at all?
Creating a malicious subdomain is trivial, so highlighting the entire
host is indeed worthless (if not dangerous). See bug 386727.
> In that case, we have no guarantees of identity, and we're highlighting
> information that we know may be incorrect or faked.
The information either matches a domain that the user knows well or it
doesn't. Only the user can tell that, and highlighting the relevant part
helps as most users are unable to parse URLs.
Dao
Michael Lefevre
> Axel Hecht wrote:
>> Which page I'm on on MDC, and any other wiki for that matter.
>
> Isn't there a big <h1> at the top of the page to tell you that?
There is, and there's an even bigger heading that says "Mozilla Developer
Center".
>> On bbc,
>> taking a similar example,
>> http://news.bbc.co.uk/2/hi/asia-pacific/6290302.stm, 'asia-pacific'
>> catches my eye on a browser with URLs.
>
> "Asia Pacific" is also in the title, and is highlighted in the sidebar.
The page also has "BBC" in several places, even more obviously than "asia
pacific".
> We are not saying that the non-domain parts of URLs never contain any
> useful information, we are saying that any useful information they
> contain should be (and almost always is) reflected in the page itself,
The same is true of the site's name.
> which is a much better place to read it.
That all depends on the site. Exactly where and how the navigation and/or
title of the current page is displayed varies a lot - the URL tends to
vary less, so I generally find the URL is a better place to read it.
Of course, I (and the other people complaining about the change) are
probably in that minority of people that actually read URLs.
However, if everyone else is looking at the page content rather than the
URL bar, then will they start looking at the domain part of the URL bar to
confirm which site they are on, just because the other parts of the URL
are grey?
And, if they do, will they understand how much they can rely on the black
domain name as opposed to a site with a padlock, and/or be able to compare
either of those to a site with EV?
If someone has to read the release notes, or post a question on a support
forum, or even read through the help docs, in order to understand what is
going on with the grey/black URL text, then the feature isn't helping a
lot of people (maybe even less people than the URL-readers that will be
looking for info on how to edit their userchrome.css file to get rid of
it...)
--
Michael
Tony Mechelynck
OK, but the rest of the URL should IMHO not be lowered to quasi-invisibility.
I have tested 40% grey (#666) thanks to userChrome.css and it makes the
non-domain parts of the URL "greyed out but still readable" which I much
prefer as a default to that very pale grey which was there just before I added
these lines to userChrome.css (I don't know what the latest Minefield nightly
would show if I removed these CSS rules).
Another thing: When on a file: URL I'm talking "to myself"; on an about: or
chrome: URL I'm talking "to my Firefox installation". In these cases there is
no identity problem (and, BTW, no security problem either since these
protocols don't access the Internet at all). But I haven't found how to
recognise these URLs (in order to make them all-black) in userChrome.css.
Best regards,
Tony.
--
Time is nature's way of making sure that everything doesn't happen at
once.
Tony Mechelynck
> Tony Mechelynck schrieb:
>> OK, let me suggest something else:
>>
>> #urlbar *
>> { color: #666 !important /* 40% grey */
>> }
>> #urlbar .textbox-presentation-domain /* keep domain black
>> always */
>> { color: black !important
>> }
>> #urlbar .textbox-input-box, /* re-emphasise when
>> focused */
>> #urlbar *:hover /* or at
>> mouseover */
>> { color: black !important
>> }
>>
>
> ... which means that you're ignoring the OS theme's colors.
>
>> One problem: On URLs starting with "file:///" or "about:" everything
>> is greyed out.
>
> That's not true for "about:".
>
>> On chrome URLs only the top-level "folder" is in black (e.g. "mozapps"
>> in chrome://mozapps/content/extensions/extensions.xul , the addons
>> manager when shown in a tab)
>
> nsIURI says "mozapps" is the host in that case, so that's what is
> highlighted.
> Is that a problem?
For me, yes. The "important parts" (if any) of the URL in this case are
"chrome:" and "extensions.xul", not "mozapps" which is meaningless for me.
>
>> I tried the Moz-proprietary at-rule @-moz-document url-prefix() {} but
>> it didn't work. I guess it doesn't apply to the browser chrome.
>
> |.textbox-presentation-protocol[value="file://"] +
> .textbox-presentation-subdomain| should work as a selector.
>
> Dao
Ah, thanks, I'll play with that next time.
Best regards,
Tony.
--
Cleveland still lives. God _must_ be dead.
Johnathan Nightingale
> Gervase Markham wrote:
>> Phishing is an identity problem, not a security problem.
>
> Fully disagree.
So even though I know what Gerv is getting at here, I think I would
disagree too. "Security" is a pretty big word with pretty big
implications. I know that if we asked most of our users was "Security"
means to them, they would talk about being safe, and not being hacked,
and not having information stolen, and so forth. One of my favourite
numbers from Rachna's _Why Phishing Works_ paper is that basically a
third of her participants weren't even aware that phishing even occurred
or, for that matter, was a *word*. Nevertheless, once informed, I'm
sure they would consider it "security."
Whatever we do to address "security", it certainly doesn't start and end
with the location bar changes (or with Larry, but sayrer was right to
want to avoid digressions, so I will too.)
I *think* Gerv's point was just that, regardless of the debate over the
whole meaning of "security", the location bar change is supposed to help
users assess identity, because even straight identity matters. Yes, DNS
is hardly reliable. Yes there are still homograph attacks and
paypalsecurehooray.com attacks. But I think the bar here is:
Does it do a better job than a vanilla text field?
Helpfully, sayrer addressed that too:
> I agree that highlighting structural characteristics of the domain name
> could help users identify sites if we have reasons to trust that
> information. However, I don't think it is an acceptable UI trade-off
> because:
>
> 1.) It makes the location bar more visually complicated when it's
> static. [0]
>
> 2.) The highlighted section of the text will move when navigating
> between sites. This increases twitchy UI perceptions.
>
> 3.) It deemphasizes parts of the URL that could be very important to
> the user.
>
> 4.) There is no UI precedent. Users aren't going to know what it means.
I would say that all 4 of these points are basically undeniably true.
I come to a different conclusion than sayrer though. I think #1 and #2
are a reasonable price to pay if we feel like the overall effect helps
users understand where they are browsing.
I think #3 and #4 are reasons to keep the other half of this discussion,
where people are comparing colour schemes, text treatments, use of
whitespace, &c going. #4 will be true for any new UI, but that doesn't
mean you can ignore it - it means the design has to be intuitively
clear, or easily learnable, which is somewhere I feel like we can get.
#3 feels solvable too, to me.
> All that said, I think it was worth trying.
+1
Cheers,
J
--
Johnathan Nightingale
Human Shield
Mozilla Corporation
joh...@mozilla.com
Robert Sayre
>
> I come to a different conclusion than sayrer though. I think #1 and #2
> are a reasonable price to pay if we feel like the overall effect helps
> users understand where they are browsing.
>
See, I think it's a total deal breaker, and I feel the same way Axel
does. It might be possible to do something like this in concert with
related simplifications, but there were none. If you keep adding
"helpful indicators", you get a crufty interface that people don't like,
don't use, and don't understand. We are already way past "simple" in our
UI. Try doing things like counting drop-arrows.
- Rob
Greg Campbell
> Jesper Kristensen wrote:
>> == Who are we trying to help? ==
>>
>> Users that doesn't understand URLs at all?
>> - They probably wouldn't look at the location bar at all, so this is
>> no help to them.
>
> There are almost no users in this category as you have defined it.
> Almost everyone who has ever used the web has typed in "www.foo.com",
> for some value of foo. They might have got the URL off the side of the
> bus, or off a cereal box or advertisement.
The users Jesper was describing are the ones who read a URL in an ad,
then type it into the Google search box (which is on their homepage when
they launch "the internet"). They indeed do not use the location bar.
(Evidenced by the number of Google searches for URLs.)
Greg
Axel Hecht
Analyzing my objections a bit, the current implementation doesn't
highlight the domain name. It obfuscates everything else.
That's a bug, and to me, it's dataloss,regression,dogfood.
Axel