Hot on the heels of (Chromium Blog) An Update on the Lock Icon
We have this tongue-in-cheek response from Scott Helme contemplating a new LE logo.
https://twitter.com/Scott_Helme/status/1654136865715286017
I found it humorous, but I'm also curious what other folks think of the upcoming Chromium change. Personally, I don't really mind visually one way or the other as long as getting to the cert details doesn't become a 5-click multi-menu nuisance.
How else can you take it?
Sarah here from Let's Encrypt. I run the comms team. While we think Scott's artwork is fun and cute, we have worked very hard over the years to build a unique identity in the Let's Encrypt brand and to make that identity a reliable indicator of quality. Conflating our logo with the generic concept of TLS certificates takes us backward in that endeavor so we hope people continue to see this squarely as a parody!
The chromium change is definitely a good one. I don't particularly care about the icon one way or another -- I suspected they'd move it to the right hand side of the omnibox where they've started putting a few other new icons, but I guess not -- but getting rid of the lock icon is definitely good. HTTPS needs to be the unmentioned, unquestionable default.
Heck, I want my mobile OS to block it and notify me if an app ever tries to make a non-SSL'd HTTP connection.
Heck, I want my mobile OS to block it and notify me if an app ever tries to make a non-SSL'd HTTP connection.
CRL/OCSP 
The problem I have with my phone is that the lock icon in Samsung Internet no longer allows me to view certificate details. I'm concerned that the trend of pushing away the lock icon will diminish awareness (and subsequently knowledge) of TLS/SSL and possibly lead to problems therewith becoming (even more) opaque. Even if HTTP were retired entirely in favor of HTTPS, I feel that it would still be important to be able to readily access certificate information for confirmation and diagnostic purposes, which, to me, is the primary function of the lock icon. IMO it's a horrible miscalculation to even consider moving the lock icon, nonetheless removing it, for multiple reasons:
Now that every site loads over HTTPS, knowledge of TLS to the average user is about as important as knowledge of TCP (i.e. irrelevant). The only thing they need to know about is when there's an error.
Meh, this has been debunked multiple times in research:
The icon's location isn't moving though, it's just not a padlock. If the protocol does not use certificates you'll get a big scary warning, not just the absence of an icon.
[Citation needed]
You might like my masters thesis, After HTTPS: Indicating Risk instead of Security, wherein we propose to convey risk assessment to the user instead of security in a world where all sites are HTTPS (Google Chrome later ended up using some ideas from this paper in their browser):
I wholeheartedly disagree. TLS/SSL is still incredibly manual in configuration, meaning that there are a lot of disparate moving parts that need to be coordinated to have a working system. Claiming that one can just "not know" is like claiming that one doesn't need to know about basic automobile fluids or mechanics being the driver of a vehicle. I, for one, don't want less informed drivers. They're bad enough already.
I think maybe I'm being misunderstood here. By "engender trust in the protocol", I'm talking about a basic user being basically aware that the protocol currently being used is actually being secured by certificate usage at all. I'm not talking about fronting for the mechanics of the TLS protocol specifically. Keep in mind that browser developers have also made the (IMO terrible) decision of removing the protocol itself from the address bar during site usage. If you remove the lock from the image below, how do I have ANY indication that HTTPS is being used AT ALL? Additionally, a lock icon is MUCH easier to recognize to a basic user than https.
If you put that "big scary warning" in the content area, a good portion of users (myself included) will likely interpret that as a spoof trying to sell "protection" (or install malware under the guise of such). Having the lock icon in a prominent, unalterable (by bad actors) place makes it quick and easy to recognize (legitimate) problems. I really don't want to go digging around in my car's central computer display to find the check engine light.
Regarding never removing the icon (my quoting mechanism for this site is malfunctioning now for some reason 
):
When a site has "mixed content", many/most browsers have traditionally chosen to remove the lock icon from the screen rather than display the icon with a strong indication of the problem with emphasis to click to find out more. IMO this is a dark pattern that results in stealing the indication that the requested connection uses certificates to indicate that the inclusion mechanisms of embedded content result in requests that do not.
I shall look into your thesis. 
I sense that it may portent good things to come.
Except that the vast majority of people "riding" in the cars are not driving the cars too, so no, they don't need to know about engine maintenance. The vast majority of people using a website are not deploying a website (and especially not one they need to manage themselves).
There's probably a reason most public transit doesn't post their maintenance info on every seat for everyone to see. But they will take the bus out of service if there's a problem.
The fact that it loads without a big scary warning saying the site isn't secure. 
I thought you just said it was a mistake to remove the protocol from the URL though:
You'll really like my masters thesis, then, where I scrutinize current browser warnings and recommend an unspoofable warning UI that takes place above the line of death.
The entire webhosting market (of billions) begs to differ. Sure, things have become simplified to a large degree due to development (thanks to your efforts, my efforts, and those of others dedicated to the cause), but based on the stories in this community alone, we've still got a long way to go to reach blissful ignorance. I work with cert-manager and k8s in my day job. Thank God I'm a longstanding, frequent contributor of this community with a reasonable mastery of certs and ACME or I'd be completely hosed. There are many, many thousands in similar roles who aren't so fortunate. Wait until the OpenSSL 1.1.1 EOL comes closer as we approach 9/11. I predict we're going to see the majority of the world's ignorance of SSL details come to full fruition. Be on the lookout for agonies of user overlap between Caddy and Palo Alto.
Or it's HTTP and I have no way of knowing since I clicked a link or bookmark to get here without carefully inspecting the protocol in such, like I'd predict 95%+ of users would do.
Correct. Could be ftp as far as I know. Or torrent. Or my-site-has-been-compromised-protocol. The lock icon is just a stupidly-simple way of knowing that a cert-based protocol is being used (hopefully backed by browser intelligence indicating modern/correct configuration/strength). It could be the wrong cert-based protocol though. 
CDNs (e.g.Cloudflare) muddy the waters here even more and yet have become increasingly prevalent with more amateur web developers.
It makes me very happy that there are smart people, such as yourself, who have put good thought and passion into this. To me, this is more of a UX concern with browsers than a cert concern at heart. One of my greatest humbling points (strongly learned through my development of CertSage) is in understanding that I'm not the typical user. I do actually use CertSage for my own sites. I needed to make sure that someone with 1/100 of my technical capacity could also do so.
Huh, I get errors when attempting to load a site over HTTP, and I'm pretty sure they're making this the default going forward:
But anyways, the padlock is dead. Long live the padlock (of your web server)!
I own indomitable.dev, which is (supposed to be) hsts preloaded. Seems to load GoDaddy's parking page over HTTP with no problems. 
Oh, there's a tiny, little exclamation point.
This site can’t be reached
indomitable.dev unexpectedly closed the connection.
Try:
- Checking the connection
- Checking the proxy and the firewall
ERR_CONNECTION_CLOSED
Quite broken from my standpoint (using Chrome).
See my screenshot. Using Chromium Samsung Internet, one of the most common browsers on earth.
Yeah, no, HTTP isn't working, immediately loads using HTTPS.
See my screenshot. It most certainly is HTTP and working.
Yes, that might work for you, but for me, it is NOT working. HSTS preloaded, HTTPS only which is broken.
Right, but you're not using Samsung Internet, the stock browser on Galaxy devices since forever. Is it right? No. But that's the state of much of the world regarding HTTPS/TLS/SSL. If it's all done correctly, it works great. It's rarely all done correctly. I don't need a check engine light much if I'm a master mechanic who built my own engine.
To Matt's point, when I'm visiting Bob's the Mechanic website, I may not be deploying his website, but I certainly want to know in no uncertain terms if there's a problem with such. Taking information away from the user as a means of keeping them from misinterpreting it sounds frighteningly like many arguments for censorship, but I digress. I'd rather educate people about the right way to use tools than simply take the tools away because people have been taught incorrectly (or not at all) about how to use them properly.
IMO there is no dangerous information. There is only ignorant or dangerous intention. Sometimes those are the same.
If only that were all it engendered trust in. Unfortunately, as you know perfectly well, the padlock is much more likely to engender trust in the website itself, not the protocol by which you're communicating with it (to which the vast majority of users don't even give a first thought, much less a second).
Quite true. Hence...
Unfortunately, if enough people eat Tide pods... (a bad "if you give a mouse a cookie" paragraph started to form here).
