Jared, please explain a little what you mean by "Don't include." Does it mean "do not show 'https://' in the address bar in the mixed content case"?

Yes, it means we don't want to show 'https://' in the address bar in the mixed content case. We want to treat mixed content the same as non-https, but we will use a different icon (bug 747090).

First, I don't know what the new icon/indicator for the mixed content is supposed to look like, so maybe some of the issues I describe below are dealt with with that indicator. What I write below is based on the assumption that the indicator will be a little icon similar to the lock icon and the globe icon. For the most part, I think the changes I've seen regarding the identity block redesign seem great. But, I think this particular change (no scheme shown for mixed content) will be very problematic, because it would have a very negative effect on gmail, Google Reader, and probably many other mail- and mail-like web applications that load images from insecure domains. Consider this scenerio: 1. User is in GMail, security indicators are all OK-looking with the lock and the black "https://" shown in the address bar. 2. User opens an email with some hot-linked images in it. 3. The lock changes to something else and the "https://" goes away, because of the insecure content (the images). This very jarring effect would make it seem like the entire security of the page has been removed. This isn't really true; the situation is actually much more nuanced, as has been discussed in bug 62178 for a while. The majority of the time (AFAIK), mixed content is relatively benign (images and videos) and shouldn't affect the way the address bar looks, because the security of the whole page or the site isn't really affected by the insecure content. The security indicators up in the address bar should only change when there are possibly-dangerous types of mixed content (scripts, stylesheets, etc.), which is something that is much more rare. I am especially concerned that if we cry wolf for GMail and similar benign cases, then the mixed indicator will become just "noise" for the user and will not be helpful, which would be counter-productive. I think it might be a good idea to at least prioritize the other work regarding the identity block redesign ahead of this particular change, because I hope that whatever we decide for bug 62178 might help simplify, or slightly change, what should be done here.

I agree with Brian. Hiding https would also be extremely confusing; I'd wonder how I got redirected to http and immediately add https:// back in. It would also lead to the wrong URLs being copied/shared. It *might* make sense to *modify* the https in the mixed *scripting* case. (Perhaps cross out and turn red, like Chrome does for invalid certs.) But that should be a separate bug depending on bug 62178. And even then, just modifying the lock icon might be the appropriate level of warning and punishment.