The default bug view has changed. See this FAQ.

HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering

RESOLVED FIXED in mozilla1.8.1

Status

Core Graveyard
Security: UI
P1
major
RESOLVED FIXED
13 years ago
6 months ago

People

(Reporter: Jeremy M. Dolan, Assigned: Gavin)

Tracking

({fixed1.8.1})

Trunk
mozilla1.8.1
fixed1.8.1
Bug Flags:
blocking-aviary1.0 -
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [affects l10n] [asaP1] [kerh-coa])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

13 years ago
Logging in to my Citibank account last night, I noticed the lock icon in the
bottom-left had a red slash through it. Hovering over it simply said "Signed by
Verisign Trust Network", or somesuch. Double clicking and looking through all of
the properties showed nothing wrong. Wasn't expired, the names matched, all of
that stuff.

Web search, bugzilla search, and IRC channels turned up no hints as to what this
ominous red slash meant. With all the Citibank fishing scams lately, I was quite
unnerved about logging in to my account, but had to anyway after an hour or so
of investigating turned up nothing.

Whatever this red slash is, mozilla needs to VERY CLEARLY indicate what's going on.

Linux Firefox 0.9.1.
Reporter: what theme/skin are you using?
(Reporter)

Comment 2

13 years ago
The standard, default, whatever it's called this week. Clean profile.
According to discussion in Bug #251472, "The lock with the slash through is
because it's a secure page which has content (images) loaded from an insecure
location...".  This is bad UI though.  It should explain better when you hover.
OS: Linux → All
Hardware: PC → All
->Browser, since Mozilla doesn't describe it either.
Changed summary to (hopefully) fit more themes and still make sense.
Assignee: bugs → general
Component: Toolbars → Browser-General
Product: Firefox → Browser
QA Contact: bugzilla → general
Summary: red slash through HTTPS secure lock icon, no indication what it means → HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering
Target Milestone: --- → mozilla1.8beta
Version: unspecified → Trunk
Bugzilla puked while changing component.  Trying again.
Target Milestone: mozilla1.8beta → ---
(Reporter)

Comment 6

13 years ago
Well, I must say, a small visual indication rather than a popup warning is a
vastly improved experience for mixed-mode https pages. But I think a big red
slash is way too ominous for this degraded mode, unless there is a huge
potential for information leakage that I'm not informed about, as all cases I've
ever seen have just been harmless sites set up poorly.

The red-slash is a lot more scary than a page without the lock icon at all.
Submitting, credit card info to a company I trust, without encryption, isn't too
ridiculously risky, in my opinion. A big red warning graphic (apperantly)
indicating that something's already fishy with this site was a lot more
worrysome to me.

Though with a tooltip and a better icon, this is a huge usability win. Bravo, UI
folks, fantastic idea. It's a wonder it wasn't thought of 10 years ago. (Sorry
though, no great suggestions offhand for what the visual indication SHOULD be.
Perhaps a slightly greyed out lock? Firefox may have some more flexibility for
presentation here with the new secure page indicator UI on the trunk.)
Flags: blocking-aviary1.0RC1?
Jeremy, the issue of how ominous the icon looks is up to skin designers.  I do
think it's good to make it look dangerous, because it's possible you're looking
at a page with an insecure subframe from a malicious site.  Knowing that you're
getting some insecure data is good.  But I'm not a UI guy.

Anyway, after some hunting, I think a tooltip could be added/modified by adding
a string to
http://lxr.mozilla.org/seamonkey/source/netwerk/resources/locale/en-US/security.properties#51
called something like "SecurityButtonMixedEncryptionTooltipText" but less
ridiculous, then moving the code from
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/nsBrowserStatusHandler.js#380
up a few lines into the switch(), to append the mixed-encryption text in the
mixed security case.  The guys in #developers are busy right now, but if I get a
chance to run this by them and they think that's a good solution, I can probably
implement the change.
Chris, that sounds like a reasonable approach.
Flags: blocking1.8a3?
The tooltip is going to get longer, thus this bug depends on either bug 67127 or
bug 45375 for best results.
Status: NEW → ASSIGNED
Depends on: 45375, 67127
Created attachment 153847 [details] [diff] [review]
Patch v1

As written, fixing either 67127 or 45275 will make this work.
Assignee: general → cst
-> XP Apps: GUI Features
Component: Browser-General → XP Apps: GUI Features
Attachment #153847 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #153847 - Flags: review?(neil.parkwaycc.co.uk)

