Currently the identity UI in Firefox 3 treats sites with mixed content as unencrypted. This is not particularly deceptive, since a site with mixed content is not functionally more secure than one with no encryption - attackers can easily undermine the retrieval of http page content or scripts in order to access "secure" portions of the page. It does, however, make it difficult to diagnose some situations where a site appears to be https, but "Larry" has no information (e.g. bug 434734). Once we are unfrozen, we should consider special casing here.

Alex, Dao, what do you think, if we're changing the string to indicate this difference, should we bring some version of the broken padlock into Larry as well? Dao's got this bug blocking bug 514475, which is about removing the padlock from the status bar - if we're doing that, we'll lose the only use of that icon - and the existence of this bug suggests that we consider the distinction to be worth-making. I've seen a surprising number of user-education sites recommending people look for the "https" - a broken padlock in the UI would hammer home the danger. I think I just talked myself into us wanting to do that, given that we do display the padlock in Larry when encrypted. I think the code's fine, Dao, but I don't love the text. "Unauthenticated content" sounds like jargon, but also doesn't tell you why you care. The other two versions of that text talk about protecting (or not) from eavesdroppers, which (I hope) helps people make a decision about what kind of information to exchange. What about: "Your connection to this site is only partially encrypted, and does not prevent eavesdropping." Still awkward? I'd also love it if we had a test for the correct behaviour of these states, given that browser-chrome/mochitest support this now.

(In reply to comment #2) > Alex, Dao, what do you think, if we're changing the string to indicate this > difference, should we bring some version of the broken padlock into Larry as > well? That icon doesn't exist at this point, so I'd prefer spinning it off to a new bug. I don't think this is important enough to block this bug and bug 514475. > "Your connection to this site is only partially encrypted, and does not prevent > eavesdropping." Fine by me. I copied the current text from the lock tooltip.

with the suggested string change

(In reply to comment #3) > (In reply to comment #2) > > Alex, Dao, what do you think, if we're changing the string to indicate this > > difference, should we bring some version of the broken padlock into Larry as > > well? > > That icon doesn't exist at this point, so I'd prefer spinning it off to a new > bug. I don't think this is important enough to block this bug and bug 514475. Filed bug 514658.

This is likely outside of the scope of this bug, but there are two things on my mind about mixed SSL. First, beltzner recently tweeted: >just realized that he paid for #TIFF09 tickets using a mixed-SSL form at a URL >that included the IP, port & .EXE name of the fulfillment app As johnath has correctly pointed out a bunch of times, it is difficult to notice the absence of something, which is probably what led to beltzner making the purchasing mistake. Secondly, the mixed SSL case always ends up with us saying "good and bad" (lock, but it has a error over it), instead of saying just good or just bad. So what if we actually switched the site button to red in the case of mixed SSL. if you are on a site and about to make a purchasing decision, you have a nice peripheral indication of "don't, you aren't really secure." You no longer have to notice the absence of something, and we make a clear statement on the side of bad, instead of trying to say both simultaneously. Clicking on the site button provides the same text, but red larry and an unlocked lock.

Comment on attachment 398449 [details] [diff] [review] patch v2 This is ok, but "partially encrypted" still seems to mix good and bad. Perhaps something more along the lines of "This web sites encryption is not set up correctly" (clearly bad)

Also, aside from submitting information, the mixed content could result in a third party changing the information shown on the page (right?), so I think it makes sense for us to raise a flag in terms of the identity (red larry).

(In reply to comment #6) > So what if we actually switched the site button to red in the case of mixed > SSL. if you are on a site and about to make a purchasing decision, you have a > nice peripheral indication of "don't, you aren't really secure." It's not less secure than a site without any encryption, though. While the red would be useful to the site owner, it seems misleading to the user.

Yeah, but isn't tried and failed worse than didn't try. The site trying (and failing) to add encryption indicates that the integrity of the content or information submitted is increasingly important. Not encrypted, not very important content = neutral grey Not encrypted, important content = red encrypted, important content = neutral blue (neutral since you could be talking to anyone, but noticeably different) extended validation, important content = green.

I don't think you can always assume there is "important content" on the page just because SSL is used. Sometimes, it's just the login process that needs to be secure because the credentials could be used to gain access to other systems. One example is our university information portal. It requires a login to display personalized content that consists mainly of faculty news and summaries of recent activity around the campus (which I would hesitate to call "important content"). Yet it triggers the mixed content warning due to non-SSL images included as part of RSS feeds, which are outside our control. Though I guess we could block non-SSL images there or redirect to a non-SSL URL after login to avoid the "red larry".

Anyway, red larry should be a separate bug.

>Anyway, red larry should be a separate bug. yep, filed follow up bug 515562

Comment on attachment 398449 [details] [diff] [review] patch v2 Code looks good. Can we get a test that just loads a mixed content page and verifies the mode is set correctly?

Comment on attachment 400023 [details] [diff] [review] test added a191=beltzner

(In reply to comment #17) > (From update of attachment 400023 [details] [diff] [review]) > a191=beltzner The flags have it right and I'm sure dao wouldn't push it anyhow, but just to be abundantly clear, here - this is a192 - 1.9.1.x is not taking strings.

This should really wordwrap, it makes the Larry dialog overlong. Follow up bug, Dao?