[spin off from bug 435035 comment #6] 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.

Yes, please. If we bring back the background color under the URL text (have been playing with Chrome lately and was reminded how much I really miss the reassuring gold/yellow background) then that could change red, too. There's also a bug on simply not loading insecure content on a secure page. That's the default with Opera and an option in IE. Don't load the content, and fire off a door-hanger notification that lets people add them if they explicitly choose to. If we did that then we'd definitely want this to remind the user they've taken that step for that page.

Some additional context here: Chrome tried having a skull and crossbones for mixed SSL, and after a few days of it scaring their users (as they accessed a variety of mainstream sites, like Gmail), they decided to pull the feature. There's a balance here between trying to convince sites to stop using mixed SSL, while still trying not to be so overtly negative that it scares users. Giving this more thought I think probably scaling our UI back to normal (non-ssl) in the case of mixed content makes the most sense.

(In reply to comment #2) > Some additional context here: Chrome tried having a skull and crossbones for > mixed SSL, and after a few days of it scaring their users (as they accessed a > variety of mainstream sites, like Gmail), they decided to pull the feature. Actually, Chrome differs between mixed-content <script> and mixed-content <img>. They treat them differently. We don't. Also, what version of Chrome are you testing this with? I'm still seeing the skull on Chromium 6. > There's a balance here between trying to convince sites to stop using mixed > SSL, while still trying not to be so overtly negative that it scares users. > Giving this more thought I think probably scaling our UI back to normal > (non-ssl) in the case of mixed content makes the most sense. I need some type of change in the UI to let me know that mixed-content is occurring... The broken lock icon used to provide that for me, but now that's gone. This is important for continued secure web development and just good web security in general.

>what version of Chrome are >you testing this with? I'm still seeing the skull on Chromium 6. I'm still seeing it on the developer channel. If they haven't pulled it on the main channel yet they are apparently about to do so (unless they just put it back), either way I'm told that it's pretty universally freaking out users.

I don't dispute that Reed needs that UI, but I don't believe our users do. Currently mixed content is treated as insecure, and that's how much I would expect users to trust it. Calling out the bustage as a nod to the fact that there might be a user expectation of security - that we might want a *present* indicator instead of an absent one, is an idea I'd absolutely support, but I don't believe it blocks the release to develop and deploy this UI in what might well be the last beta, post feature-freeze.

At the very least, Larry needs to indicate that there is mixed content. Presently we put the UI in a confusing state where there's Larry information saying the connection is encrypted and protected from eavesdropping, and shows the certificate, but doesn't show EV or SSL UI presentation and shows no indication that there's mixed content putting the user at risk.

(In reply to comment #6) > At the very least, Larry needs to indicate that there is mixed content. > Presently we put the UI in a confusing state where there's Larry information > saying the connection is encrypted and protected from eavesdropping, and shows > the certificate, but doesn't show EV or SSL UI presentation and shows no > indication that there's mixed content putting the user at risk. Bug 435035 fixed that, right? Do you have a test page handy where this doesn't work?

I guess I meant it should do it in a way that's user-visible. My eyes went right past that different string, and I was actually looking for it :( Could just be a problem with me, but I suspect that we're not doing as clear a job as we could be with the signalling of the change from SSL to mixed-content SSL, which is a HRM, DANGER! case.

I think Firefox should complain less about mixed display. It's crying wolf on Gmail, Reader, and Twitter. This is distracting and makes it harder for Firefox to promote other optional security features that might be more relevant (see bug 711816).

This should probably be wontfixed or duped to bug 724419 where the identity block is being changed. Either the feedback from this bug will be incorporated or it won't, it's not going to go anywhere on its own.