Comment 12

13 years ago
Why not make it something simple like "Warning: mixed content"
I copied the wording from the original "mixed content" warning text.  I figured
the user might still care who it's signed by, and not know what "mixed content"
is, unless they remembered the original annoying dialog they dismissed without
reading.

Of course, there's a whole other bug with that...
https://www.andrew.cmu.edu/~cst/securetest.html contains an iframe signed by
verisign, but Moz only tells me it's signed by Thawte.  If I didn't trust
Verisign, that might be a problem.
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-

Comment 14

13 years ago
Comment on attachment 153847 [details] [diff] [review]
Patch v1

Personally I think a better place to fix this would be in nsNSSCallbacks.cpp,
because otherwise you're never going to be able to localize this properly.
Attachment #153847 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #153847 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #153847 - Flags: review-
I traced through the code again after modifying my testcase to use Google
instead of non-SSL Verisign, and it only runs through once (when it loads the
actual page).  At that point, everything is secure, so sslStatus is secure/not
broken.  When the browser loads the Google iframe, this code doesn't get run, so
I can't change the tooltip from there.

The JS reads the SSL status from nsIWebProgressListener, not its
"getBrowser().securityUI", so unless whatever component actually knows that the
state is broken can also set the properties of "getBrowser().securityUI", the
change has to live in JS, or something bigger has to be done.
Target Milestone: --- → Future
Keywords: helpwanted

Updated

13 years ago
Flags: blocking-aviary1.0?

Comment 16

13 years ago
If Firefox is going to be released to the public at large the current solution
of slashed lock is totally inacceptable. Non-specialist users will never
understand why their bank connection is considered only partially secure. The
reasoning behind the slashed lock may be right, but will not sell. What are
users expected to do? Tell their bank that the lock is slashed? You know the
answer: use IE.

Having secure and unsecure data on the page may be correct if the data which has
to be secured is secured. Can this be detected? If not, then the connection
should be displayed as unsecure, period.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040811
Firefox/0.9.1+ 

(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040811
Firefox/0.9.1+) 

Comment 17

13 years ago
I totally agree with Raanan, I myself had to search why my bank connection was
considered insecured. I did understand it only after having found this bug, and
I still don't know which elements are insecured, since I found nothing that come
from a non-secured website.
When someone tells me where to make the fixes (or I have enough time to hunt
around on my own), I'll fix this.  I can think of an ugly hack to do it in JS,
but it would be r-'ed.  Otherwise, it'll sit until someone who has the knowledge
and motivation fixes it him/herself.
Assignee: cst → timeless
Status: ASSIGNED → NEW

Comment 19

13 years ago
After re-reading the posts here, a question came to my mind, which i hope
someone can provide an answer for: is there a standard defining what a "secure"
page should contain and what it should not contain? Unless such a standard
exists and can be pointed to when raising the issue with banks and other service
providers using this technology it will be difficult to justify "half secure"
locks. If the standard exists, then this half-secure lock should be defined
there and only then used in applications.

Comment 20

13 years ago
In my opinion, a page is secure (and deserves a solid lock icon), only if all
displayed information, including all frames and images and plugin objects, was
transfered over an encrypted channel, and for each displayed piece of
information, the originating party used a valid (trusted) certificate.

That is, secure means, for everything that is displayed
- we know it was encrypted during transmission
- we know for sure who sent the data, because the sender authorized itself


Now what is the definition of a "mixed security lock" or "half secure lock"?

Whenever there is at least one piece of displayed information that arrived
without encryption or from an untrusted origin, the "half secure lock" should be
used.

Or, in other words, if only "some" displayed content is secure, a mixed lock
should be shown.


However, Mozilla has a deficiency that is described in bug 135007.


As of today, if you look at a page that contains images, and the images have
been transfered without encryption, or has an untrusted origin, we still show a
secure lock icon!

We should really show a "mixed security" icon in that situation, but that
requires bug 135011 and bug 135007 to be fixed.


Unfortunately, until today nobody invested resources to fix this deficiency.

In my opinion, it was an unfortunate decision made by the original implementors
of security in Mozilla, to not care for this situation.

In my personal opinion, bug 135007 is much worse than this bug 251123.


Unfortunately, at the time of writing comments in bug 135007, it turned out to
be complicated to fix the deficiency, since the fix required the image library
to get enhanced and communicate the security status to the crypto component.

Please see the comments I made to bug 135011 and bug 135007 that I made over two
years ago.

Updated

13 years ago
Flags: blocking1.8a3? → blocking1.8a3-

Comment 21

13 years ago
Kai Engert is probably correct in the analysis of the security issue (comment
#20). However, I am not sure that it is up to Mozilla to set a standard if none
exists. In my opinion, if the approach suggested by Kai is to be adopted, it
must win acceptance in the security circles. Only then will it be possible to
refer to a standard when talking to third parties about the quality of their
security, and to develop the corresponding mechanisms to implement it.
In comment 20, Kai explains what the lock icon (and its predecessor, the 
key icon) has meant since the beginning of the Netscape/mozilla series 
of browsers.  He is not proposing any new standard, but merely explaining
the way things have been consistently for the last 10 years.

Comment 23

13 years ago
Well, things have not been consistent with Firefox since the issue was raised
here on July 2004. 

I was not implying that Kai was suggesting a new standard. I was merely saying
that it would be much easier for developers as well as users and information
providers to have a standard defining what a "fully secure" means and how to
consider a "partly secure" icon. 

There may not be a need for full security in all instances, and it should be
clear to a user what the "partrly secure" icon means, not in technical terms but
in functional terms. If my bank sends all the sensitive data encrypted over a
secure link but sends its logo unencrypted, then this may be OK - if the
standard says so - and no slashed lock should be displayed.

A user needs to have confidence in the system. Displaying a slashed lock, even
with an explanation (some items were not ...) does not help inasmuch as these
items are not identified. Once again, a standard will help users, information
providers and developers to work in confidence. If Mozilla considers this as an
importaqnt feature then it should promote an international (internet?) standard
to that effect. That will certainly help in marketing the compliant products.

This affects l10n, it needs blocking- or a string to land within 24 hours.
Whiteboard: [affects l10n]

Comment 25

13 years ago
sounds like we are going to have to try and deal with this post 1.0.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Product: Core → Mozilla Application Suite
This needs to be fixed in all browsers-->core security
Component: XP Apps: GUI Features → Security: UI
Product: Mozilla Application Suite → Core
Target Milestone: Future → ---
Flags: blocking-aviary1.1?
*** Bug 288609 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking1.8a3-
Flags: blocking-aviary1.0PR-
Whiteboard: [affects l10n] → [affects l10n] [asaP1]

Updated

12 years ago
Flags: blocking1.8b4+

Updated

12 years ago
Flags: blocking-aviary1.1?

Updated

12 years ago
Blocks: 300860

Updated

12 years ago
Blocks: 300861

Comment 28

12 years ago
is anyone working on this?  was nominated as blocking the branch for 1.8.  is
this really a blocker?  it looks like the sort of thing that could land after
the branch.

/cb
affects l10n, are we serious about branchpoint being the string freeze?

Updated

12 years ago
No longer blocks: 300861

Comment 30

12 years ago
not going to block our branching.
No longer blocks: 300860
Flags: blocking1.8b4+ → blocking1.8b4-

Comment 31

12 years ago
Looks like my report, bug 263182, may be a duplicate of this
Bug 263182 fixed the dialog behind the lock, but this report is right, the tooltip still implies that the page is signed & secure.
Taking.
Assignee: timeless → gavin.sharp
No longer depends on: 45375, 67127
Keywords: helpwanted
Target Milestone: --- → mozilla1.9alpha
Status: NEW → ASSIGNED
Priority: -- → P1
Suggestion for tooltips:

      lock: "Verified by %S and fully encrypted"
slash-lock: "Verified by %S but only partially encrypted"

or, if you share my suspicion that the names of signing agencies are meaningless less wordy:

      lock: "Fully encrypted"
slash-lock: "Partially encrypted"
(In reply to comment #34)
>       lock: "Fully encrypted"
> slash-lock: "Partially encrypted"

Encryption is only part of what SSL gives you. The more important part is the assurance--to the extent you trust the signing agency--that you're talking to the site you think you are.

People generally don't understand that and we're not going to educate them in the space of a tooltip, but using only "encrypted" reinforces their mistaken belief. Currently we're using the vague "Signed". May not clarify much, but at least it doesn't mislead. "Secured by" might also work.

slash-lock: "Verified by %S but only partially encrypted"

"Verified and encrypted" is great (if wordy), but in the slash-lock case it's "partially (verified and encrypted)", it's not just the encryption that's partial.

I don't want to lose the %s for the secure case, but we could lose it in the mixed case and say "Contains verified and un-verified content" (or signed and un-signed). Or since we don't like this state and want people to be suspicious of it, drop the positive and go with "Contains unsigned and unencrypted content/elements/whatever".
based on dveditz's comments, I'd suggest:

     lock: "Verified by %S and encrypted"
slashlock: "Contains unverified and unencrypted elements"

however, I'm still wondering if we need to use big words like "verified" and "encrypted" in the tooltip, as opposed to something simpler like:

     lock: "This page is secure (%S)"
slashlock: "This page is partially secure"

My feeling is that while these strings are less precise, they are more understandable by the common user. I'm not 100% convinced that we even need the %S to be shown in the tooltip, either. I'll defer to dveditz' judgement, however, if he feels that it's important we use certain key words in the tooltip.
Created attachment 201824 [details] [diff] [review]
patch v2

I chose simply "Contains unsigned content" for now to fit in with the current "secure" tooltip. I think that if the wording needs revisiting then it's probably best done seperately.

Seems like nsSecureBrowserUIImpl is the only one in position to know about overall page security status (since it determines it!), so the check goes there instead of in nsNSSCallbacks, which doesn't know about other loads. Ideally I think nsSecureBrowserUIImpl should construct it's own tooltip, getting the issuerName from mSSLStatus, and not depend on nsNSSCallbacks.
Attachment #153847 - Attachment is obsolete: true
Attachment #201824 - Flags: superreview?(dveditz)
Attachment #201824 - Flags: review?(kaie.bugs)
Gavin: that's probably the right thing to do. I've forked simplification discussion to bug 315141.
SSL never signs content, so the "contains unsigned content" tip is not too 
meaningful, and perhaps misleading (by implying that SSL content is signed).
 
SSL verifies the *source* of the content of an https page, 
(this is sometimes called the "authenticity" of the content") and 
(optionally, but typically) provides secrecy (encryption) of the content. 

One might say that the non-SSL components of a mixed page are 
unauthenticated and unprotected (unencrypted).
One might say that an SSL page is authenticated by %S and protected
(or encrypted).

Comment 40

12 years ago
> SSL never signs content

However, our current tooltip UI says "Signed by %S"

I see two possible strategies:


a) Change "mixed tooltip" only.

We continue with the current "good tooltip" message, that uses wording "signed by". 

If we do so, the wording for the "mixed" situation should be similar. Gavin suggested "contains unsigned". IMHO we should make it very clear that something is wrong with the currently displayed page. 

What about "Error: Only portions are signed by %S" ?


b) Change existing wording, too.

Follow Nelson's complaint, that "signed by" is inappropriate.
Come up with a better wording, that is clearly understandable for end users, and tells the truth.

Nelson's suggestion: "Authenticated by %S".

But is "authenticated" clear to the average user? I looked at "page info / security". In that dialog we say "Web Site Identify Verified". Why don't we follow that wording and use it in the tooltip, too?

Proposal for good tooltip: "Web Site Identity verified by %S."

Proposal for mixed tooltip: "Error: Only portions of this Web Site are verified by %S."

Comment 41

12 years ago
Comment on attachment 201824 [details] [diff] [review]
patch v2

I'm rejecing this patch for now, because we don't have a wording agreement yet. While the patch is fine for simple wording, we'd have to adjust it, should we decide to use %S in the wording.
Attachment #201824 - Flags: superreview?(dveditz)
Attachment #201824 - Flags: review?(kaie.bugs)
Attachment #201824 - Flags: review-
I'd suggest that we use this bug to fix the fact that the tooltip doesn't correctly indicate that there's a problem with the page, and then use bug 315141 to discuss revising both messages for clarity & accuracy.

One question that I've never had answered clearly: is something wrong when the page contains signed and unsigned content? Is there any legitimate case for that?

If not, then I'd suggest "Warning: Contains unsigned content"

Comment 43

12 years ago
> One question that I've never had answered clearly: is something wrong when the
> page contains signed and unsigned content? 

This scenario means, the web site authors failed in their attempt to provide a site, that uses secure protocols to transmit all displayed content.

If some of the shown content was not transfered using secure protocols, in my opinion, this is as bad as having no security at all. The user has no idea which portions on screen are "secure" and which are not, so the user should not trust any of them.

Rather than "mixed security" we should call it "broken security".


> Is there any legitimate case for that?

I'm not aware of intended cases. I think, when the browser displays that situation, the web site authors should be informed and fix their site.

Comment 44

12 years ago
FWIW, IE 7 is not going to display non-secure content on secure pages by default.

"In addition, users will no longer see the so-called Mixed-Content prompt, which read: This page contains both secure and nonsecure items.  Do you want to see the nonsecure items?  IE7 renders only the secure content and offers the user the opportunity to unblock the nonsecure content using the Information Bar.  This is an important change because very few users (or web developers) fully understand the security risks of rendering HTTP-delivered content within a HTTPS page."

From http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx

Comment 45

12 years ago
Yes, I know. But before we can do that, we must fix other bugs first, bug 62178 and bug 135007. Those bugs will have to provide the infrastructure, to allow us to actually block that content...
Regarding comment 44 and IE 7's UI changes, how does moving the user's choice
from a modal dialog to an "information bar" increase the security?

Comment 47

12 years ago
Nelson,

If I read this correctly, the answer is that IE won't even prompt the user and not display the insecure part of the mixed content - it will only show the secure part of the content, unless the user goes to the info bar and turns on the insecure part explicitly. Since there will be no dialog shown to the user that he can click through, I think security is improved.
IINM, the info/security bar is a thin bar that goes accross the top of the 
window that displays the page content.  It provides a means for the user
to "click through" and get the missing parts of the page.  The big  difference
seems to be that the dialog required the user to make a decision and click yes 
or no, and the new approach makes this choice optional, but no more difficult.

If the argument is that, given a choice, the users will always choose to 
display the missing content, then how is the new behavior more secure than
the old, given that both behaviors give the user a way to get the unencrypted
content?  
I think the argument is that when annoyed by a dialog box that defaults to "yes, show me the insecure content" users will choose to see the insecure content. And be annoyed that the browser asked.

This way users will *not* see the content by default. Inertia argues many won't then go turn it on, especially if the way to do so is in a bar that looks like the "annoying popup content" bar. And then if the user does turn on the content they'll have a clue which parts were insecure and will, one hopes, be suspicious of the new stuff that shows up. Sounds good to me, actually, better than saying "something somewhere did not use SSL--have fun guessing."

IE probably has to do this to provide some way to see these pages because both Netscape and Opera will show the full content (with a mixed icon, or in our case sometimes without the mixed icon if it's only insecure images).

Comment 50

12 years ago
Can we agree with the suggestion made in comment 42?
Which is,
- say "Warning: Contains unsigned content". 
  And NOT mentioning the name of the CA)
- move other rewording work to a separate bug.

In my opinion it seems to be a reasonable suggestion, as we currently indeed say "Signed By %s" in the user interface.

Nelson, David, Julien, if you agree with this proposal, I'm willing to grant r= to the patch.
How about:
Page contains some unauthenticated content.
or
WARNING: some content unauthenticated.
or
WARNING: some content not authenticated.

Is anyone willing to consider doing the "secure by default" thing, and 
displaying/using only the stuff received by https unless/until the user
asks it to also display the unauthenticated stuff?

Comment 52

12 years ago
Nelson,

Yes, I think it is a good thing to show only the content from authenticated sites by default, and have an option (but not a dialog with a prompt) to show it in the UI, uppon request. If the rendering engine allows, maybe that content should be shown in monochrome and the in  RED to show that it is the insecure content ;) Or even better, in big BLINKing red. I just talked to Nelson about it and he approves.

Re: the wording, I don't have strong feelings, but I think we should be more accurate. As you pointed out earlier, it isn't the content that is being authenticated, but the site. I would prefer if the UI talked about content from an authenticated site vs content from an unauthenticated site (or replace site with server if you prefer).

Updated

12 years ago
Whiteboard: [affects l10n] [asaP1] → [affects l10n] [asaP1] [kerh-coa]
Created attachment 202857 [details] [diff] [review]
patch v3 (checked in)

Here's the same patch as v2, with "Warning: Contains unauthenticated content" instead of "Contains unsigned content." per Nelson and Mike's suggestions. I think it's probably best to get this landed and then worry about perfecting the wording (for both cases) in bug 315141.
Attachment #201824 - Attachment is obsolete: true
Attachment #202857 - Flags: superreview?(dveditz)
Attachment #202857 - Flags: review?(kengert)
Attachment #202857 - Flags: review?(beltzner)
Comment on attachment 202857 [details] [diff] [review]
patch v3 (checked in)

r=me in that yes, we need a new tooltip, and this one is as informative as the tooltip for properly secured content.

Not sure if bug 315141 should block this one or not, but I should at least register the fact that I don't see the text of these tooltips as final.

Thanks, Gavin.
Attachment #202857 - Flags: review?(beltzner) → review+

Comment 55

12 years ago
Created attachment 202995 [details] [diff] [review]
patch v3 addition - to achieve wording consistency (checked in)

I'm fine with the wording suggested in the previous patch.
I suggest, if we indeed introduce the wording "authenticated", we should at the very least be consistent.

I'm attaching this additional patch that IMHO should be used together with patch v3.

It changes our corrent hovering text "Signed by" to "Authenticated by".

Updated

12 years ago
Attachment #202995 - Flags: review?(beltzner)
Attachment #202995 - Flags: review?(beltzner) → review+

Comment 56

12 years ago
Comment on attachment 202857 [details] [diff] [review]
patch v3 (checked in)

r=kengert
assuming this patch is used in combination with the other one
Attachment #202857 - Flags: review?(kengert) → review+

Updated

12 years ago
Attachment #202995 - Flags: superreview?(dveditz)
Comment on attachment 202995 [details] [diff] [review]
patch v3 addition - to achieve wording consistency (checked in)

sr=dveditz
Attachment #202995 - Flags: superreview?(dveditz) → superreview+
Comment on attachment 202995 [details] [diff] [review]
patch v3 addition - to achieve wording consistency (checked in)

>Index: security/manager/locales/en-US/chrome/pipnss/pipnss.properties

pipnss.jar appears to have been removed from Firefox (and in 1.0 contained only a contents.rdf). Is this part of the change expected to do anything?
Comment on attachment 202857 [details] [diff] [review]
patch v3 (checked in)

