User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170329100319 Steps to reproduce: https://bugzilla.mozilla.org/show_bug.cgi?id=1325171#c6 (intitial suggestion) https://bugzilla.mozilla.org/show_bug.cgi?id=1335970#c1 ("Interceptable") https://bugzilla.mozilla.org/show_bug.cgi?id=1335970#c6 (when https hits 66%) https://bugzilla.mozilla.org/show_bug.cgi?id=1350125#c2 (extending isSecureContext) https://bugzilla.mozilla.org/show_bug.cgi?id=672600#c65 (we are waiting on DNSSEC/DANE Stapling MOSS project) Expected results: I want to suggest an uniform improvement of the padlock for bug 1335586 (https-everything). On bug 1349897, bug 1350125 it's wanted to highlight "User trusted" certs (exceptions). On bug 1310447, bug 1335970 it's wanted to have a crossed padblock + text for http://. bug 942136 wants a visual distinction between bad and good practices.

Thank you for tracking these bugs and also putting this together! Some of these are certainly worth considering I'm not convinced we can push them at the same time frame though. Especially mixed content padlock changes.

Is there any interest from in changing these locks, especially the mentioned "user-accepted" padlock to indicate when a user has overriden a self signed cert or added a local trust root? That and I just wanted highlight this bug as it cleanly aggregates all bugs.

