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

Status: RESOLVED FIXED

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

Description

[Jeremy M. Dolan]

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.

Comment 1

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Reporter: what theme/skin are you using?

Comment 2

[Jeremy M. Dolan]

The standard, default, whatever it's called this week. Clean profile.

Comment 3

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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.

Comment 4

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

->Browser, since Mozilla doesn't describe it either.
Changed summary to (hopefully) fit more themes and still make sense.

Comment 5

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Bugzilla puked while changing component.  Trying again.

Comment 6

[Jeremy M. Dolan]

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.)

Comment 7

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Chris, that sounds like a reasonable approach.

Comment 9

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

The tooltip is going to get longer, thus this bug depends on either bug 67127 or
bug 45375 for best results.

Comment 10

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: Patch v1

As written, fixing either 67127 or 45275 will make this work.

Comment 11

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

-> XP Apps: GUI Features

Comment 12

[alanjstr]

Why not make it something simple like "Warning: mixed content"

Comment 13

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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.

Comment 14

[[e-mail]]

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.

Comment 15

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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.

Comment 16

[Raanan Barzel]

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

[Francois Ingelrest]

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.

Comment 18

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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.

Comment 19

[Raanan Barzel]

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

[(Don't use, old account) - Kai Engert]

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.

Comment 21

[Raanan Barzel]

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.

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

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

[Raanan Barzel]

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.

Comment 24

[Benjamin Smedberg]

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

Comment 25

[chris hofmann]

sounds like we are going to have to try and deal with this post 1.0.

Comment 26

[Daniel Veditz [:dveditz]]

This needs to be fixed in all browsers-->core security

Comment 27

[Daniel Veditz [:dveditz]]

*** Bug 288609 has been marked as a duplicate of this bug. ***

Comment 28

[Chris Beard]

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

Comment 29

[Benjamin Smedberg]

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

Comment 30

[Asa Dotzler [:asa]]

not going to block our branching.

Comment 31

[Nick Michaluk]

Looks like my report, bug 263182, may be a duplicate of this

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

Bug 263182 fixed the dialog behind the lock, but this report is right, the tooltip still implies that the page is signed & secure.

Comment 33

[:Gavin Sharp [email: [e-mail]]]

Taking.

Comment 34

[Mike Beltzner [:beltzner, not reading bugmail]]

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"

Comment 35

[Daniel Veditz [:dveditz]]

(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".

Comment 36

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 37

[:Gavin Sharp [email: [e-mail]]]

Attachment: 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.

Comment 38

[Mike Beltzner [:beltzner, not reading bugmail]]

Gavin: that's probably the right thing to do. I've forked simplification discussion to bug 315141.

Comment 39

[Nelson Bolyard (seldom reads bugmail)]

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

[Kai Engert (:KaiE:)]

> 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

[Kai Engert (:KaiE:)]

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.

Comment 42

[Mike Beltzner [:beltzner, not reading bugmail]]

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

[Kai Engert (:KaiE:)]

> 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

[Robert Parenton]

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

[Kai Engert (:KaiE:)]

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...

Comment 46

[Nelson Bolyard (seldom reads bugmail)]

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

[Julien Pierre]

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.

Comment 48

[Nelson Bolyard (seldom reads bugmail)]

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?  

Comment 49

[Daniel Veditz [:dveditz]]

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

[Kai Engert (:KaiE:)]

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.

Comment 51

[Nelson Bolyard (seldom reads bugmail)]

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

[Julien Pierre]

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).

Comment 53

[:Gavin Sharp [email: [e-mail]]]

Attachment: 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.

Comment 54

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 55

[Kai Engert (:KaiE:)]

Attachment: 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".

Comment 56

[Kai Engert (:KaiE:)]

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

r=kengert
assuming this patch is used in combination with the other one

Comment 57

[Daniel Veditz [:dveditz]]

Comment on attachment 202995 [details] [diff] [review]
patch v3 addition - to achieve wording consistency (checked in)

sr=dveditz

Comment 58

[Daniel Veditz [:dveditz]]

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 59

[Daniel Veditz [:dveditz]]

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

sr=dveditz

Comment 60

[:Gavin Sharp [email: [e-mail]]]

(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)

Comment 61

[:Gavin Sharp [email: [e-mail]]]

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 62

[:Gavin Sharp [email: [e-mail]]]

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

Comment 63

[:Gavin Sharp [email: [e-mail]]]

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

Comment 64

[:Gavin Sharp [email: [e-mail]]]

Both patches checked in, marking fixed. Thanks all!

Comment 65

[:Gavin Sharp [email: [e-mail]]]

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;