Closed Bug 74320 Opened 24 years ago Closed 3 years ago

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

Categories

(SeaMonkey :: Themes, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: jgmyers, Unassigned)

References

Details

(Whiteboard: icon)

Attachments

(3 files, 5 obsolete files)

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: 3 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: