If you're using Chrome, right-click the URL bar and check "Always show full URLs", so you can see the <a href="https://" rel="nofollow">https://</a> prefix like it's 1999. This also fixes a variety of UX problems with editing URLs.<p>By the way, does anyone know of a good alternative to <a href="http://neverssl.com" rel="nofollow">http://neverssl.com</a> ? I had been using this for years, but now it supports SSL for some unfathomable reason.
Reading through this it's making a lot of sense, the lock icon was added to convey that the 'connection is secure', while making the assumption that the user understood it's talking about the transport layer behind the scenes. Of course, most users cannot be expected to know that kind of detail, so they would associate it with the thing in front of their eyes, the website itself.<p>I am sticking to Firefox but as changes go, this wouldn't be a terrible one for non-Chrome browsers to converge upon. I don't think it's a good idea to hide the option away entirely though; a lack of available information and options for a user on a platform can often lead to the platform itself deciding it needs to become the arbiter of information, but I assume the iOS limitation is Apple's usual user-hostile behaviour.
I approve of getting rid of the lock icon, showing only a broken lock for HTTP and no lock for HTTPS. It's always been weird to have site permissions settings revealed by clicking that lock.<p>But the replacement icon looks really strange to me. They're calling it a "tune icon," but I've never seen a tune icon like this, with just two circles and two lines. Looks weird. I'm surprised that it fared well in the experiment.<p>I would prefer it if they'd use a gear icon, which is normally used for settings like this. You can see a gear icon at the bottom of the tune menu for "Site settings," which makes it all the weirder that they're using a tune icon in the URL bar and a gear icon in the menu for site settings.
For my masters thesis, I proposed replacing the security indicator with a risk indicator: "After HTTPS: Indicating Risk Instead of Security" - <a href="https://scholarsarchive.byu.edu/etd/7403/" rel="nofollow">https://scholarsarchive.byu.edu/etd/7403/</a><p>Turns out there are lots of localized, privacy-preserving cues you can observe to determine whether a user may be at some level of risk, that doesn't involve a centralized blocklist or a boolean answer; and users really appreciated the "heads up".<p>I think a control panel like this is a good step forward after ubiquitous HTTPS. I also think user agents can do more to protect and warn users in ways that are less easily spoofed by malicious sites. Looking forward to seeing future developments!
I'm glad they continued the "An Update on X" = "X is getting axed" tradition at google. It's one of the few constants. Maybe they even have a UX guideline about it by now :D<p>PS: I'm not writing this out of spite, btw. It just came to my mind when I saw the title and I was surprised I was right
It’s a continuation of the trend that led to them removing Extended Validation indicators: <a href="https://duo.com/decipher/chrome-and-firefox-removing-ev-certificate-indicators" rel="nofollow">https://duo.com/decipher/chrome-and-firefox-removing-ev-cert...</a><p>Here’s how they used to appear: <a href="https://pbs.twimg.com/media/EBxdA7EWsAIQtc0.jpg" rel="nofollow">https://pbs.twimg.com/media/EBxdA7EWsAIQtc0.jpg</a><p>While I buy the reasoning that consumers simply ignore them, EV indicators would be really useful in a corporate setting to mitigate phishing attempts against employees. It’s much easier to train employees to “look for your company’s name in the green bar” before they sign into a site, than to understand how domains work and why login.yourcompany.com is OK but login-yourcompany.com isn’t.<p>Does anyone know if it’s possible to restore EV indicators in Chrome via MDM software or similar? Does anyone work at a company that does this?
> The new icon is scheduled to launch in Chrome 117, which releases in early September 2023, as part of a general design refresh for desktop platforms.<p>I downloaded Chrome Canary to take a look at this "general design refresh" and... sigh.<p>The new browser UI is now 10 pixels taller than the old one.<p>I realize 10 pixels isn't a lot. But it's also not noting—it's half the height of the top bar on Hacker News. And this is after Google <i>already</i> made their UI much taller in their last refresh. If you make the UI take up more and more space with each redesign, it adds up.<p>Yes, I have a bigger monitor today than I once did. But I bought that monitor so I'd have more space for actual content, not the browser UI.<p>Remember how Google chose the name "Google Chrome" because it was designed to have a minimal UI that gets out of your way and lets you focus on page content?
I wonder how many ordinary users have any notion of what the “tune” icon [0] is supposed to indicate.<p>[0] <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgugOcJZQTuZzMo-ker60pSIzOIfBPPIV7Gq_7nmOU9lVqJWZ-qyurLC-Pj3lrPrrh-pemoJC6Ix27Dam2LmNasddSS21m37_7YV8qbC2MPE8j1gEIcBqcMqSAvhq5WnAJ34OV3IZYoqhivJo0oN3C2A4NWA0csosSV4jFIbqhOopCrXwKPFu96oW6_Yg/s288/tune.png" rel="nofollow">https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg...</a>
What's with the naming and visuals of the "tune" icon, which seems to be a "site settings" icon with weird left- and right-justified radio buttons?
It's been interesting to watch the web landscape change over the last 8 years. Back in 205 when I joined Google's Web DevRel team, I worked with Chrome security engineers to create a persuasion article [1] about why all sites should be encrypted with HTTPS. The fact that they felt the need to create that page at all indicates that HTTPS was not that common. In 8 years the ecosystem has got to a place where HTTPS is so common that we don't even need UI for it anymore.<p>[1] <a href="https://web.dev/why-https-matters/" rel="nofollow">https://web.dev/why-https-matters/</a>
"You know that green lock in your browser?" used to be how I explained what I did in 5 seconds. Now what am I supposed to do?!<p>I like this update, I think this is an excellent UX change
This is a good move for the secure-by-default move.<p>In The Lounge IRC client, we've also opted to this approach years ago, where secure connections show no icon, and insecure connections show an insecure icon.
While we're fixing the UI for SSL, can we do something about unsecure connections to devices on my home network? At best I get a huge security warning that makes me jump through hoops to get past it, sometimes Chrome won't even let me get past without knowing the secret code. Surely we can figure out how to tell that a connection is only on the local network, and then give the user a one-time option to not worry about encryption for such local connections?
I never understood why a website served using a self-signed (and untrusted) certificate would throw up more warnings than a website served without any encryption at all.<p>Even today, a page served over HTTP just gets an unobtrusive bit of text saying "Not secure", but if a page is served over HTTPS with a cert that expired yesterday you will get a very scary full-page warning that entirely blocks you from accessing the underlying page.<p>It seems totally backwards to me.
I think its possible there could be a backlash against this change, as even though many peoples' understanding of the security implications of the lock icon didn't align with reality, their <i>expectation</i> vis a vi "lock icon means secure, no lock means insecure, be careful if there isn't a lock" could force a broad unlearning of something that the security community has tried to teach over the past ten to fifteen years.<p>> Despite our best efforts, our research in 2021 showed that only 11% of study participants correctly understood the precise meaning of the lock icon.<p>It doesn't seem to me that this is the right thing to be measuring. What matters more is: how many people <i>critically misunderstand</i> what the lock icon means, leading to the potential for trusting sites which shouldn't otherwise be trusted. The study itself goes on to better answer this, though its absent from the article: only 23-44% of respondents referred to the padlock at all when asked to evaluate the trustworthiness of a website. Its safe to say that some subset of that group would be shared with the group who critically & negatively misunderstand what the padlock represents, but its also safe to say that the entirety of the 11% "we know what the padlock means" group is also in the center of this venn diagram.<p>In other words: not more, and likely less, than a third of users were being misled by the padlock to the point of compromise. That's still a lot of people and its worth improving, but its a far cry from the 89% the blog post advertises.<p>When combined with the notion that the padlock's <i>absence</i> could cause harm; a different kind of harm, moving from "yeah this site is trustworthy I'll enter my credit card" when it isn't, to "no way this site is trustworthy I'm out of here" when it is trustworthy for some in that 23-44% group; I'm not sure this is a positive change.<p>I get that the world of HTTPS is evolving, and its very broadly default-on instead of default-off nowadays, but it seems to me that this is something of an expedient and ineffectual solution to something much harder: education. The article says "Despite our best efforts, our research in 2021 showed that only 11% of study participants correctly understood the precise meaning of the lock icon", but I'm at a loss for what exactly Google means by "despite our best efforts". I don't intend to be mean or combative with this observation. Education is really difficult; but when viewed through a more critical lens this article and the associated change really smells like "We failed to correctly educate our users about internet security, so we're changing an icon to absolve ourselves of the responsibility of the previous icon's inferred meaning."
Think of all the webpages that tell people to look for a padlock icon in their browser? All the books, all the training materials, videos, etc.<p>This doesn't seem like a good idea at all.
Such a cryptic lock is even more confusing. I propose a very simple, easy to understand solution:<p>http should simply be RED
https should not be indicated at all<p>A curated list, preferably by the gov. should indicate which SSL certificates are allowed to be green.