426689 - HTTP basic auth prompt over plain http shows big lock icon

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Kai Engert (:KaiE:)]

Attachment: screen shot

Go to http://kuix.de/misc/test35
You'll be prompted to enter a password.
The connection is basic auth over plain HTTP, no security in progress at all.

Actual behavior:
The prompt displays a big lock symbol, suggesting there is some kind of security in effect.

Expected behavior:
Do not show lock symbol.

Comment 1

[Kai Engert (:KaiE:)]

A regression from bug 244273?

My tree is from yesterday, but I guess things didn't change since then.
I'm updating my tree and will retest anyway.

Comment 2

[Reed Loden [:reed]]

Firefox 2 uses the same icon for both http and https, but the icon used is the question bubble and not a lock.

Comment 3

[Kai Engert (:KaiE:)]

Yes, I still get this bug with the most recent trunk.

Comment 4

[Reed Loden [:reed]]

Bug 402839 caused this on accident.

Comment 5

[Michael Ventnor]

The lock symbol here doesn't mean "security", it means "authentication". It is a stock icon, gtk-dialog-authentication.

Comment 6

[Kai Engert (:KaiE:)]

(In reply to comment #5)
> The lock symbol here doesn't mean "security", it means "authentication". It is
> a stock icon, gtk-dialog-authentication.

The user does not know that "here" it's supposed to mean authentication, while in other browser windows we use it to indicate some kind of protection.

I think the lock symbol is a very bad choice for visualizing authentication.
I think we should even ask GTK maintainers to change that.

(They could use a key icon, which is what authentication prompts ask for.)

For the immediate fix I propose we switch back to the question mark icon.
According to Mike Connor that's what's display on Mac.

Comment 7

[Michael Monreal [:micmon]]

From the GNOME POV the lock icon is 100% right. I fully agree with Michael Ventnor.

Comment 8

[Johnathan Nightingale [:johnath]]

(In reply to comment #7)
> From the GNOME POV the lock icon is 100% right. I fully agree with Michael
> Ventnor.

I don't dispute that, but the most critical consistency to maintain is within our own product, where the lock is used to represent encryption/security, and is very likely to carry exactly the wrong message here (namely that the credentials are being sent over an encrypted connection).  In typical gnome usage, I suspect this confusion isn't as much of an issue (since it will often be asking for locally stored credentials involving no network traffic) but for a network application that uses the padlock to signal encrypted channels, it certainly is.

Back in the day, there was gtk-dialog-question, IIRC, but I don't know if that's still live.  Anyhow - a question mark is significantly more appropriate here than a padlock.

Comment 9

[Michael Monreal [:micmon]]

Heh... no. Using the GNOME icon theme, there is no lock at all there. GNOME's metaphor for gtk-dialog-authentication is a pair of keys. The lock metaphor has not been used in a long time in GNOME. It is used in the GTK fallback icons for historical reasons...

Comment 10

[Johnathan Nightingale [:johnath]]

(In reply to comment #7)
> From the GNOME POV the lock icon is 100% right. I fully agree with Michael
> Ventnor.

(In reply to comment #9)
> Heh... no. Using the GNOME icon theme, there is no lock at all there. GNOME's
> metaphor for gtk-dialog-authentication is a pair of keys. The lock metaphor has
> not been used in a long time in GNOME. It is used in the GTK fallback icons for
> historical reasons...

I don't understand - does comment 9 correct comment 7, and assert that the padlock is *not* GNOME-consistent?  If a pair of keys is consistent with platform, I'd go for that even if it does have vague security connotations - it doesn't strongly imply encryption the way the padlock does, which is the central problem I want to solve. 

Comment 11

[Damon Sicore (:damons)]

Jonath, should we block on this?

Comment 12

[Johnathan Nightingale [:johnath]]

(In reply to comment #11)
> Jonath, should we block on this?

I think I understand Michael M's comment now.  He's saying that Kai is seeing the GTK fallback icon, but that (shall we say "more modern"?) GNOME installs override it with the keys icon instead.  That is good to hear, but for those without this override (like Kai) it's still very misleading.

In my opinion, we should replace gtk-dialog-authentication with something less likely to confuse, or remove the line added by bug 402839, if this is the end result.  I don't know what proportion of our linux users this puts at risk, but unless it is vanishingly small, I'd recommend blocking or at least wanted-with-intent-to-approve.  The bug that regressed this is not a blocker, and we have never had this behaviour in the past, so in my estimation the risk to backing out the change (as a last resort) is low.

Michaels M or V - do you see other ways to resolve this so that we can keep native look and feel without sending mixed messages? 

Comment 13

[Kai Engert (:KaiE:)]

(In reply to comment #12)
> 
> I think I understand Michael M's comment now.  He's saying that Kai is seeing
> the GTK fallback icon, but that (shall we say "more modern"?) GNOME installs
> override it with the keys icon instead.  That is good to hear, but for those
> without this override (like Kai) it's still very misleading.

I'm using Fedora 8, which I think is quite bleeding edge.

Comment 14

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Proposed workaround until we kow a better solution to guarantee the icon will not be a lock icon.

This patch gives me a question-mark icon in the prompt.

Comment 15

[Damon Sicore (:damons)]

After deliberating, I don't think we should block.  However, we'd take the
patch.

-'ing.

Comment 16

[Johnathan Nightingale [:johnath]]

Comment on attachment 313660 [details] [diff] [review]
Patch v1

> .authentication-icon {
>-  list-style-image: url("moz-icon://stock/gtk-dialog-authentication?size=dialog");
>+  list-style-image: url("moz-icon://stock/gtk-dialog-question?size=dialog");
> }

I don't have a linux machine to verify that this works.  Assuming it does, r=me BUT I'd really like to get Michael M or Michael V to comment on whether there is another icon that would make everyone happy.

Comment 17

[Michael Ventnor]

The GNOME icon theme's icon is different enough to ours that I doubt it would cause confusion. Like I said before, its up to the GTK icon theme what metaphor is used when we request the authentication stock icon.

I really don't want to have to do this... using the question icon yet again in this situation seems to make us look lazy (IMO thats what I would think if I was an end user)

If all else fails, we could use the key icon from the password manager. But I still think the authentication icon is the best way despite what one icon theme does.

Comment 18

[Kai Engert (:KaiE:)]

So, I'm a bit confused, let's see if I get it right.

I wasn't aware earlier, but now, If I understand correctly, we are now discussing about GTK (base engine), GNOME (desktop), which both have their own icons, and Firefox the application, which wants to avoid icons that a theme might have chosen, but which are inappropriate for the application context.

I have a suspicion why I see the GTK fallback icons. It's because I'm not using GNOME. I use KDE.

I think we should avoid the fallback icons that doesn't match the application context.

Comment 19

[Kai Engert (:KaiE:)]

(In reply to comment #17)
> The GNOME icon theme's icon is different enough to ours that I doubt it would
> cause confusion.

Sorry, maybe I missed an important detail, but I don't follow.
The fact that GTK icon and GNOME icon are different, how does that help to avoid confusion?


> I really don't want to have to do this... using the question icon yet again in
> this situation seems to make us look lazy (IMO thats what I would think if I
> was an end user)

I don't follow why a neutral question mark icon for a prompt to authenticate over a channel of unknown security is lazy.


> If all else fails, we could use the key icon from the password manager.

Is that a property of GTK or GNOME?

If it's GNOME, I think it won't help me when using KDE.

If it's GTK, how would one use it?
Can you propose a patch?

Comment 20

[Kai Engert (:KaiE:)]

Comment on attachment 313660 [details] [diff] [review]
Patch v1

I propose to take this patch until we have a better one, requesting approval.

Comment 21

[Michael Monreal [:micmon]]

(In reply to comment #18)
> I wasn't aware earlier, but now, If I understand correctly, we are now
> discussing about GTK (base engine), GNOME (desktop), which both have their own
> icons, and Firefox the application, which wants to avoid icons that a theme
> might have chosen, but which are inappropriate for the application context.

GTK ships a set of icons. The authentication icon there is a lock. GNOME (and KDE4) use the freedesktop icon spec for icons, the matching icon would be "dialog-password". In both GNOME icon theme and Oxygen icon theme (KDE4) this icon shows keys. The freedesktop icon spec also provides a set of legacy icon name mappings (symlinks), one of which is dialog-passwort -> gtk-dialog-authentication. So in GNOME, we end up seeing "dialog-passwort" if gtk-dialog-authentication. Ideally Firefox would use the freedesktop names, but this would mean Firefox had to provide it's own fallback scheme.

Why is KDE left out here? Because they choose too. The Oxygen team was made aware of the problems they cause by not shipping legacy icon links (specifically in regard of Firefox 3) but for whatever reason they choose not to provide these mappings.

As for trying to avoid inappropriate icon metaphors which themes could use: this is pointless. There could be themes showing cats and dogs on all the icons but this is really not something we should care about. It's the icon theme that is broken - but, if the user wants to use it anyway, it's his problem. At least the icons in FF are consistent with the rest of the desktop.

Comment 22

[Kai Engert (:KaiE:)]

My 4 months old distribution is still using KDE 3. KDE 4 is very bleeding edge. If Firefox looks wrong with KDE 3, we should have a good fallback.

I agree that we shouldn't try to work right with funny themes a user might prefer to install. But I haven't done anything like that.

We should look correct on the default themes.

Comment 23

[Michael Ventnor]

Can the Tango team make a suitably sized key icon, similar to the one used in the password manager?

Going back to the question icon when it barely qualifies as a question is a regression IMO.

Comment 24

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

>Can the Tango team make a suitably sized key icon, similar to the one used in
>the password manager?

They actually made one at 64x64 for a notification feature that got cut.  Now that I think about it I probably should have pointed that out earlier, I've just been passively reading this bug.  monreal: can you generate a png and attach it?

Comment 25

[Michael Monreal [:micmon]]

64x64 would be way to big for this dialog. Even 48x48 seems to be too big. Can someone tell me what size the icon is scaled to? 42x42?

Comment 26

[Kai Engert (:KaiE:)]

Look at the screenshot. My screen is 1600x1200. According to gimp this icon is at least 56 width and 74 height.

Comment 27

[Michael Monreal [:micmon]]

(In reply to comment #26)
> Look at the screenshot. My screen is 1600x1200. According to gimp this icon is
> at least 56 width and 74 height.

What? I took the attached screenshot as a base and the visible area of the icon is not biger than 36x39. So, what is the intended size of this icon?

Comment 28

[Kai Engert (:KaiE:)]

Oops, I'm sorry, I had accidentally looked at the position, not the selection size. You're right.

Comment 29

[Michael Ventnor]

40x40 if my original CSS wasn't changed.

Comment 30

[Johnathan Nightingale [:johnath]]

Michael, Michael, Alex, and Kai - thanks for coming to a workable place here.

Kai - I think we can remove the approval request on the old patch, if Michael M is going to furnish us with a new icon RSN?

Comment 31

[Kai Engert (:KaiE:)]

(In reply to comment #30)
> Kai - I think we can remove the approval request on the old patch, if Michael M
> is going to furnish us with a new icon RSN?

You mean add an icon that we ship with Firefox? (sounds good)

Comment 32

[Michael Monreal [:micmon]]

Attachment: Key icon (40x40)

I hope this pleases everyone. Let's take this into chrome, it's a smaller version of the 64x64 key we already have and quite close to the password icon in both GNOME and KDE4.

Comment 33

[Johnathan Nightingale [:johnath]]

Comment on attachment 314575 [details]
Key icon (40x40)

wfm

Comment 34

[Reed Loden [:reed]]

Attachment: patch - v2

Comment 35

[Johnathan Nightingale [:johnath]]

Comment on attachment 314665 [details] [diff] [review]
patch - v2

I don't have a linux box to confirm that this presentation looks okay (i.e. no transparency jaggies or anything) but the patch is right (obviously assuming that the image is landed at the same time).

Comment 36

[Kai Engert (:KaiE:)]

Attachment: screen shot with v2 applied

I copied the file to mozilla/toolkit/themes/gnomestripe/global/icons/Authentication.png
I applied the patch and built.

I get no icon (which is fine with me as a fix), but obviously not what has been intended.

No messages on error console.

Comment 37

[Kai Engert (:KaiE:)]

Oh wait, I made a mistake, didn't add file to jar.mn

Comment 38

[Kai Engert (:KaiE:)]

Attachment: real screen shot with v2 applied

Please ignore comment 36.

This is the real screenshot with the patch applied.
I get the key, looks good to me!
Thanks

Comment 39

[Michael Monreal [:micmon]]

Should the icon be moved a bit, e.g. centered between the current position and the text? it looks a bit weird this way imho

Comment 40

[Kai Engert (:KaiE:)]

I think moving the icon position should be requested in a separate bug, in order to keep the changes for FF 3.0.0 minimal at this point of time.

Comment 41

[Kai Engert (:KaiE:)]

Drivers, I'd support taking patch v2.

Johnathan, are you happy with the screen shot, too?

Comment 42

[Johnathan Nightingale [:johnath]]

(In reply to comment #39)
> Should the icon be moved a bit, e.g. centered between the current position and
> the text? it looks a bit weird this way imho

It does, which is odd, since the patch is a straight drop-in replacement.  I assume we got the graphic dimensions right?


(In reply to comment #41)
> Drivers, I'd support taking patch v2.
> 
> Johnathan, are you happy with the screen shot, too?

Yes - I think we land it and file a polish bug on the positioning - that way we don't have an RC go out showing our encryption symbol for unencrypted credentials.

Comment 43

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

Comment on attachment 314665 [details] [diff] [review]
patch - v2

a1.9=beltzner

Comment 44

[Kai Engert (:KaiE:)]

checked in, marking fixed

Comment 45

[Marcia Knous [:marcia]]

verified fixed using  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041404 Minefield/3.0pre. I verified using the testcase in Comment 0.