428948 - On reported phishing and malware web pages, site ID button should turn red and Larry should show red danger icon and relevant text instead of grey, unverified icon and text

Status: RESOLVED DUPLICATE of bug 752447

(Toolkit :: Safe Browsing, defect)

Description

[AndrewM]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008041306 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008041306 Minefield/3.0pre

(This is somewhat similar to bug 420095, but for the specific case of malware and phishing warning pages, so I thought it was worth filing a separate bug.)

When you visit a reported phishing or malware site (such as the one above) and click on Larry, you see the default grey, unverified Larry and text saying "This web site does not supply identity information. Your connection to this web site is not encrypted." (see screenshot). This conflicts with the warning page, which has the red "danger" version of the Larry icon and scary text.

Instead, on malware and phishing sites Larry should show the same red danger icon as the warning page and text which supports and confirms what the warning page itself says. Also, this could be persisted so that if the user clicks the "Ignore this warning" link and later clicks on Larry, they'll be reminded that it's a reported phishing or malware site (there's already the big red information bar, of course, unless they've closed it).

Reproducible: Always

Comment 1

[AndrewM]

Attachment: Mismatch between what Larry says and what the warning page says

Comment 2

[Johnathan Nightingale [:johnath]]

Yep, we definitely should.  Don't think this blocks Firefox 3, and it likely involves string changes, but it's definitely something we should do.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #2)
> Yep, we definitely should.  Don't think this blocks Firefox 3, and it likely
> involves string changes, but it's definitely something we should do.

We have its icon on https://www-firefox3.authstage.mozilla.com/en-US/firefox/security/identity/; either we should remove it there or add it here (that page's bug is bug 428441, BTW).

(I know it shows up in the content box for a phishing site [http://www.mozilla.com/firefox/its-a-trap.html is an example], but having it not be reflected in the favicon when the page says "The “passport officer” icon will change, to reflect the level of identity information supplied by the Web site.")

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

...is a bad user-experience.

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

Ideally we would be making the whole button red to reflect the underlying change icon as well, similar to SSL and EV:

http://mxr.mozilla.org/seamonkey/source/browser/themes/winstripe/browser/siteButtons-aero.png

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

Drivers: we need a decision here as to whether this is blocking; see comment 3.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

I don't think this blocks, and if we can't fix it in time, we should just remove the red-larry bit from our website (straight delete). A non-l10n impacting fix would be to just switch the icon to red-larry, but leave the text-as is.

Comment 8

[Johnathan Nightingale [:johnath]]

Bug 432255 removed the red icon from the page mentioned in comment 3, pending a resolution here.  When this bug is resolved, we should file a follow-up to add it back.

Comment 9

[AndrewM]

Nominating for blocking‑firefox3.1 and change edit summary to include suggestion in comment 5.

Comment 10

[AndrewM]

This was marked as wanted-firefox3, does it qualify for wanted-firefox3.1?

Comment 11

[Luís Miguel [:quicksaver] (not reading bugmail)]

Attachment: ForgeryIdentityBox.png

I'd like to vote for reviving this bug. It's incredibly easy to predict situations where this would be very useful, especially considering the "ignore this warning" action persists during the current session (bug 1008882).

From the top of my head:
- it's easy to forget that you've been warned about a certain webpage after a few hours (and a few hundred other visited sites).
- if someone uses the computer and receives a malicious email/message/link/whatever and decides for whatever reason to ignore the warning, then later another person on the same computer happens to receive the same email/message/link/whatever, that second person will not even receive that warning if he's in the same browser session (kind of edge-casey I know but still possible).

I believe a constant reminder like this, that the current webpage has been reported as malicious, would definitely improve UX in terms of keeping us informed of where we are and what's safe to do in there (and if we should be there at all).

I made a quick mockup of how I would like/expect the identity box to look in this situation.

Comment 12

[Luís Miguel [:quicksaver] (not reading bugmail)]

Also, I don't agree with the summary. The identity box should reflect this info on the actual reported webpages, not on the warning pages as the summary suggests; those are internal webpages even, so it would be weird indeed if they're dangerous themselves at all...

I understand this changes a bit the objective of the bug, but showing this info only on the warning pages would be redundant (and not technically true). I think this bug should focus on the suggestion made by AndrewM in comment 0:
> this could be persisted so that if the user clicks the "Ignore this
> warning" link and later clicks on Larry, they'll be reminded that it's
> a reported phishing or malware site

Changing the summary to reflect this, please change back if I misread or if you disagree.

Comment 13

[Florian Bender]

I'm just going ahead and request adding this to the backlog, preferably with a high priority. You can request the firefox-backlog flag in the bug panel above (under "Flags (edit)").

Comment 14

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

This was approached in bug 752447. Duping it forward since there is a more recent conversation in that bug.