Closed Bug 426689 Opened 14 years ago Closed 14 years ago

HTTP basic auth prompt over plain http shows big lock icon

Categories

(Core Graveyard :: Security: UI, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: KaiE, Assigned: micmon)

References

()

Details

Attachments

(4 files, 2 obsolete files)

Attached image 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.
Flags: blocking1.9?
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.
Firefox 2 uses the same icon for both http and https, but the icon used is the question bubble and not a lock.
Yes, I still get this bug with the most recent trunk.
Keywords: regression
Bug 402839 caused this on accident.
Blocks: 402839
The lock symbol here doesn't mean "security", it means "authentication". It is a stock icon, gtk-dialog-authentication.
(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.
From the GNOME POV the lock icon is 100% right. I fully agree with Michael Ventnor.
(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.
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...
(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. 
Jonath, should we block on this?
(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? 
(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.
Attached patch Patch v1 (obsolete) — Splinter Review
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.
Attachment #313660 - Flags: review?
Attachment #313660 - Flags: review? → review?(johnath)
After deliberating, I don't think we should block.  However, we'd take the
patch.

-'ing.

Flags: blocking1.9? → blocking1.9-
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.
Attachment #313660 - Flags: review?(johnath) → review+
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.
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.

(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 on attachment 313660 [details] [diff] [review]
Patch v1

I propose to take this patch until we have a better one, requesting approval.
Attachment #313660 - Flags: approval1.9?
(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.
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.
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.
Keywords: regression
>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?
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?
Look at the screenshot. My screen is 1600x1200. According to gimp this icon is at least 56 width and 74 height.
(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?
Oops, I'm sorry, I had accidentally looked at the position, not the selection size. You're right.
40x40 if my original CSS wasn't changed.
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?
Attachment #313660 - Flags: approval1.9? → approval1.9-
(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)
Attached image 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.
Attachment #314575 - Flags: ui-review?(johnath)
Comment on attachment 314575 [details]
Key icon (40x40)

wfm
Attachment #314575 - Flags: ui-review?(johnath) → ui-review+
Attachment #314575 - Flags: approval1.9?
Attached patch patch - v2Splinter Review
Attachment #313660 - Attachment is obsolete: true
Attachment #314665 - Flags: review?(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).
Attachment #314665 - Flags: review?(johnath) → review+
Attachment #314665 - Flags: approval1.9?
Assignee: kengert → michael.monreal
Attached image screen shot with v2 applied (obsolete) —
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.
Oh wait, I made a mistake, didn't add file to jar.mn
Please ignore comment 36.

This is the real screenshot with the patch applied.
I get the key, looks good to me!
Thanks
Attachment #314687 - Attachment is obsolete: true
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
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.
Drivers, I'd support taking patch v2.

Johnathan, are you happy with the screen shot, too?
(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 on attachment 314665 [details] [diff] [review]
patch - v2

a1.9=beltzner
Attachment #314665 - Flags: approval1.9? → approval1.9+
Attachment #314575 - Flags: approval1.9? → approval1.9+
checked in, marking fixed
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.