If you visit an https site that presents a non-EV Certificate that has mixed SSL and non-SSL content on the page, Larry gives the same indications as if the site had no certificate and was not encrypted at all. If you do the same on a website that presents an EV Certificate, you get the Identity Verified green checkmark plus the text stating that the site is encrypted to prevent eavesdropping. This behavior is not terribly consistent. In my opinion, both results are incorrect. I don't think the mix of SSL and non-SSL content should really change the display relative to the site identity. After all, that really only refers to the identity of the site mentioned in the URL. As far as I know, in the it is all SSL case, that is all that is checked for, that it is all SSL. It matters not if all the content comes from the same server, uses the same certificate or comes from the same domain, just hat it is all encrypted. So, as ling as the Identity indicator does not say all the content comes from these people as identified by this certificate, as far as the Identity part goes whether or on it is all encrypted is immaterial. As far as the mixed content goes, I thing the text at the bottom about encryption needs to be altered to say something to the effect that not all the content is encrypted.

In the case where the site is mixing SSL content with non-SSL content, whether the SSL is EV or not, the identity really should be presented as unconfirmed. Asserting the identity of the page implies that what you are seeing is what the site intended you to see, but if there are non-SSL parts to that content, then they can be altered undetectably, so we can no longer say "yes, this is paypal, and you can make decisions about this site based on your trust relationship with paypal" since parts of it could be from non-paypal sources. Now, if SSL-verified paypal.com links to other sites using SSL connections, if they have image hosting off-site for instance, we can still confidently assert paypal's identity as the top level site, since we can confirm the identity and integrity of the base page, and of all the content. But in any event, there shouldn't be a difference in this behaviour between EV and SSL. Either we can confirm the content or we can't. There are several bugs already on breakages in our mixed content detection, but this is the first I've heard of EV and SSL getting different treatments. Moving to PSM, since (unless there's a bug there that I'm not aware of) Firefox just reflects the security state as sent from PSM.

OK. Unfortunately the only testcase I have for this is not with a Versign certificate. The site is https://getbids.com/ which uses a Comodo EV certificate, so in order to see the issue you need to add the following to nsIdentityChecking.cpp: { "1.3.6.1.4.1.6449.1.2.1.5.1", "Comodo EV OID", SEC_OID_UNKNOWN, "CN=UTN-USERFirst-Hardware,OU=http://www.usertrust.com,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US", "CN=UTN-USERFirst-Hardware,OU=http://www.usertrust.com,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US", "04:83:ED:33:99:AC:36:08:05:87:22:ED:BC:5E:46:00:E3:BE:F9:D7" },

(In reply to comment #1) > Moving to PSM, since (unless there's a bug there that I'm not aware of) Firefox > just reflects the security state as sent from PSM. > Well, I am beginning to think this has to be a Firefox bug, as the padlock in the status bar as well as pageinfo show the correct information. It is just Larry that does not.

Although I suppose the code here: http://lxr.mozilla.org/seamonkey/source/security/manager/boot/src/nsSecureBrowserUIImpl.cpp#1153 could be modified to only set STATE_IDENTITY_EV_TOPLEVEL if STATE_IS_SECURE is already set.

This resolves the issue for me.

This alters the EV cert case to work identically to the way the non-EV cert case currently does.

Comment on attachment 289973 [details] [diff] [review] Patch v1 I think this makes a lot of sense. Thanks.

Fixed as part of check in for bug 402574. Bill, thanks a lot for your help!