If you're using Chrome, right-click the URL bar and check "Always show full URLs", so you can see the https:// prefix like it's 1999. This also fixes a variety of UX problems with editing URLs.
By the way, does anyone know of a good alternative to http://neverssl.com ? I had been using this for years, but now it supports SSL for some unfathomable reason.
"neverssl.com now supports ssl, as some browsers and sites automatically use https even when you don't type that in. You get a browser-cacheable page that still helps you get online by forcing a request that ... never uses ssl." --
https://twitter.com/NeverSSL/status/1456310362551164928
They're trying to solve the "how do log into this captive portal" problem, and they needed to make this change to handle that typing "neverssl.com" now often evaluates to "https://neverssl.com".
Depending on what you're trying to do one of the "captive" ping urls works eg http://captive.apple.com
This is the url that apple devices ping to get the login box up for things like hotel wifi. There's a mozilla one also which is http://detectportal.firefox.com/canonical.html [1] , but that returns a redirect which may or may not work for your use case.
My latest annoyance with the Chrome URL bar is when certain things autofill (it might be bookmarks, but I think I see it in other frequently-visited addressed too), instead of it populating with the full URL so I can edit it, it just pops up as a piece of text to the right of where I'm typing, so I can see the URL that will fill if I hit enter but I can't edit it. It just started doing this a few months ago maybe?
> By the way, does anyone know of a good alternative to http://neverssl.com ? I had been using this for years, but now it supports SSL for some unfathomable reason.
For forever I used yahoo.com to login to a captive portal. I don't know why, but for some reason it worked for me when typing google.com, etc didn't work. Somehow I figured that out and stuck to it. I haven't done it in a while, though, not sure if it would still work.
Thank you. I searched and found a similar option in Safari settings but it doesn’t permanently show the protocol prefix. It also gets overridden on google searches where it just shows your search terms, not the URL.
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.
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.
When we were hosting custom websites for various university departments on the cheap, at this point it was difficult to do HTTPS on a site that shared IPs (which I gather has been corrected). One group insisted on it, despite that their form results, which weren't exactly secret squirrel knowledge, got stuffed into plain ole SMTP emails. I explained this carefully.
"But it has a LOCK on it ..." It was impossible to get them to understand that SSL only protected one part of the movement of data. All they got was LOCK.
So, yes, I agree that the lock offers a kind of false sense of security to people who will latch onto that symbol even as the people providing the hosting tell them otherwise.
while making the assumption that the user understood it's talking about the transport layer behind the scenes
I remember using an early (90s?) browser that explicitly said "Secured Connection" in the status bar with an icon that featured a depiction of a network cable. I don't remember the details, but I think that may have been in the early days of SSL.
The lock icon is tappable in other iOS browsers (Firefox, Brave, DDG, the list goes on). Chrome chooses to put site settings and SSL info in a different menu in the iOS version. I'm not sure which iOS platform limitation you're referring to.
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.
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.
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.
This icon is gaining traction fast. I've seen it a lot over the past few years. "Tuning" and "adjusting" is a slightly more specific concept than "settings". I think users associate the "settings" gear with whole-app settings, or "technical"/"system" settings, and it might be something they're loathe to click on because that's typically a large forest of things they don't care about or understand.
Firefox currently uses the same icon to configure site permissions (microphone, location, etc). However, it is only displayed if you have granted permissions. You can see it here:
i think it's a fairly recognizable and standard icon, i've definitely seen it used for this sort of thing before. i've never heard it called a "tune icon" before but the name ultimately doesn't matter much
For my masters thesis, I proposed replacing the security indicator with a risk indicator: "After HTTPS: Indicating Risk Instead of Security" - https://scholarsarchive.byu.edu/etd/7403/
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".
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!
Microsoft Edge already does that. They show a quite prominent "Not secure" sign with an exclamation mark instead of the regular hollowed out (aka very indistinguishable) lock icon when the connection isn't trusted HTTPS.
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
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
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.
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?
> EV indicators would be really useful in a corporate setting to mitigate phishing attempts against employees.
Our company puts a big red banner on the top of all emails that come from an external source or don't have DMARC/SPF/DKIM/other security protections. Literally nobody ever checks the banner. It has no effect on phishing click rates. People do not read, or think. They just look for wherever it is expected for them to click something/fill something out, or just click random things to see what something might be.
The only thing that has marginally improved click rates is when we either gamify it, or put all external mails in an external mail folder marked NOT SAFE.
> EV indicators would be really useful in a corporate setting to mitigate phishing attempts against employees
I believe that kind of "negative awareness", the awareness that need you to keep checking if something has disappeared constantly doesn't work well in practice. You naturally develop blindness to that element, and therefore to its absence too.
Long ago I was reading someone registered corp in some other jurisdiction with the same company name which he wanted to impersonate with EV cert. And succeeded.
So what are you proposing is of questionable value.
> 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.
I downloaded Chrome Canary to take a look at this "general design refresh" and... sigh.
The new browser UI is now 10 pixels taller than the old one.
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 already 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.
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.
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?
It is not just about pixels... The line-height of the text in the address bar simply feels wrong to me. We now have more spaces but smaller, harder to see text. Feels like going backwards for me. Reminds me of the new Steam download UI, the elements are larger while the download speed is much harder to discrern. I rememember lying on bed checking on the game download speed in my high school years, now I have to get real close to see the current speed.
The rest of the "refresh" actually seems not unacceptably bad.
Some 'designers' just blatantly waste advanced technology and screen real estate. Like I finally built a PC that can open right-click menus in an instant wihout having to watch the spinner, and then windows 11 decided that having (unskippable!) transitions to open menus is a good idea. I went out of my way to make sure I have the lowest-latency mouse and monitor, and websites use these custom css scrollbars that have nearly 2 frames of more latency that the system one, also dragging windows in and out of Stage Manager make your mouse have massive latency for a while.
I am at least happy with macOS though, at least the line-height is not going wild. Seems Apple have some of their soul left, though they may be lost soon. Even just being a novice macOS user I can immediately tell whether any animation is done pre or post 2020.
This settings/configure/adjust icon seems to be in the middle of a transition between abstract and universal. Something like a magnifying glass didn't need any transition period because humans already associate it with "searching" from fiction. Other icons required reinforcement to learn (e.g. the share icon - or, even more well learned, the pause icon). One of the downsides of the modern hyper-focus on metrics in UI is that it dictates that iconography already be intuitive. Sometimes we need to ignore this rule in order to teach users a new icon, which then helps us improve interfaces by communicating more without words.
I've got to say, "tune" is such a weird word to choose, it almost sounds like a bad translation.
Tuning is associated with musical notes (originally) and then with cars (optimizing performance) and engines more generally.
It's a weird metaphor to use for an icon that's usually been called "settings".
Because settings are not tuning, because engine/car tuning isn't about choosing your preferred settings, it's about small adjustments to maximize performance.
(The visual icon makes sense since it shows the popup to toggle settings for the site.)
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.
"Click the button that looks like two magnifying glasses pointing left and right" clearly!
I get what they were going for with this design, but it's impossible to describe this over the phone. I guess they want you to use Chrome Remote Desktop if you ever need to support someone remotely.
This is a good move for the secure-by-default move.
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?
1) Business contexts. A local network maybe shouldn't be trusted, there, for security purposes. "OK, but they should set that with policies" which, yes, sure, but defaults do matter, so... I dunno, I can see why they'd prefer the safer default.
2) Lying DNS servers on a local-but-actually-public network (think: coffee shop wifi) directing you to a local address to bypass SSL protection while it proxies Amazon or your bank website or whatever, and steals your credentials.
3) IPv6 is supposed to render these distinctions rather moot (although, LOL, and also that's precisely one thing some folks don't like about it, but that's another topic)
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.
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.
An analogy may help, imagine the website as a door. A website using HTTP is a normal door and using HTTPS is a door with a lock, where the keyring in this analogy are the trusted CAs by your browser. A website using HTTPS with an expired certificate is a door that should have a lock, but the lock no longer latches; and a self-signed certificate is a locked door with a key left in the doorknob.
From a security perspective, a door without a lock has no expectation of protecting anything. But a door that should lock but doesn’t, or is supposed to be locked but has the key left in the latch is not providing the security expected, and should be given pause when anticipating security from the lock. This is what the browser is trying to translate with its UI.
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 expectation 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.
> Despite our best efforts, our research in 2021 showed that only 11% of study participants correctly understood the precise meaning of the lock icon.
It doesn't seem to me that this is the right thing to be measuring. What matters more is: how many people critically misunderstand 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.
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.
When combined with the notion that the padlock's absence 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.
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."
We have collectively taught all the non-tech folks not to enter sensitive information, such as credit card numbers, in non-secure forms that don't show the lock.
This used to mean a lot when certificates were harder and more expensive - the rationale was fly-by-night bad actors wouldn't bother. This is most definitely not the case now.
Realistically as well, it's mostly to guard against man-in-the-middle interception - as we all know once it hits the server handling the SSL termination, all security bets are off.
FWIW Chrome does (and I assume will continue) saying "Not secure" where the padlock used to be, for HTTP sites. So there is at least that as a warning.
Google’s blog was too polite to say it but the real point here is that whether a site has ssl support is now completely useless information. Any legit commercial site will have it, any malicious site will have it, the only sites that don’t are weird relics. So removing the lock icon makes sense regardless of how educated users are.
They'll change. Maintaining backwards compatibility with third-party training material is the least-useful form of maintaining backwards compatibility.
This is forever the problem with documentation: it checkpoints a description of a system at a point in time.
You can make an extremely valid similar argument regarding C++ tutorials written in 1995, but the end-response is the same: "Update your sources, learn the new thing, and most importantly don't assume anything computer-related that is more than 5 years out of date is relevant, especially for something Internet-related."
p1mrx|2 years ago
By the way, does anyone know of a good alternative to http://neverssl.com ? I had been using this for years, but now it supports SSL for some unfathomable reason.
jefftk|2 years ago
"neverssl.com now supports ssl, as some browsers and sites automatically use https even when you don't type that in. You get a browser-cacheable page that still helps you get online by forcing a request that ... never uses ssl." -- https://twitter.com/NeverSSL/status/1456310362551164928
They're trying to solve the "how do log into this captive portal" problem, and they needed to make this change to handle that typing "neverssl.com" now often evaluates to "https://neverssl.com".
seanhunter|2 years ago
This is the url that apple devices ping to get the login box up for things like hotel wifi. There's a mozilla one also which is http://detectportal.firefox.com/canonical.html [1] , but that returns a redirect which may or may not work for your use case.
[1] https://support.mozilla.org/en-US/kb/captive-portal
hbn|2 years ago
amluto|2 years ago
hgj4dfshgf43|2 years ago
http://http.rip/
rzzzt|2 years ago
MarkSweep|2 years ago
luckystarr|2 years ago
http://http.rip/ was shared (here?) recently.
jbverschoor|2 years ago
Dandy3556|2 years ago
zeven7|2 years ago
cmckn|2 years ago
runnerup|2 years ago
DiggyJohnson|2 years ago
WrtCdEvrydy|2 years ago
mgraczyk|2 years ago
unknown|2 years ago
[deleted]
llimllib|2 years ago
mattnewton|2 years ago
dmitrygr|2 years ago
politelemon|2 years ago
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.
at_a_remove|2 years ago
"But it has a LOCK on it ..." It was impossible to get them to understand that SSL only protected one part of the movement of data. All they got was LOCK.
So, yes, I agree that the lock offers a kind of false sense of security to people who will latch onto that symbol even as the people providing the hosting tell them otherwise.
userbinator|2 years ago
I remember using an early (90s?) browser that explicitly said "Secured Connection" in the status bar with an icon that featured a depiction of a network cable. I don't remember the details, but I think that may have been in the early days of SSL.
resfirestar|2 years ago
dfabulich|2 years ago
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.
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.
coldpie|2 years ago
A gear icon would work as well, but the intent was immediately obvious to me.
happytoexplain|2 years ago
Also, I think using not-well-known icons is actually underrated (see my comment here: https://news.ycombinator.com/item?id=35793362)
pavon|2 years ago
https://support.mozilla.org/en-US/kb/site-permissions-panel
noja|2 years ago
notatoad|2 years ago
https://www.google.com/search?q=preferences+icon&tbm=isch
benatkin|2 years ago
mholt|2 years ago
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".
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!
sedatk|2 years ago
mqus|2 years ago
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
dadrian|2 years ago
kmoser|2 years ago
ladon86|2 years ago
Here’s how they used to appear: https://pbs.twimg.com/media/EBxdA7EWsAIQtc0.jpg
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.
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?
throwawaaarrgh|2 years ago
Our company puts a big red banner on the top of all emails that come from an external source or don't have DMARC/SPF/DKIM/other security protections. Literally nobody ever checks the banner. It has no effect on phishing click rates. People do not read, or think. They just look for wherever it is expected for them to click something/fill something out, or just click random things to see what something might be.
The only thing that has marginally improved click rates is when we either gamify it, or put all external mails in an external mail folder marked NOT SAFE.
sedatk|2 years ago
I believe that kind of "negative awareness", the awareness that need you to keep checking if something has disappeared constantly doesn't work well in practice. You naturally develop blindness to that element, and therefore to its absence too.
jve|2 years ago
So what are you proposing is of questionable value.
bmicraft|2 years ago
Wowfunhappy|2 years ago
I downloaded Chrome Canary to take a look at this "general design refresh" and... sigh.
The new browser UI is now 10 pixels taller than the old one.
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 already 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.
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.
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?
World177|2 years ago
[1] https://i.imgur.com/cuCcyf1.png
anon3242|2 years ago
The rest of the "refresh" actually seems not unacceptably bad.
Some 'designers' just blatantly waste advanced technology and screen real estate. Like I finally built a PC that can open right-click menus in an instant wihout having to watch the spinner, and then windows 11 decided that having (unskippable!) transitions to open menus is a good idea. I went out of my way to make sure I have the lowest-latency mouse and monitor, and websites use these custom css scrollbars that have nearly 2 frames of more latency that the system one, also dragging windows in and out of Stage Manager make your mouse have massive latency for a while.
I am at least happy with macOS though, at least the line-height is not going wild. Seems Apple have some of their soul left, though they may be lost soon. Even just being a novice macOS user I can immediately tell whether any animation is done pre or post 2020.
layer8|2 years ago
[0] https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg...
Spivak|2 years ago
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh...
happytoexplain|2 years ago
CharlesW|2 years ago
crazygringo|2 years ago
Tuning is associated with musical notes (originally) and then with cars (optimizing performance) and engines more generally.
It's a weird metaphor to use for an icon that's usually been called "settings".
Because settings are not tuning, because engine/car tuning isn't about choosing your preferred settings, it's about small adjustments to maximize performance.
(The visual icon makes sense since it shows the popup to toggle settings for the site.)
samtho|2 years ago
djur|2 years ago
unknown|2 years ago
[deleted]
kaycebasques|2 years ago
[1] https://web.dev/why-https-matters/
GuB-42|2 years ago
matthewaveryusa|2 years ago
I like this update, I think this is an excellent UX change
jeroenhd|2 years ago
I get what they were going for with this design, but it's impossible to describe this over the phone. I guess they want you to use Chrome Remote Desktop if you ever need to support someone remotely.
xPaw|2 years ago
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.
rootusrootus|2 years ago
yamtaddle|2 years ago
1) Business contexts. A local network maybe shouldn't be trusted, there, for security purposes. "OK, but they should set that with policies" which, yes, sure, but defaults do matter, so... I dunno, I can see why they'd prefer the safer default.
2) Lying DNS servers on a local-but-actually-public network (think: coffee shop wifi) directing you to a local address to bypass SSL protection while it proxies Amazon or your bank website or whatever, and steals your credentials.
3) IPv6 is supposed to render these distinctions rather moot (although, LOL, and also that's precisely one thing some folks don't like about it, but that's another topic)
aezart|2 years ago
cyclotron3k|2 years ago
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.
It seems totally backwards to me.
aewens|2 years ago
From a security perspective, a door without a lock has no expectation of protecting anything. But a door that should lock but doesn’t, or is supposed to be locked but has the key left in the latch is not providing the security expected, and should be given pause when anticipating security from the lock. This is what the browser is trying to translate with its UI.
015a|2 years ago
> Despite our best efforts, our research in 2021 showed that only 11% of study participants correctly understood the precise meaning of the lock icon.
It doesn't seem to me that this is the right thing to be measuring. What matters more is: how many people critically misunderstand 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.
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.
When combined with the notion that the padlock's absence 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.
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."
minaguib|2 years ago
This used to mean a lot when certificates were harder and more expensive - the rationale was fly-by-night bad actors wouldn't bother. This is most definitely not the case now.
Realistically as well, it's mostly to guard against man-in-the-middle interception - as we all know once it hits the server handling the SSL termination, all security bets are off.
FWIW Chrome does (and I assume will continue) saying "Not secure" where the padlock used to be, for HTTP sites. So there is at least that as a warning.
s17n|2 years ago
astrea|2 years ago
cobbal|2 years ago
chrismsimpson|2 years ago
awinter-py|2 years ago
absentmoon|2 years ago
8lahaj|2 years ago
[deleted]
PaulHoule|2 years ago
mattl|2 years ago
This doesn't seem like a good idea at all.
post-it|2 years ago
shadowgovt|2 years ago
You can make an extremely valid similar argument regarding C++ tutorials written in 1995, but the end-response is the same: "Update your sources, learn the new thing, and most importantly don't assume anything computer-related that is more than 5 years out of date is relevant, especially for something Internet-related."
djur|2 years ago
unknown|2 years ago
[deleted]
computerfriend|2 years ago
jbverschoor|2 years ago
http should simply be RED https should not be indicated at all
A curated list, preferably by the gov. should indicate which SSL certificates are allowed to be green.
throwawaaarrgh|2 years ago
Government oversight of TLS certs? No way this could possibly go wrong
renewiltord|2 years ago
dadrian|2 years ago
jackson1442|2 years ago
dfabulich|2 years ago
billyhoffman|2 years ago