Google Chrome Will Finally Default To Secure HTTPS Connections Starting in April (engadget.com) 35
An anonymous reader shares a report: The transition to the more-secure HTTPS web protocol has plateaued, according to Google. As of 2020, 95 to 99 percent of navigations in Chrome use HTTPS. To help make it safer for users to click on links, Chrome will enable a setting called Always Use Secure Connections for public sites for all users by default. This will happen in October 2026 with the release of Chrome 154.
The change will happen earlier for those who have switched on Enhanced Safe Browsing protections in Chrome. Google will enable Always Use Secure Connections by default in April when Chrome 147 drops. When this setting is on, Chrome will ask for your permission before it first accesses a public website that doesn't use HTTPS.
The change will happen earlier for those who have switched on Enhanced Safe Browsing protections in Chrome. Google will enable Always Use Secure Connections by default in April when Chrome 147 drops. When this setting is on, Chrome will ask for your permission before it first accesses a public website that doesn't use HTTPS.
April? (Score:1)
Re: (Score:2)
And thus all the content out there that is running on perfectly acceptable hardware will now be lost media unless you visit it via archive.org
The chrome developers have done so much damage to the public web with the "Everything SSL" approach. Sites that work perfectly fine, especially in Japan, never bothered to upgrade to HTTPS.
End of Innocence (Score:2)
Remember when browsers would by default ask for your permission to connect to a secure site?
Innocent times...
Re: (Score:3)
Re: (Score:3)
Facebook cookies being stolen via shared Wifi hotspots was also a big motivator for Facebook to move to HTTPS by default as well.
Re: End of Innocence (Score:2)
Re: (Score:2)
Yes it's true, Google's interest in security is purely selfish. It's about protecting their data from being poached by other companies, nothing else.
Next up: screw us over by disabling HTTP entirely (Score:5, Interesting)
While this change is a good thing, I foresee a dark path ahead: One day we will wake-up to find that Chrome removed HTTP support. Suddenly technicians around the world won't be able to access all the little-known web services running on their own machines, or on LAN-based IoT devices, where security is not important and the chip doesn't have the CPU power to run AES. Google will back it out for a few months, then unexpectedly turn it on again and claim that HTTP is deprecated so everyone had an ample 2 months to redesign and redeploy millions of devices.
I have been burned by Google executing this pattern on other browser features like JavaScript, HTML, or certificates because they seem to think that browsers are only used for public web sites.
Re: (Score:2)
For quite some time I've been keeping really old versions of Firefox and java plugins in order to manage some very old but still critical stuff on the corporate internal network
Re: (Score:1)
Re: (Score:2)
Same. I made the bonehead move of upgrading the firmware on a large TrippLite UPS which forced Java applets instead of HTTP and of course Eaton abandoned it with haste so now I have like a Fedora 14 VM just to change its settings. Which is such a pyramid of stupid decisions.
Yet it keeps on trucking on a lonely VLAN and replacement batteries every several years are quite cheap.
Re: (Score:2)
THIS. I have some Raritan lights out management boards that need some Java run in a way that isn't at all supported in any modern browser, even with any tweaks, whitelisting or anything. They have an app now but such older boards aren't supported. The only simple way to connect is just to use a VM with Windows 7 and Internet Exploder. Then I realized even Windows 98 would do, faster and the VM is tiny. Faster CPUs need a small patch but work just fine (as long as it's still on an x86 CPU, I just couldn't fi
Re: (Score:2)
we used to have several hundred TrippLite ATSes (automatic transfer switches) where the netmgmt cards at the time used that stupid & slow Java applet.
years later they came out with the WebcardLX that dumped Java for HTML and were backwards compatible
Re: (Score:2)
Self-signed certs won't do any good if the old NAS, etc. doesn't have a means of importing a certificate, does not support TLS 3, etc. Google's forced "security" treadmill is not that different from Microsoft's TPM 2 dependency for Windows 11: Both do little more than annoy users and generate e-waste.
Re: (Score:2)
Re: (Score:2)
Just block raw HTTP unless it's in a private IP address range. That should cover 99% of use cases where HTTP is still used. I would also consider allowing an option to blindly accept self-signed certificates on private IP ranges to encourage HTTPS for people too lazy to use Let's Encrypt or something like that, or are running older equipment on a local LAN.
I would assume these are already settings that just aren't turned on by default, as they seem pretty obvious.
You still need a domain name (Score:2)
I would also consider allowing an option to blindly accept self-signed certificates on private IP ranges to encourage HTTPS for people too lazy to use Let's Encrypt or something like that
Does "too lazy" include no budget for a domain name before the proof of concept is complete? Let's Encrypt doesn't work unless you buy a domain name and keep it renewed. To satisfy a DNS-01 challenge, you need to host the domain's DNS at a provider with an API that an ACME client can use. To satisfy an HTTP-01 challenge, you need to be on an ISP that allows incoming connections on port 80. A lot of home ISPs block inbound port 80 because they use carrier-grade network address translation (CGNAT) or want to
Re: (Score:2)
Without disagreeing on your principles, you could do this with a $3 numeric .xyz domain and the free DNS tier at Namecheap.
https://www.namecheap.com/doma... [namecheap.com]
There's probably noone building a prototype network app who can't swing $3 and run the ACME client.
The people who make money on certs really hate distributed ideas like DNSSEC and DANE and its successors.
There are Ethereum domains too now but Ether gas is way more than $3.
Re: (Score:2)
You are completely missing the point. This provides no benefit to anyone, and there are plenty of devices that simply cannot possibly do HTTPS. HTTP is a valid protocol, and just because something is not secure is not a reason to have corporations banning it.
Re: (Score:2)
Chrome based browsers already made it a lot harder to use sites with self signed certs as well - I had a VSphere server on my local network that had a self provided self signed cert, and actualy accessing the server got progressively more and more difficult (and there was no way to change the cert). At one point I had to type in "this is dangerous" to get the browser to actually give me an option to proceed.
Re: (Score:2)
Some old wallwarts,wired into home net -- not visible externally--, have to be http and cannot work
with modern browsers. And basic internal net at home, it seems odd to insist on https.
Re: (Score:2)
I've already run into this problem with Firefox. Obviously web pages still work fine, but if you want to download files via normal HTTP, the Firefox download interface will frequently cancel downloads for security reasons without offering an override. I have to use Palemoon to download files from old archive sites in these situations.
Re: (Score:2)
Are you sure they are cancelled? When I've run into this the "insecure" file is sitting there with the temporary name used during downloading. Renaming it manually as desired ends up with what was expected.
Re: (Score:2)
This has already happened with KVM-over-IP devices. The device was perfectly usable until a hack for the old version of Java it used kept attacking it, and thus it had to be turned off.
Re: (Score:2)
Unfortunately it usually takes Google a few years minimum to deprecate any feature, and they are more likely than not to abandon the attempt before reaching the deadline. See 3rd party cookies.
I can see them adding further warnings, or disabling HTTP for non-local addresses, but if they announced it today it wouldn't happen for at least 3 years.
triggering "sign in" pages for public wifi (Score:5, Interesting)
I have one pain in the arse use-case for NOT wanting https all the time, and to have it use http when i ask for it.
public wifis don't always trigger the o/s (in my case, a mac) to prompt with the page that allows you to sign in (be it public password, here's my email, whatever). So when that doesn't happen, you have to to go an http page to trigger it. https urls won't do that because, well, the cert that would come up from the internal service is wrong for the domain and so the browser barfs at that. So i have to go to an http page and NOT have the browser intercept it and try to do https instead.
Re: (Score:2)
The sign-in pages are stupid. Most of them are worthless click-throughs that should go away. A few do have you do some sort of sign-in, so they should be https.
But the whole process is a stupid hack. They did add a new DHCP option for sending a sign-in URL, but it was never widely adopted. That would have made it work much more reliably for everyone.
Re: (Score:2)
Type an IP address in the search bar.
https only is a trap (Score:2)
Making http difficult or impossible to use is a bad idea that erodes freedom and dramatically shifts the balance of power to CA/B and corporate whores behind it. For https to work you need a certificate and a domain both of which requires blessings of third parties to obtain and keep.
The deal with certificates is constantly changing as CA/B unilaterally does whatever the hell they want. In a couple years time you will need to obtain a new certificate every month and a half. What's to stop them from chang
Netscape browsers had this warning for non-SSL sit (Score:2)
As an option, though, not by default. I always kept it enabled, even though I had to dismiss the pop-ups frequently. Quite a few forms I didn't submit because of the warming, though.