Closed Bug 74320 Opened 24 years ago Closed 4 years ago

[Classic and Modern] add "weak crypto" lock icon

Categories

(SeaMonkey :: Themes, defect)

Product:
SeaMonkey
Component:
Themes
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jgmyers, Unassigned)

References

Details

(Whiteboard: icon)

Attachments

(3 files, 5 obsolete files)

Updated New Lock Icons (Color Chart) 1-24-03
120.36 KB, image/png
Details
Example
14.14 KB, image/png
Details
New Mozilla Locks
12.42 KB, application/x-zip-compressed
Details
When PSM2 lands, it will distinguish between strong and weak SSL ciphers, setting the level of the security-button to "low" for weak sites. securityOverlay.css currently displays lock-secure.gif for both "high" and "low". The theme should be using an icon other than lock-secure.gif for "low". The two alternatives are: 1) Design a new icon for weak sites 2) Use lock-insecure.gif for weak sites. My personal preference would be (2), as 40 bit ciphers offer virtually no protection at this point (per http://www.counterpane.com/keylength.html) and that would be the simplest and easiest interface for a user to understand.
(The Modern counterpart to this is bug 74322).
OS: Windows NT → All
Hardware: PC → All
Just tell me what attribute you set on the #security-button element to indicate "weak crypto" and I'll update the CSS to show the correct image.
Status: NEW → ASSIGNED
*** Bug 74322 has been marked as a duplicate of this bug. ***
We set the value of "level" to "low" in the weak crypto case.
Secure sites should display some kind of "locked" icon, otherwise users will be confused. This means that option 2 is out (in my opinion). The current icon should be displayed until a new one is designed to represent the weaker modes. If a user doesn't want weak encryption, they should just turn off the weak ciphers.
The old summary: [Classic] add "weak crypto" lock icon changed to The new summary: [Classic and Modern] add "weak crypto" lock icon
The old summary: [Classic] add "weak crypto" lock icon changed to The new summary: [Classic and Modern] add "weak crypto" lock icon
Summary: [Classic] add "weak crypto" lock icon → [Classic and Modern] add "weak crypto" lock icon
Blocks: 88358
Mass reassigning my theme bugs to Shuehan.
Assignee: hewitt → shliang
Status: ASSIGNED → NEW
need new icon
Assignee: shliang → marlon
The "weak crypto" icon needs to convey two distinct bits of information: (1) encryption is active, and (2) the encryption is not the strongest form offered by Mozilla. The current crypto icons have two variations: (a) a line drawing of an unlocked lock on a gray background, and (b) a line drawing of a locked lock on a yellow background. One option would be to indicate strong crypto with the current line drawing of a locked lock on a yellow background. Then, indicate weak crypto with a locked lock, gray background. The lack of encryption would still be indicated with an unlocked lock, gray background.
Whiteboard: icon
Target Milestone: --- → mozilla1.0.1
Another thing. The "weaker crypto" icon should not send the message that the level of security is useless. The "stronger crypto" icon should not send the message that the level of security is perfect. Thus, my earlier suggestion in my previous comment should probably not be implemented without modification. How about a yellow background for both icons? For weaker encryption, we could use a dark shade of yellow. For stronger encryption, we could use a bright shade of yellow. For both icons, to indicate imperfect security (as all security is necessarily imperfect), the icon could be shaded progressively darker from left to right.
Proposed relnote: When visiting a SSL enabled site, the lock icon will take on a yellow background, and will not indicate the relative strength of the SSL encryption used.
Keywords: relnote
Attached image Concept Encryption Icon Idea (obsolete) —
I have been thinking about this for some time, and I think this might work. Please refer to the attachment I have made. There were two ideas. The first one is a standard color code for the locks Red for 40 bit encryption, yellow for 56 bit encryption and finally Green for 128 bit encryption. The second idea is to include the level of security as visible text above or next to the locked icon. Also on the MouseOver for the lock icon, the pop-up help window should inform the user what level the encryption is in addition to who has signed it.
The first idea does not work for people with red/green color blindness. The underlying code makes no distinction between 40 and 56 bits. They are both low security.
Thank you for working on this bug. We need to build on your work. The color green usually means "It's safe to go." We should not convey such information ever because 128 bit SSL encryption does not equal 100% assured security. As Bruce Schneier has observed, there are always ways to circumvent cryptography through such tactics as social engineering or password guessing. We should not give users a false sense of security. Furthermore, although 40 bit is not as strong as 56 or 128 bit, it is still better than no encryption. By using the color red for 40 bit encryption, many users will get the impression that they should stop and not proceed. Many users will mistakenly think that no encryption (gray) is better than 40 bit encryption (red). We should have a gray, unlocked lock icon for no encryption. For 40, 56, and 128 bit encryption, we should have a gray, locked icon on a yellow background that gets progressively brighter. The darkest background would be for 40 bit. The brightest background would be for 128 bit encryption. We should not use the colors green or red. Colors other than green or red would work.
Why not make the strong crypto icon have a locked locl with a green, or blue background, and the weaker crypto icon with a yellow, or red background?
Please not green or red. Any colors but those. Green = safe to go. Red = not safe to go. Those are not the messages we are trying to send. The facts are: Strong crypto does NOT = perfect safety. Weak crypto does NOT = guaranteed danger. No crypto does NOT = guaranteed danger. The messages we should be sending are: Strong crypto = best security Mozilla offers, but it isn't absolutely perfect. Medium crypto = in between strong and weak. Weak crypto = low security, but not guaranteed danger, either. No crypto = Your safety is in your hands, but not guaranteed danger, either. The colors green and red should not be used here. Green says that safety is perfect when that is false. Red says that danger is guaranteed when that is false. Any other color would be fine.
I personally don't like the color-code idea. Too hard for users to figure out what's what. I cast my vote for Matthew Kruer's second idea: > The second idea is to include the level of security as visible text above or > next to the locked icon. It's simple, and it works. People aren't going to miss the loss of real estate on their status bar. (Why *is* there a second text area just to the left of the online/offline indicator though?)
Thanks for the vote. Looking at what has been stated before about the idea for color for the locks. You can’t use red, yellow, green color because it gives people get a false sense of security, and on top of that, you can not use certain color together because of colorblind people. I think the only viable option is to simply include text to say what encryption level you are currently using. It better then coming up with some arbitrary color/icon scheme, and the text says exactly what it means. Also depending on how it’s implemented the text would not be limited to just 40, 56, 128 bit encryption, but higher levels such as (I think its PGP’s) 1024 bit encryption. I think that this is the simplest answer to an impossible problem.
Yes, you can use yellow. Yellow means "caution" and thus it is appropriate at any level of encryption. We should put any written text in a tooltip. Otherwise, it will be a distraction. Just make the locked icon yellow, and make the yellow color progressively brighter for higher levels of encryption.
Attached image Encyrpted page status (obsolete) —
I have to respectfully disagree. Some people are not as visually acute to color changes as you are, and by simply increasing the intensity of the yellow color, I doubt people would see a difference. So to show that this text display of the encryption level would not be glaring to some, I made a quick pic. I did two things first I inverter the color so now the lock it self is yellow, not the background, and the second I add the 128-bit text to the right as not to be confused with the connection indicator. I think this works the best. If people don’t like seeing the text then simply add an option under security preferences not to show the level of encryption. Then we have the best of both worlds.
That's not a bad idea. It would confuse a lot of people, though. Your average user doesn't know the meaning of "128-bit." They would be confused as to whether that is "good" or "bad." I see your point about people with disabilities not being able to see progressive tints of yellow. Is there some document on the web about accessible color design? We don't have to use just one color, like yellow. We don't have to use yellow at all. We could use multiple colors. As long as we don't use the colors of red or green, any color scheme will at least not mislead users. The point of this bug is to have icons that readily distinguish between the relative strengths of encryption, and convey that information in a way that is instantly recognizable. I still think that choosing one color, and using progressive shades or tints makes the most sense. Less-sighted users could still resort to a tooltip that could appear when the mouse is pointed at the icon.
Another idea is to make the lock slightly bigger with higher levels of encryption.
Here's another vote against color coding. Progressive shades are only useful if you have something nearby to compare them with (e.g. something that shows all the revelant shades). A tooltip may be the best answer. I think many users have learned to equate "128 bit" with "good".
Please note earlier comments: there are only two levels, "high" and "low". Anything using fewer than 90 bits of encryption is reported as being "low". The theme is not given the information to distinguish between 40 and 56 bits. Given that designing a new icon is proving to be so problematic, I would like to reemphasize my suggestion to use lock-insecure.gif for weak sites. Connections using weak ciphers are indeed insecure against passive eavesdropping.
In order to get something done, that is somewhat simple and doable, here is what I purpose, a temporary/permanent solution. Currently when you are in a “secure” page, if you Mouse Over the Lock Icon, you will only get who the encryption is secured by, but not the level of encryption. This should be included in the Mouse Over information. As of right now you have to look at the Page Info under the Security tab to find the information. This is very inconvenient, especially when we are trying to have as much information about what type of encryption. This would be a simple solution This still does not replace the different icon for each level, but it would satisfy my requirement for having the level of information upfront, and we should be able to get this out by the 1.3b version in January. As for the Icons how about this idea. Three levels of encryption icons, High, Medium, and Low. Low is the lock in a bronze/copper color. Medium is the lock is a silver color High is a lock in gold color Everyone should be familiar with the idea of bronze, silver and gold. Its ambiguous, no red, green yellow, but anyone one knowing anything about awards will recognize that silver is better then bronze and the gold is better then silver. This also leaves room for a little bit of expansion, because in award, platinum is higher then gold, and visually it is represent by white silver.
Attached image Security Levels Based Upon Medals (obsolete) —
Here is an example of Security Levels Based upon Medal colors. Hope this clarifies things.
I like Matthew Kruer's ideas on tooltips and medal colors a lot.
I also like Matthew Kruer's medal idea. It seems like a better concept than the color-coding, which is not intuitive and can be deceiving (56bit being red/yellow). I'm voting for this bug. We missed the milestone. Can someone either update the milestone or blank it?
minusing for buffy. we have very limited design resources. We support recommendation 2 in the original report.
Keywords: nsbeta1-
Attached image New Lock Icons (Chart) (obsolete) —
I went ahead and created new icons both large and small for Mozilla. This is a chart of all of them. If these are acceptable and if anyone would like tem just contact me. I have them all in PNG format with transparent back grounds. Note: On the Large Icons, The reason why I included them is for people to more easily identify what the icon is. This would work with my above mentioned “display the level of encryption in the mouse over” the icon would be placed on the left side of the box and all the information would be displayed on the right side. Also in the Privacy and Security section of the preferences I would these to be included also along with a description.
Attachment #103302 - Attachment is obsolete: true
Attachment #109513 - Attachment is obsolete: true
Attachment #109818 - Attachment is obsolete: true
Excellent icons. Just one point of constructive criticism. To my eyes, the posted icon for weak encryption looks too reddish. The bronze medal has some red in it, true, but it is closer to brown than red. The weak encryption icon should have the brownish hue of the bronze medal. Here's a close-up of the Olympic medals awarded at Salt Lake City: http://web.knoxnews.com/web/kns/sports/olympics/art/medals1000.jpg
Please try to duplicate the colors from the above medals URL exactly. They are quite distinct to a person with red-green color blindness, whereas the locks in the above attachment are not.
Attached image Updated New Lock Icons (Color Chart) (obsolete) —
Andrew Hagen: “Excellent icons. Just one point of constructive criticism. To my eyes, the posted icon for weak encryption looks too reddish. The bronze medal has some red in it, true, but it is closer to brown than red. The weak encryption icon should have the brownish hue of the bronze medal.” There is a simple answer to this the Original color was Copper not Bronze, and copper is more towards the Orange/Red then Bronze, but I have added the Bronze color and there is barley a noticeable difference so I had to exaggerate it by making it half as bright. Nelson Bolyard: “Please try to duplicate the colors from the above medals URL exactly. They are quite distinct to a person with red-green color blindness, whereas the locks in the above attachment are not.” What colors Exactly are you not distinguishing between? -------- I took a snap of the pallet from each of the medals, but when I imported the color into my master gray scale image, because the hue of the master is so simple compared to the hue of the medal color, the images came out looking like $#!^. (Not to get technical but the master has so simple a hue that when it tries to match colors it end up using only ~16 of them out of 256, so I had to color it by hand.) I exaggerate some of the colors to be more perceptible for color blind people now it should look like the lighter the images become the higher the security. Pull out the turkey and stick a fork in it. I think it’s done!
Attachment #111965 - Attachment is obsolete: true
Those are fantastic. I like the ones on the far right-hand side the best. Are those the ones you're recommending? It would be great to have this for 1.3.
Flags: blocking1.3b?
Keywords: mozilla1.3
Yes those are the ones I am recommending. I may make a slight change to the Combo Gold to make it darker so it will be more distinctive for those with color blindness, but I do not think that it will affect the overall color. Other then that I think this is done. Now if someone will just implement it. We also need to come up with how the locks will be displayed or should I say at what level they will be displayed at. Right now I believe the lowest encryption there is, is 40bit and the highest I have seen is 4096bit Knowing that here is what I have come up with. Bronze < 63bit Silver 64 to 127bit Gold 128 to 255bit Platinum > 256bit This is totally arbitrary but seems to work well this way. Note: I want to include Platinum because it only a matter of time before that becomes a common standard for web encryption. And looking far into the future the next generation the numbers will be revamped to Bronze <127bit Silver 128 to 255 Gold 256 to 512bit Platinum > 1024bit And onwards...
The only information the skin gets is whether or not there are fewer than 90 bits. There are only four states to the "level" attribute: "high", "low", "broken", and not present.
Should a new bug be opened to provide the skin with more information?
Regarding comment 36, There are typically two different kinds of encryption, symmetric and asymmetric (a.k.a. public key), used in SSL and S/MIME. The two kinds of encryption have radically different key sizes. Key sizes for symmetric ciphers include 40, 56, 80, 112, 128, and 256 bits. Key sizes for asymmetric crypto include 512, 1024, 2046, and 4096 bits. Each category has its own ranges of weak, moderate and strong. NSS makes both the symmetric and asymmetric key sizes available through an API. If the symmetric key size is below 90 bits, or the asymmetric is below 1024, then the lock should signify weak crypto.
Nelson Bolyard: I think you just validated my point for more then the 3 colors so using what you said: “Key sizes for symmetric ciphers include 40, 56, 80, 112, 128, and 256 bits. Key sizes for asymmetric crypto include 512, 1024, 2046, and 4096 bits.” You come up with something like this Symmetric ciphers Bronze <=63bit Silver 64 to 127bit Gold 128 to 255bit Platinum >=256bit Asymmetric crypto Bronze <=1023bit Silver 1024 to 2045bit Gold 2046 to 4095bit Platinum >=4096bit I don’t think that there is a need for different icons for different types of encryptions, as long as they provide similar protection. John G. Myers: “The only information the skin gets is whether or not there are fewer than 90bits. There are only four states to the "level" attribute: "high", "low", "broken", and not present.“ I’m glad I stepped in and made the icons when I did. If the original Idea was to have an unlocked icon for encryption less then 90bits, just imagine the utter confusion that using an open lock to represent some of the lower encryptions would have caused. People would start to wonder if all encryption were broken. And then you would get a whole new bunch of bugs complaining about the broken encryption. Andrew Hagen: “Should a new bug be opened to provide the skin with more information?” I don’t think we need to. Essentially that is what this “bug” is already. So looking forward. What needs to happen now is take the existing levels and add to them. Using the information on what john said, “There are only four states to the ‘level’ attribute: ‘high’, ‘low’, ‘broken’, and ‘not present.’“ There would be two additional “medium” and “very high” I doubt this would be that difficult to do.
No, the security is only as strong as the weakest link. If any link is weak, then the user should see a lock that means weak. Otherwise, he should see a lock that means strong. We definitely do NOT want to make crypto seem any more complicated or any less black-and-white than it is now.
I should not have written: > Each category has its own ranges of weak, moderate and strong. I should have written: Each category has its own dividing line between weak and adequate length. There seems to be consensus in the cryptographic community that 90 bits is the dividing line for symmetric ciphers. A year ago there was (IMO) consensus that 512 was weak and 1024 was adequate for RSA keys, but now confidence in 1024 has begun to erode. But AFAIK there has never been any consensus about any dividing line beween medium and high. There's only good enough and not good enough.
Flags: blocking1.3b? → blocking1.3b-
Who will actually add the new lock icons to the skin? It's been almost two years since this bug was opened. We should get the issue over and done with already.
I decide whether a site is secure by looking for https:// in the Location bar. I recently sent out some sensitive info online, only to realize I was using 56- bit encryption all along. What can we do for poor souls like me?
If we're going to just have strong encryption and weak encryption icons, I think the gold and silver icons would work the best.
It seem to me that the original mandate has changes slightly from distinguishing between strong and weak (which are in constant flux and subjective) to more of an information based. The Icons now mean what range of encryption you are using from 1-bit to 256-bit symmetric and 1-bit to 4096-bit symmetric. For the average Joe Blow, this is a simply informative so they know that “hey you are not using a great encryption for sending this type of information” not to say “don’t send it” because the level is to low. You have to agree that any encryption is better then none. The amount of encryption you need is more based upon how secure you think the data should be during transfer. Some might think its fine that sending a number over using 64-bit encryption. The latest statement by distributive network RC5 (http://www.distributed.net/rc5/) says that the brute force cracking method takes a distributive network 1,757 days or 4.9 years to crack one message. True I don’t feel good about using 64-bit encryption as using a higher one, but I’m not going to lose sleep about it. Seriously would you use higher 90-bit encryption to a personal e-mail? Probably not, but I would like to know that I am using 128-bit encryption when sending my credit card information or 64-bit when sending sensitive e-mail, or even 56-bit for fun mail. Your argument, at least to me now, is more of a foot note on the encryption page. “The (insert organization here) believes that anything under 90-bit encryption is a weak encryption and should not be used for sensitive data!” I may be totally wrong but I hope I am making a valid argument. As to your reference about the weakest link, yes this is also true, but it is far beyond the scope of this particular bug. I am more worried about someone hacking someone’s database that has my number then stealing it during transmission. There is no way for this group to prevent that type of threat therefore your weakest link has no relevance because the encryption is not the weak link, but rather the programs that use the encryption, including but not limited to Mozilla itself. But to clarify it for future reference, I will use the actual bit range that each color should represent. Fixes: replaced Combo Gold with Dark Gold to help the icons be more distinctive for the color blind.
Attachment #112260 - Attachment is obsolete: true
I find the multi-level chart very confusing, and I work in crypto. There is no way that my mother, or some NGO worker in the field is going to be able to determine if a particular color is 'safe' or not. Just stick with the "High" "low" "broken" "not Present" ideas. Trying to learn and remember more states is way to cumbersum. bob
Please explain these color charts you've attached. How many colors are you recommending? 4 or 8? Why are there two columns under "recommendation for final"? What is the difference between the two columns? Why are there two distinct colors described as "Dark Gold" under the heading of "recommendation for final"? Your ranges of numbers have symmetric and asymmetric ranges switched. I suggest you read http://theory.lcs.mit.edu/~rivest/bsa-final-report.ps, a paper by 7 of the worlds most distinguished cryptographers, before you dismiss the 90 bit number.
Attached image Example —
Q: Please explain these color charts you've attached. How many colors are you recommending? 4 or 8? A: There are only four icons, six if you include broken and unlocked, the color icons go in order towards greater encryption levels. Bronze = Low (less then 90-bit) Silver = Middle (say 90-bit or greater) Gold = High (128-bit or greater) Platinum = Spare or if implemented Very High (This is only my would be attempt to extend the levels higher as not to be short sighted, This is NOT a necessity, just something I would like to see included) The reason for the 2 sizes in purely for informational purposes: See attachment for example of how they would be used. Q: Why are there two columns under "recommendation for final"? A: Read below. Q: What is the difference between the two columns? A: As for the reason for the GREY SCALE, it you give an example of what color blind people would see. They are NOT additional, they are the same as there color counterpart to the left. As you can see all the colors ramp nicely. Q: Why are there two distinct colors described as "Dark Gold" under the heading of "recommendation for final"? A: I have no clue what you are taking about. The “color” across is a grey scale of the image next to it. If you are color blind then this is an error on my part, but they are suppose to be the same. I hope that clears things up for everyone.
With the gold/silver approach, we would probably want new "insecure" and "broken" images. If someone could attatch a .gif file for each state, I could generate a patch to add them to the skin. Detecting weak asymmetric keys is bug 134735. That bug is stalled awaiting direction from the security module owner.
color is not solely reliable for indicating a change in status such as this. I am resetting the target milestone, since this bug was minused, i can't work on it right now. Unless someone is willing or able to do this icon for 1.3 in their spare time. cc'ing gail white, might be able to help
Target Milestone: mozilla1.0.1 → mozilla1.4alpha
For the broken Icons, do we need to have a diffrent one for each of the levels of security?
We only need one broken lock icon. Broken is broken--there aren't different levels of broken.
OK I am about ready to post all the icons up here, but I need to know what format they need to be in. I currently have then in png for the higher bit color, and I also went to the trouble of using transparencies for the background, but I need to know if this will work or if they need to be converted over to gif’s without transparencies. Please advise, and I will make the final adjustment and post them. let try to get this finished before switching to Phoenix on the road map.
AFAIK, the patent on the compression method used in GIF has not expired yet.
I know about the Gif Patent, but I believe it expires sometime in 2003-2004, and I don’t think that it really matters, it the encoding process, and not necessarily the use that costs money. But then I have heard it both ways. Anyway looking at the JAR’s and looking at the lock icons I see that there is one called lock-mixed.gif what is the significance of this. I have not seen it used before. Can someone please explain how it is used. –TIA-
Please remember that the strenght of symmetric cipher (40, 56 or 128bits) does not tell you much about the SSL:s encryption strenght. Mozilla does not show asymmetric (RSA) keysize AT ALL. Having 128bit symmetric cipher with 512bit RSA means that SSL security is as insecure as it was with just 40bit symmetric cipher. Therefore Mozilla should also indicate or atleast allow users to manually check the RSA keysize. You cannot judge the encryption strenght by looking on at the symmetric cipher, you need to look at the asymmetric cipher also!
Attached file New Mozilla Locks —
This is all the locks for the proposed upgrade to the icon. In it, it has the following files in PNG format. I hope someone will take responsibility and just implement the update. Refer to example attachment for details. If you need any changes or other icons created let me know, and I will do my best to fill the request quickly. Broken_Lock.png Combo_Gold_Lock_Locked.png = High security > 128bit+ New_Dark_Bronze_Lock_Locked.png = Low security < 90bit New_Silver_Lock_Locked.png = Low security < 90bit to 128bit Platinum_Lock_Locked.png = Spare Unlocked.png Larger versions of the locks above, to be used in the description of the type of security Broken_Lock_Icon.png Combo_Gold_Lock_Icon.png New_Dark_Bronze_Lock_Icon.png New_Silver_Lock_Icon.png Platinum_Lock_Icon.png Unlocked_Icon.png
Just wondering what happen with this “bug” whether or not this is going into the realm of never going to be done?
About 7% of the Male population and about 0.4% of the Female population has some form of color vision deficiency. Any fix that relies on color alone may cause problems for these people. Because of this color alone should never be used to give important information like encryption strength. Netscape 3 and earlier used keys rather than locks to show encryption status, a key with one tooth was low level encryption, a key with two teeth was high level encryption. I Have no idea why this was abbandoned at Netscape 4 for the lock, but going back to the Netscape 3 style key icons would provided a fix. If we are going to stick with Locks it's important to insure that the *shape* of any icon changes to show encryption strength, not just the color.
Product: Core → SeaMonkey
Assignee: marlon.bishop → nobody
QA Contact: pmac → themes
Target Milestone: mozilla1.4alpha → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: UNCONFIRMED → NEW
Ever confirmed: true

No longer relevant as weak crypto is no longer a thing.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: