Chrome's HTTPS padlock heads to Google Graveyard Google plans to retire the padlock icon that appears in the Chrome status bar during a secure HTTPS web browsing session because the interface graphic has outlived its usefulness. Later this year the lock icon will be replaced with the "tune" icon, which Google says "is commonly used to indicate controls and settings." Today' …
Oddly (for me), I kind of agree with Google. I say pointing out when it's plain HTTP is probably the best strategy, as it means everything is potentially visible in transit (which is a problem). Showing a padlock is kind of meaningless when the use of encryption is the norm (or it bloody should be): it just gives people a false sense of security.
Having to click through a drop-down to check status is just going to mean even fewer people do it. The padlock might not have been ideal, but it was an instant visual clue for those who wanted to know.
Or, y'know, just stop the practice of hiding "http://" or "https://" in the address bar? Other than saving a little horizontal space, what's the point?
M.
A big red Unlocked padlock icon for normal http
Or a fluttering Skull and Cross-Bones - Arrr, me-hearties.
From the start I thought flagging as 'safe' rather than warning things may not be secure was the wrong approach. But I thought it was a bad idea whatever the policy - Suggesting to the great unwashed that https was safe for visit was dangerously misleading.
Just because ssl/TLS was active doesn't mean you'd see a locked lock. And too many browsers are still happy to try an unsecure http connection before an HTTPs one unless you type https:// in by had.
_every_damn_time_
So the old system sucked and the new system will do little to fix that. Yea! progress...
@Hubert Cumberdale
And of course http does not necessarily mean insecure, depends what the site is.
I run a couple of club / society websites, http only* - but that is fine as they are "information only / read only" web sites, users are just browing information, not making payments, sending PII etc.. They also use zero JavaScript (and serve no ads) so are potentially an awful lot safer than a "secure" https site
*Http only also saves a few quid & bit of hassle on the certs for https as company hosting them** restricts the certs you can use so they make extra cash off you having to purchase certs via them! and not worth the hassle of switching host provider as I only keep the sites updated "as a favour" & don't want to waste time & effort on host / site transfers.
** When I became the new sucker / volunteer to keep the sites running, hosting company was the one that had previously been used so path of least hassle was to keep with that hosting co as site worked and no need for https so not an issue about non free certs.
There's still the vulnerability that if someone's connected to an open network – e.g. public unsecured wireless – an attacker could use DNS cache poisoning to redirect the client to a malicious site, which could serve malicious Javascript, for example to exercise one of the periodic Javascript engine type-confusion RCE vulnerabilities. I think it's a pretty low-probability threat: what attacker wants to hang out at a café snooping traffic and waiting for someone to use plaintext HTTP? But there are attack vectors.
That said, I'm no great fan of the HTTPS-everywhere movement. Within corporate networks, for example, the benefit is minimal. And even on the public Internet, as I said above, it's not a terribly plausible attack.
Still being practices by Verizon in the US last I checked, and over HTTPS sessions as well. (one of the reasons Google started pinning their certs. But just theirs, that technology is just to awesome for YOU to use)
Because SSL depends on DNS, and how many US Lusers know they need to manually set the DNS for EACH DAMN CONNECTION to avoid the carrier/wifi network from screwing them.
VPNs are your friends kids.
Oh, and Mint mobile likes blocking you from their internal services if you have a VPN connection active on your device.
i just use an ad blocker on my mac devices,
on IOS its installed in vpn,dns & device management which means it also works when using "limit ip address tracking" so i don't need to pay for a vpn.
i only see ads when i disable ad blocking for troubleshooting purposes.
currently using adguard dns, also have used blahdns.
The weirdest Dali fact I have is that he redesigned the Chupa Chups logo and gave them three bits of business advice, for which he charged them <Dr Evil Voice> one million dollars </Dr Evil Voice>.
So basically the Salvador Dali work everyone knows best doesn't actually involve clocks, but gets thrown in the bin thousands of times a day...
"Unlike the padlock, it has no obvious link to any real world object that hints at its function."
My eyes say it is two keys. But my house has an unusual key design throughout. (Not the usual Yale-type.) I'd not expect that interpretation to be at the top of the list for most people.
And it is horrible.
@Screwed I think your eyes have it right, it probably is meant to represent 2 keys, I can certainly see it as a simple symbolic representation of 2 keys, but that was not the first thing to spring to mind. Then again padlock was not my first thought for a square with a semicircle on top.
If Google want to replace the handbag icon with a 69 icon, fine I don't use chrome anyway. ;)
BTW you are right it is horrible.
First they all but eliminated blogs and sites not using a certificate from search results. Now they want to do this all over again? To achieve what? To exclude everyone not trying to extract a quid from people yet again from their search results? Are they all just terminally stupid at Google? Or are only mountebanks considered worthy of being found in a Google search?
More correctly: "costs... nothing with tools like Lets Encrypt."
I just started a new job, and my first job I gave myself was to list all the renewals, expiries, etc.
In the process, I discovered - as always - that we're holding tons of unnecessary and unused domain names, and a bunch of paid-for individual sub-domain SSL certificates.
First, they should have just got a single wildcard cart. Honestly, it would have be enormously cheaper.
Second, they need to stop paying for basic SSL certificates. I moved them to LetsEncrypt within an hour for the first cert (quicker than it took to discover how to go about accessing and renewing it!). Now it takes seconds to add other certs in as they expire.
It's 2023. You haven't been able to trust that someone is NOT sniffing your traffic (and that includes your web forum administrator password!) for several decades now.
Even in IIS, there are LetsEncrypt tools that just "do it all for you". You run them, select an IIS site, it generates a cert and verifies and sets up scheduled renewal and alerts you if there's a problem. On Linux / Apache, it's even easier.
There's no excuse now for using any unencrypted service on the raw internet. Whether that's DNS, HTTP, FTP, Telnet or unencrypted SMTP (which is a bugbear for myself because it should be end-to-end, not just you-to-server, it's 2023 ffs!). Even a personal forum, or a login to your own server, or your own dumping-ground storage on a remote server that you own, etc.
You literally cannot trust things to just get to their destination unread or unmodified any more, so you must encrypt.
Would you run wireless without encryption? Would you hand your bank card, or even a personal letter, to the nearest person heading in the general direction of the bank and ask them to deliver it for you?
Encryption is the norm, and now we have the processing power for it to be effectively free, there's no excuse any more. It will be the norm now, and in a thousand year's time.
Chrome - and every other browser - should have done this 20 years ago.
SMTP should have been replaced with an end-to-end encryption 20+ years ago.
If you're doing ANYTHING online and it's not encrypted, you need to stop it now. Across your home network, who cares? But even that is an issue (e.g. internal router compromised by XSS etc.). But once something leaves your house or your phone, it should be fully encrypted - if for no other reason than to stop your ISP reading your email so they can spam ads at you (which has happened!).
Hell, if WPA2 gets weakened any further, I will be forced to buy WPA3-supporting equipment for home use. As it is, at home I've used VPN-over-wireless to my own server as the default route for years as the safeguard when WEP was compromised, when WPA1 was compromised, etc. Impact on my network performance? Zero. Welcome to modern processing. Yes, I've gamed Counterstrike over VPN over wifi to a home ADSL router and had the lowest pings on the server many a time.
Chrome are literally TOO SLOW in this regard, and the OP thinks they're moving too fast. It's NOT fast enough. HTTPS by default is the norm in all modern browsers.
My only problem with it is legacy internal services with web interfaces that will alert because their certs are self-signed. But even now... my opinion is changing on that. It used to be that I'd accept plain HTTP for internal stuff. No more. Those things get replaced now if they can't do it. But there needs to be a protocol for them to secure themselves, some form of opportunistic encryption, that doesn't require clicking through obscure warnings in the browser and having to "proceed anyway". They should warn once, the user can accept, and then the browser should provide an unremovable banner on that site every time you access it to warn that you did previous accept the self-signed cert. I shouldn't have to jump through hoops to access a legacy switch or NAS device on a local network - but we have no real way for such devices to "sign" something that will work with the global SSL/TLS system if they are purely internal.
And even that - it's becoming less and less of an issue.
Hell, even at home I run another VPN out of my network through to an external server which reverse-proxies any internal services I need to be remotely-accessible (e.g. my TVHeadend and Plex servers). The remote server does LetsEncrypt on a fixed IP under my domain to secure it, then tunnels access back to my local network to actually pick up the devices (and verifies their self-signed certificates that would otherwise make a browser balk at them). I get secure end-to-end and remote access that passes all tests, and the internal devices know nothing of the encryption that's being applied to them. And I therefore get no "browser warnings" when browsing my TV or media libraries, internally or remotely. I set it up once, it's been working for about 6 years now.
There's no excuse now for using any unencrypted service on the raw internet. Whether that's DNS, HTTP, FTP, Telnet or unencrypted SMTP (which is a bugbear for myself because it should be end-to-end, not just you-to-server, it's 2023 ffs!). Even a personal forum, or a login to your own server, or your own dumping-ground storage on a remote server that you own, etc.
You literally cannot trust things to just get to their destination unread or unmodified any more, so you must encrypt.
Sometimes it doesn't really matter. Read-only/anonymous access to FTP or website to read or download something is kinda pointless to encrypt (unless you're worried it might get modified in transit or accessing dubious material I suppose).
Any tarballs you download can usually be verified reasonably well with checksum (yeah i know MD5 doesn't really cut it anymore) If someone wants to snoop me reading RFCs they're welcome to it.
Some simple data gathering and distribution within your own network with low power/small memory machines might not have the headroom (either in ROM, RAM or power envelope) to encrypt and intecception of the data might not matter anyway. (granted, this is not example of anything on "raw internet")
Obviously something with real authentication or more sensitive (for whatever reason hat might be) content you would naturally want encryption.
TLDR; it is a bit silly to make a blanket "nothing should be encrypted, its of no cost" statement.
If i visit a new site or a site via a link i often check the cert to see a bit more info as to its validity.
Apple on their IOS devices make it impossible to do that verification.
Chrome will be making it harder to do that verification on their desktop client too.
Its a backward step.
By all means make it prominent that a site is unsecured & that a cert is not valid, but also make it easy for us to check the credentials of a cert.
I guess the big thing is those sites where the spelling is slightly off.
if the browsers provided a tool that spelt the site name in all caps and asked if that was the intended site with yes closing the dialogue and no closing the window.
checking the validity of the cert just checks if the scammers can set up lets encrypt properly.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
