User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140608211622 Steps to reproduce: Visit a non-https site (ex. http://www.ubuntu.com/) Actual results: The icon displayed by the url is the generic icon from https://github.com/mozilla/gecko-dev/blob/master/browser/themes/windows/identity-icons-generic.png Expected results: Https should be heavily encouraged by Mozilla, so the generic http icon should be switched to something that has negative feedback and warns the user more loutdly that their connection is insecure. I have attached some mockups of identity-icons-generic.png (with their corresponding svg vector graphics) that I propose as replacements.

This design is inspired from https://defuse.ca/web-browser-negative-feedback.htm

Added pull request: https://github.com/mozilla/gecko-dev/pull/36

This is a very bad idea, as a lot of websites even today don't have their HTTPS version. This can only result in users' fear that something is wrong with their computer, even though it really isn't. There is also a problem with some internet providers/public access points. Imagine you're sitting on an airport Wi-Fi, or some other public access point. Or you may have a bad timezone set on your computer - either way, on some HTTPS sites you get an Untrusted connection error. This is worse than browsing the non-HTTPS version of the site. The red broken padlock is just glaring at the user - and what is the user supposed to do? The user doesn't usually know the difference between HTTP and HTTPS (and that the "S" means Secure), and the fact that you're hiding the HTTP from the address bar doesn't help at all. If anything, I would suggest making it more obvious that user is on a secure page, though I have no idea how more obvious than a green padlock it can get. Or maybe we could warn the user when they're about to send some sensitive information through a non-HTTPS connection, such as credit card numbers or passwords.

I wouldn't say it's a very bad idea. It's a very good idea... in the long term. Implementing it now would be premature, probably. If all browser vendors got together and agreed to do this once HTTP/2 is implemented and rolling out, however, this would be a great improvement to overall security UI.

(In reply to Dave Garrett from comment #4) > ... in the long term. Implementing it now would be premature Yeah. Promoting HTTPS over plain HTTP is a good cause, but there are still far too many websites that don't support HTTPS at all, or do have the support, but aren't enforcing it (redirecting from http:// to https://). If this bug ever gets fixed, then I think Firefox needs at least a basic functionality of the popular add-on HTTPS Everywhere - i.e. if the address starts with http://, then try to find and load the secure version, and if that fails then make the padlock red/broken. I think the red color is too alarming to the user. It basically screams "Look out, this website is dangerous!". A simple gray broken padlock is enough.

I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https is now simply bad practice and harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections.

What you definitely *don't* want to do is give the user such negative feedback that they stop noticing when there's a direct problem (insecure HTTPS). A grey unlocked padlock would be a nice way to ease people into the idea that they are browsing a normal website that is insecure.

(In reply to Daniel Roesler from comment #6) > Mozilla should be a leader and push websites to start securing True, but we don't yet have much to push with. When HTTP/2 comes out, we will. HTTP/2 will be effectively HTTPS only and servers that want the better performance will have to use TLS 1.2 + the various H2 amendments to get it. (yes, H2C is a thing, however it's going to be boycotted by almost everyone) Once HTTP/2 is in full adoption, yes, this sort of proposal is a VERY good idea. Before then, however, it's hard to argue that now is the time to push. (In reply to Eric Mill from comment #7) > A grey unlocked padlock would be a nice way to ease people into the idea > that they are browsing a normal website that is insecure. Not a horrible idea, but let's be honest, anyone who will notice the difference between the current grey blob and a new grey blob will either already know enough about the situation and not care or won't be able to know what it is. Everyone else won't even notice. A slight icon change is not a real security improvement. For this proposal to have any real effect, it'll need to be an indicator that stands out as "wrong" only on sites that are out of the norm. (a red outlined identity box including "http://" would be preferable to just a broken red lock icon) For this to not just cause warning fatigue, we'll need to transition to a world where HTTPS is the norm first. HTTP/2 is the way to do that.

One good idea for the short term could be to use an insecure warning indicator like this only for unencrypted pages with password fields to start. There's no legitimate reason to have them not on HTTPS right now.

(In reply to Dave Garrett from comment #8) > Not a horrible idea, but let's be honest, anyone who will notice the > difference between the current grey blob and a new grey blob will either > already know enough about the situation and not care or won't be able to > know what it is. Everyone else won't even notice. Yeah...I agree. There still might be an opportunity to update the text and iconography in the popup box you see when you click the grey Earth icon for an unencrypted website to go beyond just "This website is not encrypted." (In reply to Dave Garrett from comment #9) > One good idea for the short term could be to use an insecure warning > indicator like this only for unencrypted pages with password fields to > start. There's no legitimate reason to have them not on HTTPS right now. Very much agree!

Ok, I've attached a mockup of a gray version of the broken lock. While I'm much more bullish on pushing for https, I agree that a transistion might work, too. Perhaps it could be gray for a few releases, then yellow, then red? That would give website websites reasonable warning that their users will soon see something red and scary if they don't switch to https.

I created a non-commercial Web site at <http://www.rossde.com/>. The cost of maintaining this Web site is merely the cost for hosting it. It carries no advertisements. I do not want the added cost of a site SSL certificate. Yes, there are free certificates available; but I have marked their roots as untrusted in my configuration. Think of all the other non-commercial, amateur-created Web sites that would be affected. Think of all the local government Web sites -- operated with limited budgets -- that would be affected. Think of all the blogs that would be affected. Think of all the freeware sources that would be affected. This concept seems intended to exterminate most of them. It is a very bad concept.

(In reply to David E. Ross from comment #13) > This concept seems intended to exterminate most of them. It is a > very bad concept. This bug is absolutely not intended to exterminate anyone. I also run a personal website (https://daylightpirates.org/), and the cost of maintaining it is also merely the cost of hosting it. You seem to be stuck on the cost of getting an SSL certificate yet reject the free options available. Can you elaborate more on why you view free certificates as untrusted? Also, I suspect that when secure connections are being pushed more by browsers, there will be more free certificate options available from more CAs. Heck, Mozilla's CA could even start to offer a free certificate with no warranty just for the personal/non-commercial sites.

(In reply to David E. Ross from comment #13) > Think of all the other non-commercial, amateur-created Web sites that would > be affected. Certificates need to be free with all domain purchases or we need a better system entirely, yes. Nobody is saying the current authentication system is ideal. Nonetheless, the basic idea of unencrypted communications is psychotic. No sane person would design the system as we have it now; it's not even worth the time to run through the reasons. (just dropping the name FireSheep for people to Google is sufficient as far as I'm concerned) That's all a side discussion, however. In any case, we are moving towards an all HTTPS world with HTTP/2. This bug is just about a proposal for the UI, and one that's not going to be implemented anytime that soon. (note: I did not confirm this bug and I suspect the likely resolution will be a reluctant WONTFIX for the time being; I and many others have been wanting something like this for a while, but I doubt we're ready for it yet)

(In reply to Dave Garrett from comment #15) > This bug is just about a proposal for the UI, and one that's not going > to be implemented anytime that soon....I and many others have been wanting > something like this for a while, but I doubt we're ready for it yet We are totally ready for it. Now is exactly the time to start the ball rolling and get people used to the idea that insecure connections are a Bug with a capital B. Mozilla needs to lead, not sit and wait the years for HTTP/2 to become default.

(In reply to Daniel Roesler from comment #16) > Mozilla needs to lead, not sit and wait the years for HTTP/2 to become > default. I'd settle for just enabled by default in a released version of Firefox, not the default used protocol Internet-wide. People (everyone, not just "average users") tune out UI stuff like this unless it's for "special" things, and even then you have to worry about warning fatigue. Doing "something" isn't the goal; being effective in the long term is. It's a bad idea to start badmouthing the majority of the Internet before we have a good replacement to evangelize them to switch to. Also, sorry, I don't personally think the broken lock icon suggested here is sufficient to get the message across. A lot more design needs to go into this concept. We'd need an icon that can't be confused with a lock at a glance (e.g. someone with bad eyesight might not notice the brokenness). Last week I was pondering the idea of a grey lock with a red 'X' over it, if such a thing could work in the limited space. Also, the fact that color isn't a great indicator has to be taken into account. Colorblindness is more common than people usually assume. I'm not personally going to make the ruling here, but I think this should probably be closed (for now) and a more detailed discussion should move onto the mailinglist/group. This is not the ideal venue to discuss this idea prior to a decision on how to move forward on the topic.

(In reply to Dave Garrett from comment #17) > A lot more design needs to go into this concept. I'm 100% on board with getting better UI resources on this. Does this just need to be assigned to the UI team? I'm also fine with continuing this discussion on the mailing list, but I don't want this to just get pushed down the road. We all agree that insecure connections need to go away, so we should be devoting resources to be making progress in solving the problem.

My current favorite suggestion is to show the generic icon for self-signed ssl certificates, and show the broken lock icon for insecure connections.

Dolske, want to weigh in here? :-)

(In reply to :Gijs Kruitbosch (Gone July 26 - August 3) from comment #20) > Dolske, want to weigh in here? :-) I do not relish the opportunity, as changes to security indicators often end up being contentious! But fine, I will weigh in. I see a few pretty clear reasons for not doing this, although I am quite sympathetic to wanting to see greater SSL usage... * Plain HTTP is still extremely common. Making that be a prominent UI state will just lead to users ignoring it and/or thinking Firefox is broken. * In general I am not thrilled with trying to get sites to change by punishing users. It's rarely effective, and just results in annoyed users who can't do anything about it. A prime example of this was the ancient warning dialog before submitting form data over a non-SSL connection. Everyone hated/disabled it, and we eventually completely removed it. * The red broken-lock, in particular, is a non-starter because it's far too alarming relative to what it conveys and how commonly it will be seen. A broken-padlock is a mixed message because that can also be used to indicate broken-SSL (although not at the moment in Firefox). I also worry about opportunity cost. We need to focus on doing things with maximum value, and this kind of change isn't likely to have much impact beyond lots of bikeshedding. We'd be better value from approaches with innate value to sites (such as HTTP/2 for performance), and the recent proposal to start limiting new features with privacy impact to SSL-only.

(In reply to Justin Dolske [:Dolske] from comment #21) > (In reply to :Gijs Kruitbosch (Gone July 26 - August 3) from comment #20) > > Dolske, want to weigh in here? :-) > > I do not relish the opportunity, as changes to security indicators often end > up being contentious! But fine, I will weigh in. I see a few pretty clear > reasons for not doing this, although I am quite sympathetic to wanting to > see greater SSL usage... Thanks a ton for the response :) The worst outcome would have been for this to languish and be forgotten. > > * Plain HTTP is still extremely common. Making that be a prominent UI state > will just lead to users ignoring it and/or thinking Firefox is broken. So the larger scope for something like this is for Mozilla to start having the attitude that non-SSL connections are a Bugs that should be fixed. There's so much open wifi nowadays, non-SSL should start to be considered bad practice. We gotta start somewhere. > > * In general I am not thrilled with trying to get sites to change by > punishing users. It's rarely effective, and just results in annoyed users > who can't do anything about it. A prime example of this was the ancient > warning dialog before submitting form data over a non-SSL connection. > Everyone hated/disabled it, and we eventually completely removed it. The upside of this solution is that it's non-interrupting. Additionally, I agree that it will be mostly ignored, which I don't necessarily see as a problem. Even if their users don't care, website owners will hopefully see it as just enough of an eyesore that they fix it just to make themselves feel better. If we can convert even a small percent of sysadmins to start using https, it will have been worth it. > > * The red broken-lock, in particular, is a non-starter because it's far too > alarming relative to what it conveys and how commonly it will be seen. A > broken-padlock is a mixed message because that can also be used to indicate > broken-SSL (although not at the moment in Firefox). So make it a gray unlocked lock. It would still be better than the globe generic icon. > > I also worry about opportunity cost. We need to focus on doing things with > maximum value, and this kind of change isn't likely to have much impact > beyond lots of bikeshedding. We'd be better value from approaches with > innate value to sites (such as HTTP/2 for performance), and the recent > proposal to start limiting new features with privacy impact to SSL-only. If people start fighting over this, I would think that it would only serve to motivate infrastructure changes so this sort of thing isn't needed. The otherside is if this is tried and works moderately well, it may get more people interested in contributing to HTTP/2. Anyway, thanks again for the reply, and I really hope Mozilla does become a leader in fixing the larger bug of non-SSL connections.

(In reply to Daniel Roesler from comment #22) > > * Plain HTTP is still extremely common. Making that be a prominent UI state > > will just lead to users ignoring it and/or thinking Firefox is broken. > > So the larger scope for something like this is for Mozilla to start having > the attitude that non-SSL connections are a Bugs that should be fixed. > There's so much open wifi nowadays, non-SSL should start to be considered > bad practice. We gotta start somewhere. Mozilla's success comes, in part, from being able to balance idealism and pragmatism. (The canonical example being implementing IE-only features to help end IE's 90% market share, the more recent examples being supporting the non-free H.264 video codec.) Increasing SSL usage is a laudable goal, but this isn't the way to do it. Other ideas welcome.

Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read <http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/>. The blogger is a certificate reseller and also a computer systems integrator. Thus, he is a professional in the area of computer systems, including security. Although he has a vested interest in selling site certificates, he argues against the idea that all Web sites should be HTTPS.

Chrome's security team announced today that they intend to start moving in this direction in 2015: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure The details of how to do this, exactly, are still TBD. But it's a signal to other browsers to work together and figure out a reasonable path forward that gets people moving. It definitely requires concurrent tooling work to lower the barrier to deployment, which is also happening (in part thanks to Mozilla). This is a good time to revisit this ticket and start the design process.

Justin, I'd like to request that this bug be re-opened for the reasons listed in the dev-security-policy mailing list thread. https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/hM2EAp3cfxg Copied below for reference. -------------------------- I would like to request that Bug #1041087 be re-opened for discussion. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 Much has changed since this bug was closed: 1. CloudFlare started offering free SSL certificates[1]. 2. The EFF, Mozilla, IdenTrust, Akamai, and Cisco will start offering free SSL certificates[2]. 3. Google is now ranking websites that use https higher[3]. 4. Chrome plans to start marking http as non-secure[4]. 5. Wireless carriers have begun modifying headers in transit[5]. All of these are a fantastic group effort to make the web more secure, and Firefox needs to be part of that effort. I propose the WONTFIX closure of Bug #1041087 be reconsidered and a timeline for gradually shifting to marking http as non-secure be established. Thanks! Daniel Roesler [1]: http://blog.cloudflare.com/introducing-universal-ssl/ [2]: https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web [3]: http://googleonlinesecurity.blogspot.com/2014/08/https-as-ranking-signal_6.html [4]: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure [5]: http://www.wired.com/2014/10/verizons-perma-cookie/ --------------------------

(In reply to Daniel Roesler from comment #26) > Justin, I'd like to request that this bug be re-opened for the reasons > listed in the dev-security-policy mailing list thread. Whether or not we should do something (and particularly a 'something' that is contentious and/or we decided not to do before) is better off discussed on a mailing list than on the actual bug. So far nobody replied to your message, and there is therefore no sudden new consensus (esp. among the responsible peers such as dolske) that we should change course. Give the mailing list some time, first (I'll poke some other lists/people on the matter, because m.d.security.policy is basically the wrong place for this).

Reopened per Google's proposal.

For those here who've yet to hear about it, there's been a development since this bug was put on hiatus that should help things a LOT: https://letsencrypt.org/ Once this new automated CA is up and running, getting a certificate and setting up TLS on a server should be something that takes only a few commands and under a minute, free of charge. In 2015 we should hopefully have both HTTP/2 & Let's Encrypt finalized and released. Getting servers to upgrade will be much easier, so this will be the time to start changing the UI to match decent security expectations. I'm quite glad this is finally all coming together. :) Adding the uiwanted keyword. Some careful UI design is needed here. To repeat a comment from above, I do not believe any variant of a padlock should be used to indicate the lack of security. It's too easily mistaken for the existing secure indicator. Padlock color should not be used as a primary indicator in order to make it easily distinguishable and to accommodate colorblind users. An incomplete list of possible indicators, in no particular order: 1) Bring back the "http://" but make it red with a strike-through (likewise for any "https://" that has notable problems) 2) Orange triangle exclamation mark sign icon 3) An eye with a magnifying glass icon (meaning you could be spied upon) 4) Change the coloring of the address bar background or border 5) Have a big identity box similar to EV, but with red "Insecure Site" text (screw icons; just say it bluntly with words) Also, form submissions, especially passwords, should be outright banned on insecure connections. (and grey/red out the form fields to indicate as such)

(In reply to Dave Garrett from comment #9) > One good idea for the short term could be to use an insecure warning > indicator like this only for unencrypted pages with password fields to > start. There's no legitimate reason to have them not on HTTPS right now. See bug https://bugzilla.mozilla.org/show_bug.cgi?id=748193. I started working on this sometime ago but stopped because it is no clear what the right UI should be and if it something we can ship in Firefox. Perhaps it wasn't a couple years ago but will be soon?

So how about this? No change in logic, other than gradually replacing the current globe icon in the following phases (i.e. this is a simple drop-in icon change). Phase 1 (2015): Gray unlocked icon (https://bugzilla.mozilla.org/attachment.cgi?id=8538168) Phase 2 (2016): Gray insecure lock (https://bugzilla.mozilla.org/attachment.cgi?id=8459202) Phase 3 (2017): Red insecure lock (https://bugzilla.mozilla.org/attachment.cgi?id=8459079) The regular https and EV https remain the same, with all the same logic for partial/warnings/etc.

(In reply to Daniel Roesler from comment #32) I think you more or less nailed it. As a dev, I was against a negative feedback approach the way it's been presented so far, especially given the poor manner in which Chrome now handles self signed-certificates (as non-private, with a dumb worded and context-less 'Back to Safety' button). But such a multi-phase approach with icon transitions seems reasonable. I'd throw the idea of a specific treatment for self-signed certificates such an orange secure color to remind the user of an existing exception. And perhaps a yellow lock for partial.

(In reply to Daniel Roesler from comment #32) > So how about this? No change in logic, other than gradually replacing the > current globe icon in the following phases (i.e. this is a simple drop-in > icon change). > > Phase 1 (2015): Gray unlocked icon > (https://bugzilla.mozilla.org/attachment.cgi?id=8538168) > > Phase 2 (2016): Gray insecure lock > (https://bugzilla.mozilla.org/attachment.cgi?id=8459202) > > Phase 3 (2017): Red insecure lock > (https://bugzilla.mozilla.org/attachment.cgi?id=8459079) Please, no. Read comment 29. Using variants of locks like this will just make the situation worse. Open up one of those grey locks and move your head far back away from the screen. The only difference between this "insecure" grey icon and the current "secure" grey icon is a white squiggle down the middle that average users will NOT immediately see as that different. Most people aren't going to examine this closely. It's only 16x16 px. Also, you cannot use the color red as the primary indicator of anything, because colorblind people are far more common than most people expect. Red-green colorblindness, in particular, affects somewhere around 7-10% of men. (colorblindness disproportionately affects males) If worse comes to worse, and the pathological obsession with padlocks continues, then at minimum we'd need a grey lock with a large red slash through it. However, I greatly prefer we have an actual different icon here. We need something new. The idea of phasing in the change in some way is not a bad idea, however I don't know if it would be worth it. Your timeframe is scarily long, though.

On the topic of creating UI for colorblind people, see: http://www.color-blindness.com/coblis-color-blindness-simulator/ You have to make the tones such that the contrast still shows with various different forms of colorblindness. Generally, if you use color to indicate something, it's best to also have shape indication as well. That way users can notice it with either color or shape. This is such a tiny canvas to work with; UI experts should be assigned to tackle this if Mozilla decides to move forward here.

duplicate of bug 1310447 (please mark as duplicate)

In Bug 1310447 we are implementing a pref to do this, however as mentioned by Dolske we can't enable this by default (yet). > The red broken-lock, in particular, is a non-starter because it's far too alarming relative to what it conveys and how commonly it will be seen. A broken-padlock is a mixed message because that can also be used to indicate broken-SSL (although not at the moment in Firefox). There is increasing value in hurting HTTP sites, however we still have to weigh up disrupting users so much they end up ignoring the icon. Firefox since implemented Bug 1217142 to increase the exposure to the broken padlock when a password field is detected. This is the kind of work that we can accept right now, where the user is immediate danger. Please open other bugs if you have an idea where we can further tighten this. Even after Lets Encrypt release we are still not in the position to blanket show HTTP as insecure. Please understand however that our stance isn't any different: insecure HTTP is bad and we want to remove it as swiftly as is possible.