(In reply to Jonathan Kingston [:jkt] from comment #1) > I'm not convinced we can push them at the same time frame though. I wanted to inspire a discussion for the ~1-3 year goal to replace https://addons.mozilla.org/firefox/addon/dnssec-validator/ with bug 672600. It's clear that standardization takes time and it should be implemented in nginx and apache first. Also there should be a discussion between browser vendors to not confuse users with very diffent security indicators. Maybe the bugs from "Blocks" should get moved to "Depends on" to make the changes in small steps, e.g. the grey padlock for user-trusted certs first, hide https:// and show a red http: & ftp:, done together with the "Interceptable" text+icon. (Quote of Johann Hofmann [:johannh] from comment https://bugzilla.mozilla.org/show_bug.cgi?id=1325171#c7) > > * to not show the protocol or a padlock when https:// is used - encryption=neutral - (but display the protocol on all other protocols): Meta bug 1335586 (https-everything) > > I think this is the general direction we're heading for eventually, but it's > not within scope for the visual refresh. Which is good, because there are a > lot of factors to consider for this decision. (It's also not necessary to do > this as part of a major UI refactor, since the identity block is pretty > isolated.) > > > * to show a red crossed padlock (bug 1310447) with a red text 'Not Secure' (bug 1335970) for every unencrypted protocol (http://, ftp://, ws://) > > Bug 1310447 comment 7 outlines our team's current decision on this: We will > not show additional text in the URL bar, since the user will get a much more > efficient insecure login warning when they try to use a login form on that > page. The "Not Secure" text does not add any additional value in our > opinion. We want to avoid adding unnecessary elements that clutter the URL > bar (even more so with the refresh that focuses on gaining simplicity > instead of adding complexity). > > The bug is not closed yet, because this decision could be reconsidered in > the future. For now, we're not doing it. > > > * to show a green padlock without a text if DNSSEC/DANE stapling is valid (bug 672600, a MOSS project is working on it) > > * to show a blue padlock with a blue Name for EV certificates (but green padlock + green text if DNSSEC/DANE stapling is valid) > (let EV green, as long as DNSSEC/DANE Stapling (bug 672600) is not > implemented, but change it then) > > I generally agree that DNSSEC/DANE sounds very exciting and we should > probably think about how we can support it UI-wise, but really, there is a > lot to consider for this and the general UI refresh will be a big project on > its own. Feel free to make new bugs in the Security component for > DNSSEC/DANE UI highlighting, so that we're able to discuss this separately. > > I do not mean to shut down your (very interesting) ideas, just to say that > they're not in scope for the UI refresh and that changing the identity > indicators is always a delicate topic :) This is a comment to my first proposal which had different padlock colors. Maybe you can mix that ideas to not confuse users "where is the padlock on paypal my grandson told me": Maybe the "(!)" icons from the attached image should get replaced with something like blue padlocks. Firefox had blue padlocks long ago for Domain-validated certificates.

Alternate version with blue padlocks (as it was for domain-validated certs a long long time ago) for non-DANE-stapled connections to not confuse our grandparents (to prevent that there is a (!) instead of a padlock on a non-DANE-stapled connection to PayPal).

(In reply to Jonathan Kingston [:jkt] from comment #2) > Is there any interest from in changing these locks, especially the mentioned > "user-accepted" padlock to indicate when a user has overriden a self signed > cert or added a local trust root? > > That and I just wanted highlight this bug as it cleanly aggregates all bugs. I think it's something we should do. It's just not the highest priority item in the queue unless some things can be done as part of the Photon project. Adding Jacqueline so she is aware of these proposals.

(some corrections) (In reply to Peter Dolanjski [:pdol] from comment #5) > unless some things can be done as part of the Photon project. Because [:johannh] said "refresh that focuses on gaining simplicity" I would like to suggest here to hide https:// and show a grey http as it is currently done with https as part of the photon refresh. I don't think there is a bug for this yet. Then, far later, when you want to warn more explicit, change the color of http and ftp to red & show the "Interceptable" text+icon.

(Just to have it mentioned once: The very long-term goal could be to have a grey padlock for domains without DNSSEC.)

Thanks for these suggestions. A bit of feedback from my side: This is a too large variety of possible icon states. I think it's dangerous to introduce too many different padlock designs. This is going in the opposite direction of where I would like to take indicators, that is either green lock or broken lock, with no intermediate state. And it's certainly not what we're aiming for with Photon. I said in another bug yesterday that I don't want to be forced to ship a security indicators cheat sheet with the browser, and this bug is basically proposing exactly that. It's not our task to implement a ranking system for site network security, our task is too inform the user in a simple, unmistakable way, if they are secure or not. If you want to provide an advanced security ranking you should build an addon or a website. Quick, without looking at your cheat sheet, what's a green padlock with a yellow warning? I looked at it thoroughly and I don't remember. I also generally don't think a blue padlock is an option. There's no way to tell if it's more or less secure than a green lock for the average user. Now, I agree with you that we should embrace new security technologies like DNSSEC and deprecate old ones, but, believe me, complicating the security indicators is not helping this cause. We should make this information more approachable, not less.

Thank you for highlighting the needs of normal users in contrast to the advanced ones. I can follow your argumentation with a petition to evaluate the following option No. 4. This suggestion is for the time when bug 672600 got implemented and not directly for Photon. I think it would be wrong to only warn if some website had wrong DNSSEC+DANE - from my view. It should be visible to the (advanced) user, that this site is technically trustful because of DNSSEC+DANE and you don't have to rely completely on the trust of the CA ecosystem as today. Highlighting EV certs while not highlighting DANE would just not take all benefits of DNSSEC+DANE. Connecting to "a DV cert and trusting all CAs" would be shown as secure as connecting to "the DV cert as the domain owner's will is". I (as advanced user) couldn't see on the first look if this is really the correct website or not. There would be some options for you: :( 1. show only green / broken padlocks, but be precise in the dropdown. :/ 2. offer a webextension API with DNSSEC and DANE results to make such an UI possible (without further addon-based validation): https://addons.cdn.mozilla.net/user-media/previews/full/136/136126.png?modified=1400119493 :'( 3. don't be precise in the dropdown and don't offer a webextension API for this and users who want to know about DNSSEC+DANE had to install the current Addon communicating over Native Messaging, so in effect, every connection has to be validated twice (what a waste of computing capacity) :) 4. I can see your good argumentation for rookie/common users. Maybe you could make such an "easy and tidy UI without double validations" possible via a pref to enable blue/green/yellow triangle/broken padlocks as suggested in the attachment (incl. bug 1353710 + bug 1353705) for advanced users and show green/broken by default. As you can see in bug 942136 there is a wish by advanced users to efficently see what the browser already knows. Maybe the Tor Browser would flip this to advanced by default.

Beside the Tor Browser (and other distributions) I have forgotten to mention that computer magazines (and nerds) could report about "hidden Firefox tweaks" and explain the advanced UI options as they are propagating OpenPGP, addons (you have to learn what they do) and why DKIM signed emails are better for example. It's Firefox strength to meet different needs via about:config and not exposing everything to addons (even for performance reasons in this case).

(In reply to Johann Hofmann [:johannh] from comment #8) > Quick, without looking at your cheat sheet, what's a green padlock with a > yellow warning? I looked at it thoroughly and I don't remember. The padlock: green: high trust (correct domain-defined counterpart) blue: basic trust (secured in some way by 3rd parties, CAs) broken: Interceptable Additions: yellow triangle: something is not optimal (not the best encryption) "Paypal, Inc.": verified owner "User trusted": local exception by me or my snaikeoil MitM software This is really exhausting: https://support.mozilla.org/t5/Protect-your-privacy/How-do-I-tell-if-my-connection-to-a-website-is-secure/ta-p/1637 * green padlock * green padlock with Name (EV) * green padlock with grey triangle <- WTF * grey padlock with yellow triangle <- WTF * grey red crossed padlock * (!) symbol (not even mentioned for http:// here) <- WTF

(In reply to Johann Hofmann [:johannh] from comment #8) > And it's certainly not what we're aiming for with Photon. Shouldn't be cheap either. ;-) > I also generally don't think a blue padlock is an option. There's no way to tell if it's more or less secure than a green lock for the average user. There is a well to tell, you click on it: currently: 1| "www.domain.tld" or "Mozilla Foundation" 2| Secure Connection (in green) this suggestion: 1| black: "www.domain.tld" or "Mozilla Foundation" or "Security exception (X)[=remove button]" 2| "High trusted connection" (in green) or "Basic trusted connection" (in blue) or "Interceptable connection" (red) 3| (optional) Yellow triangle (something is not optimal): Ancient encryption. / Something evil (XSS) has been blocked

From current understanding we want to aim to where Google is going roughly: [EV cert text]? [Green padlock] www.domainname.com [Broken Padlock] Insecure http://www.domainname.com > grey padlock with yellow triangle <- WTF This is mixed active content: https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content This only happens when the user chooses to trust unsafe scripts on HTTP, it's not even common and probably should just be broken padlock. > green padlock with grey triangle <- WTF This is for mixed passive content, unfortunately this is so common we either need to make a choice here: - Show as secure - Show as insecure This is also shown for cert exception after they have acknowledged the cert warning. Blue padlocks have been suggested for this or green with "user trusted" whilst I think this is a really good idea I'm not really the right person to suggest how this should look.

(In reply to Jonathan Kingston [:jkt] from comment #13) > [EV cert text]? [Green padlock] www.domainname.com EV Name before the padlock would be very ugly (https://bug1310447.bmoattachments.org/attachment.cgi?id=8832244 this in green for EV, oh please not!) > > grey padlock with yellow triangle <- WTF > > green padlock with grey triangle <- WTF Those "WTF" were irony because those triangles are too precise and overstrain me. I found it funny that he didn't imagine the most obvious meaning of my one yellow triangle: "something is not optimal". > This is for mixed passive content, unfortunately this is so common we either > need to make a choice here: > - Show as secure > - Show as insecure Hell yeah, only https on the top level and http for all subresources and I get a green lock. You would lose any power to have some pressure on site owners to improve things. > This is also shown for cert exception after they have acknowledged the cert > warning. Blue padlocks have been suggested for this It's just blue but you wouldn't think there is a problem, it's just less nice, please reserve it for this this bug if we had DNSSEC/DANE stapling in ~1-3 years (and maybe just for a pref for an advanced padlock view with this). Please just don't rush into something that would need further changes then. > or green with "user trusted" whilst I think this is a really good idea Thumbs up. For Photon, I would expect this: [Green padlock] PayPal, Inc. | www.example.com [Green padlock] (grey) User Trusted | dev.example.com [Broken padlock] Interceptable/Manipulable/Unprotected | www.example.com (mixed content) or http://www.example.com (at the beginning of 2018 or when the https rate hits 80%: http:// and ftp:// in red) In both green padlock cases I would suggest to show a yellow triangle on: * Non-Perfect Forward Secrecy Ciphers (plain RSA) on top level or subresource bug 1353710 * Adobe Flash plugin activated (you could extend this in the future if needed) I would avoid to say "insecure" because even a https+EV website could be insecure because of bad server-side programming, Adobe Flash or malware over ad networks. What would the user think? If a broken padlock is "insecure" then the opposite must be "Secure" (like Google Chrome is it showing currently, which is a mistake in my view). I would say Interceptable, Manipulable or Unprotected for a broken padlock. People don't know what the background of "insecure" might be. It is insecure to drive a car without to fasten (seatbelt), but people do often. But if they see a warning that their handbreake is broken they would be careful and drove in walking speed with an open door. That's like what mixed content and http is. It's not just a mystic "insecure". It's insecure to oversalt a meal. The study you linked at bug 1335970 comment 0 wasn't that precise for this case. There should be a real-life word you would use for postal mail (postcard = Interceptable/Manipulable/Unprotected, please use an envelope).

> EV Name before the padlock would be very ugly (https://bug1310447.bmoattachments.org/attachment.cgi?id=8832244 this in green for EV, oh please not!) Sorry wrong order; Not that I think it matters all that much. > Hell yeah, only https on the top level and http for all subresources and I get a green lock. You would lose any power to have some pressure on site owners to improve things. Yeah, well other than letting site owners we will eventually flip that. I don't think we are close to changing this state at the moment right now. However I was just indicating that if we want to simplify, we need to decide what to do here. > It's just blue but you wouldn't think there is a problem, it's just less nice, This is the current state right now with reusing the mixed content lock. The issue with using mixed content lock is that right now it's so popular users won't be able to distinguish fairly common web to a cert they accepted by mistake / a long time ago. > please reserve it for this this bug if we had DNSSEC/DANE stapling in ~1-3 years I don't see the advantage of adding more steps here, as Johannh said we should keep implementing new security measures and never consider our work done. The main reason Chrome moved to simplify over time what locks meant is because they had users studies suggesting. My personal view is we should be shipping more extension APIs so over time extension authors can develop additional indicators for power users who care about DNSSEC or others. These extensions can also help us shape if/when we should break the padlock ever. > For Photon, I would expect this: I don't think Photon has anything to do with these suggestions/experiments. The timescales are relatively small and making changes to how websites look for security shouldn't be taken lightly. We need to user study any changes we make. I don't think Flash should ever play a part in the padlock, we have indicators that a website uses flash that we can use for this instead. If there are known exploits in a flash version we block it entirely from loading without user exceptions. > If a broken padlock is "insecure" then the opposite must be "Secure" (like Google Chrome is it showing currently, which is a mistake in my view). I agree using the word "secure" is potentially wrong here, I think our focus is to aim at isSecureContext=false looking bad and isSecureContext=true eventually looking neutral which from all sources I have seen is Googles aim also. "Look for the padlock" was a fairly easy thing to quote but it's proven to confuse regarding where the padlock should be found (aka Favicon spoofing of padlocks, or UX on the page) and also confusing users regarding secure encryption and trust. > I would say Interceptable, Manipulable or Unprotected for a broken padlock. Personally I'm not attached to any wording we choose for "user trusted" and "insecure", we should user study these on Firefox audiences. > at the beginning of 2018 or when the https rate hits 80%: This would be great if this happens that quick :D

While the input in this bug is interesting (and some of it may be picked up in the future), I don't think this bug is going anywhere in neither short nor long term and it's too broadly scoped to be considered actionable. It could be a meta bug if there was a project for re-designing the lock, but there isn't right now. I feel like most of the points mentioned here are covered in the linked bugs. I'm going to close this.

I'm going to clear the need-info here and that it blocks https-everything as it's related but not blocking it at all. Thanks again, I would keep track of the https-everything bug instead.