Closed Bug 93571 Opened 24 years ago Closed 24 years ago

Fix lock icon behavior in the messenger window

Categories

(Core Graveyard :: Security: UI, defect, P1)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
psm2.2

People

(Reporter: ssaux, Assigned: KaiE)

References

Details

Attachments

(1 file)

Suggested fix
2.91 KB, patch
javi
: review+
mscott
: superreview+
Details | Diff | Splinter Review
The semantics of the lock icon in the messenger window are not clear, but one feature that should clearly work is when the startup page (prefs->"hmail and news"->"When mail launches, show the start page in the message area") is using SSL, then the lock icon should be correct, as should the page info -> security pane. Right now the lock is not set, and the page info -> security is blank. For a regular message text, the lock icon status will depend on some combination of the following: - Was the message downloaded from the server over a secure link? - Was the message loaded from the local disk? - Was there a web page attached to the message as an attachement and was the web page using SSL?
Setting to Future P2. The research needed to build a complete requirement for this feature and the likely substantial amount of work required to completely nail this makes it unlikely that PSM 2.1 is a realistic target.
Priority: -- → P2
Target Milestone: --- → Future
Stephane and I talked about this. In short: The lock icon in the Mail window should follow the same rules as the lock icon in the Browser window. The lock icon in the lower right corner should reflect the presence or absence of SSL between the client and the server. If the client has opened a POP connection to the mail server, it would show an unlocked lock icon because it did not use SSL. If the client opened an SSL/IMAP connection to the server, the client would display a locked icon. It does not matter if the email in question came from the server or came from the local cache. If the connection to the server uses SSL, the lock icon should be set. The lock icon in the mail window has nothing to say about emails which contain URLS or attachments which reference HTTPS sites. If the startup page is an HTTPS site, but the client is connecting to a POP server, the lock will be unlocked. The lock only comments on weather or not the client uses SSL to connect to the mail server. Clicking on the lock icon should open the Page View window and should show the cert used in the SSL transaction just like in the Browser. This is basic lock behavior, and should be fixed in PSM 2.1. Moving to PSM 2.1 from Future.
Target Milestone: Future → 2.1
There is a similar bug opened in 'MailNews' (bug 79832). Should it depends on this bug? Or is it a duplicate?
-> kaie
Assignee: ddrinan → kai.engert
*** Bug 79832 has been marked as a duplicate of this bug. ***
Keywords: nsenterprise
propagating nsenterprise+ from 79832
Keywords: nsenterprise → nsenterprise+
Looking at the code, I can see that the security status for mailnews has not yet been implemented. There is a class called "nsISecureBrowserUI". This works for browser windows only. For a mailnews window, different events have to be tracked. A new class nsISecureMailNewsUI would be required. However, in my opinion, the lock icon should not behave as in a browser window. The lock icon is supposed to tell the user that the displayed content is private. When an encrypted connection is used between the mail agent and the mail server, this does not indicate that the contents are private. The message most likely has traveled over unencrypted channels already, between SMTP servers. Displaying a lock icon would be wrong. IMHO, only if an encrypted message is displayed, the user can be sure that the displayed content is private and the lock should be closed. I checked with communicator. If I use IMAP over SSL and view a plaintext message, an open lock icon is displayed. When I view an encrypted message, the lock is closed regardless of the server connection. In communicator, when you click the lock icon, a status message about the encryption status of the message is shown. I vote for keeping this behaviour. As soon as we start to support encryption, either S/MIME or PGP, we should add this functioanlity to the lock icon. As we are currently not supporting encrypted e-mail, I vote for temporarily removing the lock icon from the mailnews window. However, I still see the advantage of providing status info about the connection to the mail server. The mailnews component already displays a mail server icon with a lock for servers connected over SSL. If we want to provide additional info (server cert details, etc.), let's add an entry to the right-click-popup-menu for a server. I suggest to open a new feature enhancement request. I'm attaching a patch that hides the lock icon in the mailnews window, and deactivates some related code that currently has no effect.
Status: NEW → ASSIGNED
In Communicator 4.78 on Windows, viewing a plaintext message over IMAP/SSL shows a closed lock icon.
I just saw that Windows and Linux versions of Communicator behave differently. With both Communicator 4.77 and 4.78 on Linux: Plaintext message over IMAP/SSL => lock icon open Encrypted message over POP => lock icon closed Next I tried on a Windows machine using 4.78. I can confirm what you see, the Windows machine indeed displays a lock icon when IMAP/SSL is used, even for plaintext messages. I have never seen that before.
The lock icon in the corner of the chrome tells you that you have an SSL connection with the server. It's implemented correctly in N6 and C4.x for browsing. It's implemented incorrectly in Win32 C4.78 for SSL/IMAP. It used to be the case (C4.6 maybe?) that the icon was locked when the message was delivered over SSL. So the first time you'd read the message over SSL/IMAP, it would be locked. But if you had selected that IMAP folder to be used offline, the client would store the message on the hard drive. So the next time you read it, the client would fetch the mail from the hard drive and NOT show the lock icon since SSL was not used. ;-) So this logic was close to the browser logic, but not close enough. :-) From my testing tonight, it seems that the logic may be more broken in C4.78. Now it's a combination of SSL plus S/MIME, but it's buggy. Some emails show the lock icon when I'm using IMAP (no SSL) and the message is clearly not signed. Kai reports other strangeness which is clearly a regression from earlier releases. The S/MIME UI will have a different mechanism for telling the user that the message was signed and/or encrypted. This is a very different statement than having a secure connection to the server you think you should be talking to. In this case, the privacy feature of SSL may not be as important as the authentication of each party for some users. The biggest problem with this approach is that it does not factor in SSL/SMTP, and that's something we should address in a future release. Let's keep the visual element consistent between the SSL/HTTP and SSL/IMAP. That also includes a tooltip showing the issuer and Page Info getting the right socket information.
We should separate the s/mime from nature of the connection to the imap server. The lock icon in the messenger window will tell the user whether the connection he has with the IMAP server is over ssl. Consequently: not connected -> unlocked. Connected over non SSL -> unlocked. Connected over SSL -> locked I don't think that the lock icon tells the user that the contents are private. It tells the user wheter any content that travels between the server and the client is encrypted. Under that assumption, the above behavior is correct. To provide a possible (future) solution to Bob's concerns about SMTP, I can see two solutions: 1) Have the send button on the composer window display a lock icon. 2) Have a lock icon on the composer window. In both cases, since we don't have a permanent connection to the SMTP server, the lock icon must rely on the pref. Note that when sending an email message, there is no resulting content to which a lock icon could be attached. Maybe another solution is to have the progress dialog change when the connection to the SMTP server is established to show a lock icon. Finally, there is one thorny issue: Assume configuration that uses SMTP over SSL, but cleartext IMAP, and folder copies of sent messages to the IMAP server. Then sending an email over SMTP sends one copy encrypted to the SMTP server and one copy in the clear to the IMAP server. Providing sensible feedback to the user becomes tricky. As for the bug at end, Kai can tell us what it takes to make the icon depend on the nature of the connection to the current server as described above.
Ok, I accept that we want to display a lock icon. I want to summarize and make design suggestions. -------------------- Behaviour suggestion -------------------- The mail window is used to display messages. Messages can come from a variety of sources. IMAP & NEWS server ------------------ These indeed may use SSL, and the connection is kept up. We can display a lock icon. If the connection is not protected, we should display an open lock. If we are offline or the connection has not been established, let's display the open lock. Local folders ------------- The local folders are filled by retrieving data from somewhere else (downloaded over POP, copied over from IMAP, imported using an import tool). As soon as a message is in local storage, we have no clue how this message was retrieved earlier and never should display a closed lock. Although a simple empty space would be most logically in my opinion, we can't do that, because the icon is used to access the page information. Therefore we either need to stick with the open lock, or invent a new icon for that. POP server ---------- Although a connection to a POP server might use SSL, as soon as the message arrives on our system, it arrives in local storage. Until mail is checked from this server, I'd like to display the open lock. When the user checks mail on a POP/SSL server, we can display the closed lock icon (until the user switches to another folder). This way a user could find out about the certificate details of the server, although the connection has been closed already. Although some of the messages within the folder might have been retrieved without using SSL. SMTP server ----------- This is a different story, but some thoughts: We should be sure not to mislead a user, giving the feeling that the mail will be encrypted. In most scenarios, e-mail will leave intranets and travel over unencrypted SMTP channels between mail servers while routed to the final destination. This is independent of whether the first segment (from user to SMTP server) uses encryption or not. Until all mail transport agents use SSL and an encrypted chain is guaranteed, this feature just helps to protect the authentication with the server from being snooped, or enables client certificate authentication, which just can't be used without SSL. In most cases users will use a single SMTP server for all their outgoing messages, and we can't detect whether a mail will stay in a protected intranet, or continue it's journey to other mail servers in plaintext. I suggest we should indicate clearly that the only thing that is protected is the password. Maybe it's better to not display any locks for SMTP. ---------------------- Clicking the lock icon ---------------------- If the user clicks on the lock icon inside Messenger, what should happen? In Communicator, this page displayed "the message is / is not encrytped, or the message is / is not signed". This matches the semantic that the page info displays something about the displayed content area (the message), not something about the server connection. However, we intend to change this semantic for now (regardless of what we do in the future when encrypted mail will be available). We need a new collection of text for the headings within that window. Strings like "Web Site Identity Verified / The web site www.acme.com supports authentication for the page you are viewing" or "The page you are viewing was encrypted before being transmitted over the Internet" are not appropriate. We need strings that say something about the mail server connection. For local folders we should state the fact that security information does not apply for messages in this folder. -------------- Implementation -------------- Currently, nsISecureBrowserUI hooks into: nsIDOMWindow -> nsIScriptGlobalObject -> GetDocShell -> nsIDocShell -> nsIWebProgress -> AddProgressListener GetDocShell is responsible for initiating the loading and viewing of a document, this is not approriate for the mailnews feedback. With mailnews, we don't have a document. We need to listen to the event of changing the folder whose contents are displayed in the message listing, as well as the connection progress to the server. Although there is already a nsIWebProgress that reports the state of loading a web document over http, there is no similar thing for connecting to a mailserver yet. But we need to have one as we need to change the icon once the connection is established. I think we need to create a new hook and interface for that. Next I need to find out how we can listen to those events and where is the right place for the mail server connection hooks.
When you click on any mail or news folder, the lock icon will indicate the presence or absence of SSL when connecting to the corresponding server. When you click on a folder, you will get this bevavior: User selects Lock is set to ------------ -------------- IMAP UNlocked POP UNlocked Local folder UNlocked NNTP UNlocked SSL/IMAP Locked SSL/POP Locked SSL/NNTP Locked Additional points regarding Kai's comments: (1) I agree that SSL/POP is a little strange. But it's probably OK to show the locked icon after the first SSL connection is made. (2) Clicking on the lock icon should open the normal Page Info window. That's what it does today. We need to populate the window with the correct security information.
Kai. Bob and I have discussed his previous comment and we're in complete agreement. We also decided that it makes sense to phase the complete solution. If we can get SSL/IMAP to behave correctly first, that is extremely valuable in and of itself. The partial solution may reduce risk.
marking nsbranch. It's unlikely that it will make it onto the 0.9.4 branch, but then I would prefer that it be officially minussed.
Keywords: nsbranch
Is it possible that we get a fix that only includes correct behavior for SSL/IMAP? Would that help make the deadline?
I don't think this restriction reduces the complexity of the yet unknown parts of the implementation.
mark nsbranch- as per conversation at today's PDT meeting. remove nsenterprise+ move to future.
Keywords: nsbranch, nsenterprise+ → nsbranch-
Target Milestone: 2.1 → Future
*** Bug 100815 has been marked as a duplicate of this bug. ***
Changing my prefered e-mail address.
Assignee: kai.engert → kaie
Status: ASSIGNED → NEW
QA Contact: ckritzer → junruh
Blocks: 107067
Keywords: nsbranch-
I propose resolving this bug by removing the lock icon from the messenger window.
Priority: P2 → P1
Target Milestone: Future → 2.2
Rational: The lock icon in the messenger window is badly overloaded. The lock icon should not give the smime status of the message. There are other ways in which smime status will be available to the reader in the mozilla smime implementation. The lock icon could still provide information about the ssl status of the connection to the mail server. But: This only makes sense for protocols that keep a connection alive, for example imap. For pop it doens't make sense. I'm not against implementing this, but if we don't implement this for now, the lock icon should be removed until the correct behavior is implemented.
I agree. The attached patch should therefore be what we want, at least for now. Requesting review from the mail team.
Before we remove it, I'm confused about the reasonsing. Stephane says "The lock icon in the messenger window is badly overloaded. The lock icon should not give the smime status of the message." How are we re-using it to show smime status? I don't see any of our smime specs showing us using this icon in the taskbar of the 3-pane for showing smime status. The specs use icons in the message pane and the icons currently there are place holders waiting for UI to design icons for signed and encrypted. To my knowledge that little lock icon in the taskbar is only used to show SSL status. Where is the over loading coming from? thanks!
*** Bug 116224 has been marked as a duplicate of this bug. ***
I think Stephane refers to ideas that we have discussed outside of this bug, where I have asked whether clicking the lock icon should open up the smime status. That's what the lock button did in Communicator. I think the explanation for removal is: - we don't want to use the lock icon for smime information, as Scott correctly points out - we are not providing SSL connection information to the mail server using the lock button (because this is confusing when mail messages without a connection are displayed)
Sorry, it certainly was overloaded in communicator 4.X, and that's what we meant. The semantics of it were very confusing. In a browser window, the lock icon opens the page info at the security tab. This ties directly to the internal security info of the connection to the server. In a messenger window for an imap account, the lock icon could very well do exactly the same, as when one click on a message, the message is fetched from the imap server. However the imap connection is persistent. What if the user has a messenger winodow opened, but hasn't fetched any messages? What if the user has a connection, but saves messages locally? In a messenger window for a pop account, there is no SSL connection. The SSL connection is opened when the user clicks on Get Messages, and is closed when the messages have been downloaded. What does it mean to view a message that was downloaded 3 month ago? Should the lock icon reflect the SSL status of the connection when the message was downloaded (which of course would require to keep SSL state across sessions for each message) or should it reflect the SSL status of the most recent "Get Message" operation (which would potentially mislead a user as to how an old message had actually been downloaded)? It's not that something truly and fully reasonable cannot be spec'ed, but rather that the specs are complex, long, and probably contentious. They would also require a significant engineering effort to implement fully. The lock icon in 4.7X did carry all of these problems (in addition to the overloading of SSL/SMIME info). It was unclear what it meant. Given the lack of resources, I believe that it's a good idea to remove the lock icon from the messenger window, until we have a full spec and a full implementation, or until we have a different paradigm to convey the SSL status of the connection to a mail server (for example, right click on the account would have a "Show connection status" item? - just a thought).
Thanks for the clarification. So 6.x is not at this time over loaded and none of our current smime specs show that it should become over loaded in the near future. I see that we don't even turn the lock on today for an imap SSL connection. Looks like we just show a lock in the folder pane under the server when your account is configured to use SSL. So if we do remove the lock in the taskbar, we still convey some visual information to the user that the imap connection is secure. So that's good. I wonder if this account icon is smart enough to become broken if I configure my account to use SSL but then I use a bad cert or something. I'll have to try that out. If that basic functionality still works then I'm cool with removing the task bar lock icon too. I'd just be worried about not conveying any visual information about your imap connection over SSL. As long as the folder pane icon reflects this correctly then I'm not concerned about removing the non functional taskbar lock icon. Of course we'll need jglick's approval too before we can change the UI. I'll send her mail.
How hard do you guys think it would be to keep the lock icon but have it just properly reflect the ssl state for imap right now? I know we used to do this in mozilla, but it looks like it broke 'cause the lock icon never locks anymore when using secure SSL over imap. Think we could make it work for that case and hide it for the rest? Or just hide it all together and forget about showing the ssl state over imap?
As mentioned above, i agree with keeping the ssl feedback and encrption feedback separate. The combined usage was the cause of much confusion in 4.x. The lock icon should be used for ssl in both mail and navigator. We'll use a different icon (TBD by Marlon) for indicating encrption feedback. If ssl isn't currently working, ok with me to remove lock icon completely. If its working for IMAP, we might want to display it as appropriate.
Scott: If there is a problem with the server cert, you get the standard PSM security dialogs (e.g.: "There is a problem with the certificate presented by dredd.mcom.com..."), at which point you have the opportunity to examine the cert presented. The only additional functionality provided by the lock icon (if it worked) would be to go and take a look at the server cert, and other information regarding the ssl connection at a later time. Regarding implementing only for IMAP kai did the research. Relevant comments in this bugs are: http://bugzilla.mozilla.org/show_bug.cgi?id=93571#c7 (first part). and http://bugzilla.mozilla.org/show_bug.cgi?id=93571#c13 (last part: Implementation part). It's somewhat involved.
Comment on attachment 48224 [details] [diff] [review] Suggested fix sr=mscott Thanks for the explanation guys. Sounds like taking it out is the right thing to do then. One thing to check for before checking in, make sure the icon isn't showing up in the standalone message window or the alternate 3-pane window. I think they all get it from the overlay you changed but I'm not 100% positive.
Attachment #48224 - Flags: superreview+
the standalone message window seems to alreaby be lacking the lock icon. I'll let Kai test his patch with the various versions of the 3-pane window.
Javi, can you please review?
Status: NEW → ASSIGNED
Sorry, for the spam, adding Javi to cc list. Can you please review?
Comment on attachment 48224 [details] [diff] [review] Suggested fix r=javi
Attachment #48224 - Flags: review+
I tested that both variations of the mailnews window no longer show the lock icon. The standalone also does not contain it. Patch checked in, marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified on 11/14 Win2000 trunk build.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: