657442 - Provide User Option to Change Color-Coded Security Indicators

Status: NEW

(Firefox :: Security, defect)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 SeaMonkey/2.1
Build Identifier: 

For users who are color-blind, a method is needed to set security indicator color codes (e.g., yellow in the address area for a secure Web page) to colors other than the defaults.  While a user interface would be very much desired, a user-settable preference variable is the minimum requirement.  

Reproducible: Always




This is an accessibility issue.  

Note that not all color-blind individuals have trouble distinguishing red and green.  In some cases, the problem involves other color-pairs.  In a few cases everything is white, black, and varying shades of gray.  Thus, this RFE should also allow for textures (e.g., half-tone) in place of color.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I'd think this should be doable via a user stylesheet....

Comment 2

[Johnathan Nightingale [:johnath]]

Yeah - I'd say userChrome or a very simple addon

Comment 3

[Kai Engert (:KaiE:)]

David, is your proposal to make it easier to distinguish current "blue vs. green", or do strive for a three-state "nothing vs. blue vs. green"?

Would it be better to have an icon rather than trying to simulate colors with textures?

Comment 4

[David E. Ross]

A user style-sheet (in userChrome.css?) requires too much expertise for the average user.  My own recent experience in trying to get CSS to work in both userChrome.css and userContent.css (for two different purposes) indicates that only very experienced users could use this method.  

An extension (add-on) would be okay, but my own programming skills are too many years stale to do it.  One problem with extensions is that they sometimes need to be updated when the underlying components change; I recently discovered that this is also true of CSS in userChrome.css, where the syntax required changes when I updated from SeaMonkey 2.0.14 to SeaMonkey 2.1RC1.  Making this a basic part of Security:UI would ensure that the capability would remain functional (or at least increase the likelihood that it remains functional) when Security:UI changes.  

Implementing this via icons would be okay providing the icons differ by more than color.  For example, the difference between a padlock and the same padlock with a red diagonal is not sufficient since a person with red-green color-blindness might not notice the diagonal.  

Two colors or three?  A user should be able to change whatever non-standard colors are used to indicate levels of security.  

No, I am not color-blind.  My maternal grandfather was color-blind.  Grandpa had three daughters.  Each daughter had two sons.  In each pair of sons, one is color-blind (including my brother) and one is not.  

According to Wikipedia (at <http://en.wikipedia.org/wiki/Color_blindness>), "In the United States, about 7 percent of the male population -- or about 10.5 million men -- and 0.4 percent of the female population either cannot distinguish red from green, or see red and green differently from how others do."

Comment 5

[Kai Engert (:KaiE:)]

I would prefer a default solution that works for color blind people, too, without requiring user configuration, without requiring an addon or tweaks.

Quoting: http://www.ambysoft.com/essays/userInterfaceDesign.html

"Use color appropriately. Color should be used sparingly in your applications and, if you do use it, you must also use a secondary indicator. The problem is that some of your users may be color blind and if you are using color to highlight something on a screen, then you need to do something else to make it stand out if you want these people to notice it."

In my opinion, an icon would be appropriate to signal "either blue or green".

I also think that the difference between "no color" and "some color background" should be easy to notice, too. In my understanding, common UI guidelines recommend that color should not be the single way of signalling.

Yes, we can argue that "additional domain name" and "company name" _might_ could be sufficient, but a counter argument is, this information is often part of the urlbar already, and might therefore be redundant, and might therefore not be sufficient.

Based on the above, my opinion is, that we should have a sort of three-state indicator, that is not using colors, but something else. An icon would be good, in my opinion.

This brings me back to the old discussion regarding the padlock.

I know there have been arguments that the padlock is misleading, but I strongly disagree. In my opinion, the padlock makes sense. The meaning of the padlock is "we're using SSL, and we have successfully verified some server certificate, and that used at least domain validation."

Yes, the argument is valid, that the padlock is not sufficient for EV. I had the idea to show something like "padlock + passport" icon, when using EV. I think this matches the semantics. We have something equivalent to the padlock meaning (at least DV), and at the same time, we have something in addition, a better identity verification (hence the passport).


There have been other ideas circulating recently. One was, proposed by Asa, let's reverse the semantics. Instead of showing a padlock, show some sort of warning icon, whenever we're without any protection measures.

This inspired me to create the anti-padlock addon (which you can find and try on AMO).

However, unfortunately, the idea of the anti-padlock does not solve _this_ bug, which asks for "allow to distinguish between DV and EV without colors".


In my personal opinion, given how many users the padlock icon has, given how many surprised questions I see on support.mozilla like "why no padlock", I think we should bring it back, in some form.


Maybe a compromise could be:

- anti-padlock icon (some sort of light warning icon)
  whenever we're without any SSL or if SSL is broken on this connection

- either the classic padlock, or alternative, no symbol at all,
  when using good SSL with DV

- some sort of "better padlock" when using EV,
  e.g. some sort of passport icon


Ignoring the above compromise, my personal preference would be:

- a icon that shows an EYE, whenever there is no SSL in use,
  or SSL is broken
  (see my padlock-or-eye addon for a nice eye icon)

- a padlock whenever we have good DV (but not EV)

- a padlock + passport whenever we have good EV

Comment 6

[Kai Engert (:KaiE:)]

Attachment: sample EV icon

Comment 7

[Kai Engert (:KaiE:)]

Attachment: sample eye icon

This could be used, meaning "anti padlock", in the sense that the data is visible, that a hacker can look at the data.

Comment 8

[Alex Limi (:limi) — Firefox UX Team]

User-configurable colors are not on the table, if the shades of green and blue we are using are affected by any of the known forms of color blindness, we should change the defaults.

Comment 9

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I believe that the fix for bug 588270, possibly combined with the fix for bug 62178, will give non-color indicators as to security levels.

With the patch for bug 588270:

* No site identity block: either non-HTTPS, or mixed content; URL scheme indicates which

* Site identity block with domain name only: non-EV

* Site identity block with something other than a domain: EV.

In addition, we are planning to use an infobar to indicate mixed content as part of 62178.

So, this should be WONTFIXed after bug 588270 lands.

Comment 10

[David E. Ross]

Since bug #588270 is now WontFix, comment #9 should no longer apply.

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Bug 742419 is the new bug 588270.

Comment 12

[Dana Keeler (she/her) (use needinfo) [:keeler]]

I don't think this is a concern any longer since the indicators are differentiated by icon, not just color (and in any case we removed the blue lock treatment for DV), but front-end folks can make the final decision.

Comment 13

[David E. Ross]

Why is this now a Firefox bug?  It also affects SeaMonkey and Thunderbird.