752447 - Use an icon and display some text in location bar for about:blocked

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[Florian Bender]

The awesome bar should indicate whenever you are on a browser special page (all "about:", error pages / warnings e. g. "Not Found" and "Phishing attempt"). 

Right now, it's trivial to fake a browser special page rendered in-content (at least error pages). This allows for phishing / social engineering. When e. g. in-content preferences land, the implications will be far greater. This risk is reduced when the changes to site identy land in Fx 15. However, the current indication for special pages (i. e. on error pages the warning sign as "favicon") is not obvious enough for non-trained users. 

I've sketched out a proposal, adding a new element in the location bar whenever you are on a special page: 
https://www.dropbox.com/s/g69dxj3hghuq3ve/fx-awesomebar-specialpage.png
https://www.dropbox.com/s/31z0zzzbr5mzqv1/fx-awesomebar-error.png

Another possibility (probably better and less intrusive but still remarkable) is reusing the EV site-identy (https://msujaws.files.wordpress.com/2012/04/tumblr_m2xymz9bfz1r47294.png) and have an e. g. orange background + text + warning sign for errors ("Not Found"), red background + text + warning sign for warnings ("Phishing attempt", "Certificate Error"), and blue background + text + gear icon(?) for in-content preferences + _any_ "about:" page (text is "about:" for any "about:" page except "Addon preferences" for "about:addons", "Preferences" for "about:preferences" etc.).

Comment 1

[Nigel]

My concern is that changes made for the EV site-identity are terrible - they do not allow visually impaired users to distinguish easily that the site is "Green" and OK to do business.  The old method of highlighting the name, as followed by Microsoft was a success.  IMO - the change thats there now is terrible and is a retrograde step in making things easier for the user.  Also the colours now can not be distinguished in certain lights even if you are not visually impaired - whilst the original in Firefox 4 showed with a highlight - Green Safe and Red - Take great care!

That would be my solution and to remove the "blue" for standard SSL sites.

Comment 2

[Florian Bender]

@Nigel, this is not really what this bug is about, however it is partly relevant to this bug: 

I think the changes are good (at least as described here: https://msujaws.wordpress.com/2012/04/23/an-update-to-site-identity-in-desktop-firefox/). If the identity block shows the company name, you're good to go, if there's only a lock icon, your session is secured but the owner is unknown (-> less secure). 

Concerning this bug: The key here is the additional text displayed after the icon (formerly: favicon): E. g. displaying "Not Found" or "Addon preferences" allows even visually impaired users to easily distinguish where they are, regardless of the chosen color (the color is only a helping indicator, not the primary source of information). Only problem is that an EV certificate could mimik a Fx special site – but who names his company "Not Found"? 

First of all, this could be mitigated by using less generic labels ("Error: Not Found", "Warning: Phishing Attempt", "Firefox Preferences", "Firefox Addon Preferences", "Firefox about:", "Firefox: Advanced Configuration" for about:config, …).

Secondly, special pages use a different color (not applicable for visually impaired, but not a dealbreaker, IMO). But even then, a different icon (e. g. gears, warning sign) gives a visual (color-agnostic?) clue about the "nature" (e. g. secure website, preference pane, error message) of an identity block.  

Thirdly, I rather think this is an advantage: Showing a name in the identity block like a page having an EV cert indicates the current location is a secure one, as preferences are (because they are generated by the browser). Thus, visually impaired users should not be confused by this behaviour. 


Either way: Did anybody actually consult with several visiually impaired users to verify the arguments presented in that bug?

Comment 3

[Nigel]

@Florian - Thanks for your comments.  The only reason why I commented was that you mention the EV display and wanted to comment that I did not think that was good.  In fact I feel its below poor!  As to the "old green background" all those I have asked including people in cyber security people, all say a green background is better than only having the additional text in green.  And the green text at the moment is bad - and thats been raised by someone else.

The name has always since FF4 been shown as a separate block, but was black with green background - thats now gone a dark shade of green.

As to anyone in Firefox consulting - not that I am aware.  I used to work with several who were visually impaired - and used that experience as well as the fact that an initial look I can not see its really green.  I have to "know" its green and see that its different.  The old method to me was 100+% better

Comment 4

[Florian Bender]

A coloured background + black or white text is ok, too, if not better (i. e. more distinguishable / alerting, at least for EV). 

Either option is IMHO ok for this particular bug, no matter how it is solved for EV certs. It may actually be better to use a colored background for EV certs (your proposal if I understand you correctly, and the current way of displaying certs) and a light background + colored text for Fx special pages (as EV certs in the current nightly version mentioned in the blogpost above). 

Thank you for your input!

Comment 5

[Florian Bender]

Just to make that clear, I also propose this for internal pages ("about:*"). Should I open a seperate bug for that?

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Florian Bender from comment #5)
> Just to make that clear, I also propose this for internal pages ("about:*").
> Should I open a seperate bug for that?

Bug 750106 will add a different icon in the location bar for about:* pages. I don't think we should make any other changes to the location bar for non-error chrome URLs, but if you feel different then feel free to file a separate bug.

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug

The only issue that I can see with this patch is that editing the URL bar and then losing focus on the URL bar will return the URL bar to dark grey background until there is a new load on the page.

Tested with http://mozilla.org/firefox/its-a-trap.html

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 622258 [details] [diff] [review]
Patch for bug

Clearing review for now as I think this will also get triggered on non-security error pages such as about:neterror. I'll add a check for about:blocked being the document.documentURI.

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug v2

This whitelists about:blocked so it doesn't apply on other error pages, as per discussion on IRC:

12:16 PM <jaws> shorlander: for bug 752447, should we only darken the location bar for about:blocked or other pages as well?
12:16 PM <shorlander> jaws: only blocked

Comment 10

[Dão Gottwald [:dao]]

Comment on attachment 622454 [details] [diff] [review]
Patch for bug v2

You add an isErrorUI to URLBarSetURI but you never use it.
Then, why does the code added to URLBarSetURI belong there?
Did you test your gnomestripe theme change? I don't think it can possibly work.
Last but not least, what exactly is the added security value here?

Comment 11

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Dão Gottwald [:dao] from comment #10)
> Last but not least, what exactly is the added security value here?

It would be good to provide something within our browser chrome to help people distinguish from fake warning messages like this one: http://nakedsecurity.sophos.com/2011/05/30/fake-firefox-warnings-lead-to-scareware/

Comment 12

[Dão Gottwald [:dao]]

I would expect people susceptible to such fake warnings to take them seriously regardless of the location bar color.

Comment 13

[Blair McBride [:Unfocused] (UNAVAILABLE)]

The security team has expressed interest in having this for awhile. IIRC, it was brought up in the security review for updating in-content error pages, as something that's desirable to have.

Comment 14

[Dão Gottwald [:dao]]

That's still a bit too vague for me to make sense of it. The dark background isn't very self-explanatory, and neither is the lack of the dark background -- so spoofs continue to work.

This also adds a vector of complexity that will be nasty to deal with. What to do about dark OS themes? What if we decide to make the location and search bars dark for dark lightweight themes? What about private windows, which Stephen has dark mockups for?

I think we should just update the icon in the location bar.

Comment 15

[Nigel]

My view is that we should go back to having the light green background that we had with FF4-FF13 for sites with Extended SLL validation

Comment 16

[Florian Bender]

IMHO this change should also apply to about:neterror additionally to about:blocked. Every in-content browser message should be accompanied by an indication not susceptible to (world-)manipulation as criminals will always find a way to use "unsecured" browser messages for their purposes. Plus, it's a matter of ux-consistency to handle similar messages (errors and warnings) in the same way. 

Darkening the location bar is IMHO ambiguous UX-wise (as :dao said). I'd stick with a different icon **plus title** (like EV certs) to distinctively indicate browser messages. Changing colors of (parts of) the location bar is only an optional visiual enhancement (plus, as :dao said, error-prone to design decisions).

Comment 17

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug v3

This patch only shows the darkened location bar for phishing and malware warnings, and includes a red error icon in the location bar as well.

(In reply to Dão Gottwald [:dao] from comment #10)
> You add an isErrorUI to URLBarSetURI but you never use it.
Fixed.

> Then, why does the code added to URLBarSetURI belong there?
The URL can be updated from a page load or from switching tabs, so I tried to place this code in the codepath that will be hit whenever the location bar is updated.

> Did you test your gnomestripe theme change? I don't think it can possibly
> work.

I tested this patch on gnomestripe and included the relevant fixes for it.

Comment 18

[Dão Gottwald [:dao]]

Comment on attachment 622938 [details] [diff] [review]
Patch for bug v3

>+  var browser = gBrowser.selectedBrowser;
>+  if (browser._isErrorUI)
>+    gURLBar.setAttribute("errorChromeUI", true);
>+  else
>+    gURLBar.removeAttribute("errorChromeUI");

As far as I can see, this code can just live where you currently set _isErrorUI.

>+#urlbar[errorChromeUI]:not([focused]) {
>+  background-color: rgb(51,51,51);
>+  color: white;
>+  -moz-appearance: none;
>+  border: 1px solid rgba(23,51,78,0.3);
>+  padding-top: 1px;
>+  padding-bottom: 1px;
>+  -moz-padding-end: 2px;
>+}

This is going to be jarring (changing the border, border radii, padding etc.) depending on what OS theme is in use.

Last but not least, see the previous comments about why we shouldn't darken the location bar.

Comment 19

[Jesse Ruderman]

Changing the icon makes sense.

Darkening the address bar seems like overkill and likely to conflict with various lucky charms, color schemes, etc.  How about making the URL or domain red instead?

Comment 20

[Nigel]

Would only support the URL Red if the red is a Bright Medium Red and not a dark red that could blend into black - it needs to be obvious to 100% of the people - not just for the Firefox developer community

Comment 21

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug v4

Tested on Linux, Windows, and Mac. This patch no longer darkens the background of the location bar. It sets the icon to the red do-not-enter icon and inserts "Blocked!" next to the icon.

This is following the bottom design in this mockup: http://cl.ly/1R333a2301050N1z3Q33/o

Comment 22

[Dão Gottwald [:dao]]

Comment on attachment 623458 [details] [diff] [review]
Patch for bug v4

Not getting into the technical review, as there's a new high-level problem: The identity popup is supposed to show details about the identity button's state. It doesn't at all do this in this case. Of course there's nothing useful we could actually put there, because all the relevant information is already in the content area.

Honestly, I'm not sure this is worth all the hassle, as this still isn't going to effectively prevent people from being taken in by fake error pages. The lack of an indicator isn't alarming, especially when people don't encounter blocked pages every day.

Comment 23

[Florian Bender]

I don't think that's a big problem at all. Either (a) do/show nothing on click (not good, as the user expects a message, and unsecure sites display a doorhanger nonetheless), or (b) show the unsecure-site-doorhanger (as currently implemented; may be confusing), or show a doorhanger with an even bigger error icon and an additional very short text indicating an error (e. g. "Firefox recommends you not visiting this page."). (c) is doubling the information (in a minimum amount), but more helpful than (b). (b) is the most practical approach as it does not change the behaviour and does not need any further changes (AFAICS). 

However, laying some groundwork for (c) may be beneficial for other use cases as well. I strongly believe having such an indicator (with "identity" information) for _all_ in-content messages (also in-content prefs) is both helpful and necessary (security-wise, at least passively) bearing in mind that Bug 752434 will land. 

As for users: They will learn to use the indentifier, as they learned for indicators for secured connections. It's a matter of evangelism. And either way, those who know where to look will appreciate this feature!

Comment 24

[Florian Bender]

(In reply to Florian Bender from comment #23)
> doorhanger nonetheless), or (b) show the unsecure-site-doorhanger (as
> currently implemented; may be confusing), or show a doorhanger with an even

should be "… confusing), *(c)* or show a doorhanger …".

Comment 25

[Dão Gottwald [:dao]]

(In reply to Florian Bender from comment #23)
> (b) show the unsecure-site-doorhanger (as
> currently implemented; may be confusing), [...] (b) is the
> most practical approach as it does not change the behaviour and does not
> need any further changes (AFAICS).

The popup currently matches the globe icon and breaking this is a behavior change. It's unclear that the confusion outweighs any hypothetical benefit here, hence my r-.

Comment 26

[Florian Bender]

If I understand correctly, the current patch follows solution (a) but it should follow at least (b), doesn't it?

Comment 27

[Tanvi Vyas[:tanvi]]

I agree that adding information to the site identity is useful.  If the user clicks the red minus sign, the user could get a doorhanger with a short message that firefox is weary of this page and has blocked it.

This may not eliminate the attack (http://nakedsecurity.sophos.com/2011/05/30/fake-firefox-warnings-lead-to-scareware/) for all users, since some users won't pay attention to the url bar.  But at least it will eliminate it for some.

In addition (or instead) of the darkened bar, I like the idea of coloring the url font red (not sure how UX feels about that).

Do we have an idea of when bug 752434 will land?  If it is soon, then maybe we should use the same UI for this messaging.  However, since it's assigned to nobody, there is no implementation info, andd no UI mockups in that bug, I'd say that bug is a ways out.  And we should do something now to mitigate the attack described in the blog post.

Comment 28

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Dão Gottwald [:dao] from comment #25)
> (In reply to Florian Bender from comment #23)
> > (b) show the unsecure-site-doorhanger (as
> > currently implemented; may be confusing), [...] (b) is the
> > most practical approach as it does not change the behaviour and does not
> > need any further changes (AFAICS).
> 
> The popup currently matches the globe icon and breaking this is a behavior
> change. It's unclear that the confusion outweighs any hypothetical benefit
> here, hence my r-.

This is not a regression from what we currently ship. We can update the doorhanger in a followup bug. The addition of this might not help all users understand if they are visiting a scam site, but it does increase the tie-in between chrome and content as well as the visual polish of the browser.

Comment 29

[Dão Gottwald [:dao]]

(In reply to Jared Wein [:jaws] from comment #28)
> (In reply to Dão Gottwald [:dao] from comment #25)
> > The popup currently matches the globe icon and breaking this is a behavior
> > change. It's unclear that the confusion outweighs any hypothetical benefit
> > here, hence my r-.
> 
> This is not a regression from what we currently ship.

What we ship are favicons in the location bar. Those are indeed not expected to match the identity (although the rest of the identity button is). We're patching mozilla-central here, though, which is in a different (better) state.

> the visual polish of the browser.

Let's not confuse the motivation for this bug. It's security. The location bar with the default globe icon isn't unpolished.

Comment 30

[Florian Bender]

Sorry, this bug does not really depend on bug 750106. 

So, what about the patch. Is it ready (apart from the "identity problem")? Who decides on the "identity problem"?

Comment 31

[Jared Wein [:jaws] (please needinfo? me)]

So it looks like this bug is WONTFIX. The wins aren't huge and the likelihood that a user seeing this will know that this is how Firefox renders blocked URLs and it is not a graphical glitch are low.