sr=dveditz
Attachment #202857 - Flags: superreview?(dveditz) → superreview+
(In reply to comment #58)
> >Index: security/manager/locales/en-US/chrome/pipnss/pipnss.properties
> 
> pipnss.jar appears to have been removed from Firefox (and in 1.0 contained only
> a contents.rdf). Is this part of the change expected to do anything?

Yes, pipnss.properties is now packaged in ab-CD.jar (see http://lxr.mozilla.org/seamonkey/source/security/manager/locales/jar.mn#11)
In fact, it looks to me like the other entity (from pippki.properties) isn't used anywhere. It dates back to when the file was originally added, so it could probably just be removed.
Comment on attachment 202857 [details] [diff] [review]
patch v3 (checked in)

mozilla/security/manager/locales/en-US/chrome/pipnss/security.properties;
new revision: 1.2; previous revision: 1.1
mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp;
new revision: 1.52; previous revision: 1.51
Attachment #202857 - Attachment description: patch v3 → patch v3 (checked in)
Comment on attachment 202995 [details] [diff] [review]
patch v3 addition - to achieve wording consistency (checked in)

mozilla/security/manager/locales/en-US/chrome/pipnss/pipnss.properties
new revision: 1.2; previous revision: 1.1
mozilla/security/manager/locales/en-US/chrome/pippki/pippki.properties
new revision: 1.4; previous revision: 1.3
Attachment #202995 - Attachment description: patch v3 addition - to achieve wording consistency → patch v3 addition - to achieve wording consistency (checked in)
Both patches checked in, marking fixed. Thanks all!
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Flags: blocking-aviary2?
Attachment #202995 - Flags: approval1.8.1?
Attachment #202857 - Flags: approval1.8.1?
Attachment #202857 - Flags: approval1.8.1? → branch-1.8.1?(kengert)
Attachment #202995 - Flags: approval1.8.1? → branch-1.8.1?(kengert)

Updated

11 years ago
Attachment #202857 - Flags: branch-1.8.1?(kengert) → branch-1.8.1+

Updated

11 years ago
Attachment #202995 - Flags: branch-1.8.1?(kengert) → branch-1.8.1+
Both patches landed on the 1.8 branch.
mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp;             1.48.2.3;
mozilla/security/manager/locales/en-US/chrome/pipnss/pipnss.properties;   1.1.8.1;
mozilla/security/manager/locales/en-US/chrome/pipnss/security.properties; 1.1.8.1;
mozilla/security/manager/locales/en-US/chrome/pippki/pippki.properties;   1.2.6.2;
Keywords: fixed1.8.1
Target Milestone: mozilla1.9alpha → mozilla1.8.1
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.