Chrome 90 goes HTTPS by default while Firefox injects substitute scripts to foil tracking tech When version 90 of Google's Chrome browser arrives in mid-April, initial website visits will default to a secure HTTPS connection in the event the user has failed to specify a preferred URI scheme. Lack of security is currently the norm in Chrome. As Google Chrome software engineers Shweta Panditrao and Mustafa Emre Acer …
In fact Chrome doesn't work as described and not all sites need https.
In testing https and http versions of the same site it was impossible to access the http version, even if the https was subsequently broken. Also hiding the URL prefix in the stupid omnibox is also wrong.
Chrome development is driven by ideology, not actual usability, security or privacy. Privacy? It's practically Google spyware. An elephant in the room is how it does DNS and manages trackers and communication with Google.
Also it should be up to the rewrite rules on the site and the user input what to do, not some half baked algorithm put in by a programmer at Google's request.
Chrome development is driven by ideology, not actual usability, security or privacy.
It is driven by pure commercial interests. It slowly subverts standards, good ideas and user-oriented usability into a vehicle to better support the corporate cash cow. Changes are done slow enough so that the general public does not see any problems. Those who see the problems are a (technical) minority who can be silenced easily or will simply be ignored as alarmists.
> not all sites need https.
It's _literally_ free to set up HTTPS nowadays, and performance is no longer a concern (outside of some extreme edge cases).
It's not just about the site you're accessing, it's about the network you're accessing the site via. HTTPS helps provide some in-flight security so that someone in the middle can't inject nasties (US ISPs have been caught injecting advertising).
If you're not serving via HTTPS, its your users/visitors you're putting at risk, not yourself.
Honestly, the battle for "not everything needs HTTPS" has been long-since lost.
> In testing https and http versions of the same site it was impossible to access the http version, even if the https was subsequently broken.
Sounds like a bug, report it
> Chrome development is driven by ideology, not actual usability, security or privacy.
It's driven by commercial interests, but I largely agree as a rule.
Not sure this one falls under that though - in fact, I'd posit that nowadays "not everything needs HTTPS" is an ideology rather than something supported by real-world evidence.
> Privacy? It's practically Google spyware.
It's perfectly possible for something to offer near-absolute privacy against *most* threats whilst leaving you still entirely exposed to one party. If you're married, then your bedroom curtains probably do much the same thing.
If you're using Chrome, then that involves accepting that Google are going to be Google. It doesn't mean they should just say "fuck keeping things private from others" for users that are willing to make that trade-off
> Also it should be up to the rewrite rules on the site and the user input what to do, not some half baked algorithm put in by a programmer at Google's request.
It is - if you don't want HTTPS on your site, Chrome will fall back to HTTP. If you're the user, then enter the url with a scheme (http://foo.bar) rather than just the FQDN (foo.bar).
All that's changed is the default scheme
I've been saying this for years, but kept getting downvoted. There is no excuse for a site to not use HTTPS any more. Yes, it's bad that Google have so much power (and I refuse to use Chrome except for testing purposes), but in this case, they happen to be using it to do something good. Defaulting to HTTPS is the right thing to do.
Aaaaand there are those downvotes again. Tell me why you don't think HTTPS on every website is a good idea. Is managing the certificates too difficult for you? That's just an argument for better certificate-management systems. Let's Encrypt is zero cost, zero-intervention, and seamless with my hosting provider. Give me one good reason – even any reason – you're not using it. The internet is a scary place. Your users deserve privacy.
> why you don't think HTTPS on every website is a good idea
Because browsers don't only access "websites": For instance what about admin interfaces on hardware of which would be incapable of handling encryption?
If you want to promote HTTPS, you should focus on servers, not browsers. Banning HTTP from browsers to force adoption of HTTPS would be as brain dead as removing head lights from cars to force installation of street lights....
(I didn't downvote you. I understand your point, although I think you miss the bigger picture.)
There's always an override for legacy hardware (admins should be able to figure that out), and it's nothing like the headlight analogy. It's much more like banning the sale of cars without seatbelts and leaving the manufacturers with no choice but to comply if they want to actually sell their cars, thus benefiting everyone's safety. In the mean time, existing cars without seatbelts will continue to function, but the various warnings given to people (I guess an almost-plausible analogy would be being warned on their MOT) will make them realise that seatbelts are probably a good idea in the long run. Focus on servers all you like, but some people will only change if you make them.
It's much more like banning the sale of cars without seatbelts and leaving the manufacturers with no choice but to comply if they want to actually sell their cars, thus benefiting everyone's safety.
I don't disagree with the general discussion, but mandating manufacturers to fit seatbelts would be more akin to Apache and nginx bundling a Let's Encrypt client within the package which attempts to secure every configured domain by default (with an override to disable if it's genuinely not appropriate), providing a self-signed cert as a fallback.
Forcing https in the browser is more akin to a law requiring that people use seatbelts when provided. It's a client-side behaviour which doesn't necessarily force manufacturers to ship their cars with seatbelts.
If the server is mandating TLS then it doesn't matter whether the browser requires https or not - https is all you're going to get.
Which brings me back to the fundamental problem that nginx and Apache aren't doing that, so Google strong-arming the web to its own will seems (in this case*) like the next-best thing.
(*I still hate Google, and I still don't think they should have this power: I'm just glad they're doing something I approve of with it for once)
In 2021, even Internet Relay Chat servers use TLS to secure the connection and SASL to provide a sane authentication layer. Gone are the days where it is considered acceptable to produce applications which are designed purely for trusted networks. If you wouldn’t administer your server using plaintext telnet, and you wouldn’t connect to your corporate network using PPTP, then you probably shouldn’t be surfing the web using plain HTTP.
Even if you hate the CA-driven PKI model, rather than advocating for plaintext, why not push for a pin-at-first-sight GPG key option as a fallback?
> Focus on servers all you like, but some people will only change if you make them.
Still, you focus solely on Internet use, which, while predominant, isn't the only use of browsers.
Think for instance about those increasingly present web GUIs (not necessarily Internet-connected or even on a network). What about those million-dollar software/machine tools, commercially EoL for years, yet able to keep working for decades? Millions of workshops and labs around the world have them. Note those devices/software are used by highly skilled technicians who are not computer savvy (yes, it's possible), so their use has to stay simple: They aren't paid to wrangle with the computer, but to use it to do their job.
It's much akin to those companies still running WinXP computers because they just can't afford to throw away a perfectly working multi-million machine tool. From an IT specialist's point of view it's a no-no, but remember it is the "IT specialist" who put them in that situation in the first place... You can't punish people for your own failures. Or at least you shouldn't.
On the big scary old internet, sure. But browsers and HTTP are used for a lot more than public facing websites.
Web servers also run on ESP8266 or similar chips with minimal resources, or from a few line of JS I've cobbled together into a single-purpose service. I do not want to be forced into managing certificates for these cases, and as they're all running on my LAN I'm not worried about the 133t hackerz.
It may be zero cost and seamless from your provider, but some providers 'make' you pay through the nose (e.g. >£50 annually for a single domain SSL certificate from Heart Internet).
That's fine for businesses, but OTT for a small club or charity website that doesn't collect information or sell stuff online.
"e.g. >£50 annually for a single domain SSL certificate from Heart Internet"
Are you saying that Heart Internet doesn't offer you LetsEncrypt certs for free (as well as paid-for certs for those who do want them)?
In that case, switch to a competent hosting company which does!
If your hosting company doesn't offer LetsEncrypt just switch.
That's likely fine for many here, but for many volunteer groups, sports clubs, whatever - it isn't "just switch".
"What's hosting?"
Why not just implement LetsEncrypt? Because for a lot of people it's a bit more than trivial.
> (e.g. >£50 annually for a single domain SSL certificate from Heart Internet).
The problem there is your provider (and actually, having recently left Heart, it's far from the only problem with them - unsurprising given their owned by GoDaddy).
They're one of relative few hosting providers who now don't offer free SSL certs via LetsEncrypt.
Hell, if you really wanted to stick with Heart for hosting (due to cost of moving), you could still get free SSL between you and the end-user by fronting with a free Cloudflare account.
> That's fine for businesses, but OTT for a small club or charity website that doesn't collect information or sell stuff online.
SSL isn't just about the data the end-user is sending to your site, it also helps prevent tampering with the responses you're sending back to them.
(e.g. >£50 annually for a single domain SSL certificate from Heart Internet).
If Heart don't have Let's Encrypt enabled for their cPanel hosting & Wordpress hosting then move. I can recommend UnlimitedWebHosting(.co.uk). They keep up to date with new versions of cPanel & Plesk, including niceties like the Let's Encrypt plugins.
UWH do indeed offer SSL certs separately on their site, but that's if you want an EV or just like spending money. It's got Let's Encrypt included.
UWH also voted correctly in the Nominet EGM, whereas Heart are owned by GoDaddy (via Host Europe Group).
Host British!
Because I have a server in the other room, on the same network, behind a firewall. What reason do i have to pay for a domain name that I'm only going to be accessing, and be the only one accessing, on my home network, behind NAT, and behind a firewall, because there's no other way to get certificate that Chrome/Firefox/etc will trust (without more machinations)?
I'm pretty sure there are reasons to not parse an HTTP response while you're waiting for an HTTPS one to come - or not. However, you'll bookmark your http-//-my-device - or just the IP address - and use that.
That's a thought though - shouldn't a security conscious browser try to convert HTTP bookmarks to use HTTPS instead. Do they already? I don't think so, because I think that would be mayhem and I'd have noticed.
Most of the devices on my network have either an unsecure website for configuration and management or one with a self-signed certificate that the browser barfs at.
I agree, out on the web this shouldn't be a problem any more, but for admins, who spend a lot of time with internal tinkering, http:// is still a daily reality.
That said, pushing to open https:// first, when nothing is supplied is a good default. Once it knows a site is http:// only, it should remember that and stick with it.
Brave does upgrade connections to HTTPS automatically by default and has done so for at least 6 months, despite being based on Chromium.
It also has an icon in the url bar to turn of strict HTTPS for the current site you are on.
What annoyed me with Chrome a few years back is when they decided to hide the HTTP/HTTPS from the URL bar so if you wanted to copy and paste a domain from the url bar to say ping it, you also got the invisible HTTP/HTTPS meaning you had to edit the paste every time.
Looking forward to more advances in the browser anti-tracking and also keeping an eye on Googles 'new privacy features' which will do nothing to increase my privacy.
What I would really like would be to be allowed to make my own choices and decisions, rather than having some external party I can't influence in any way tell me what I can and cannot do. The epitome of this is of course Goooooooooooooooooogle, whose search results are based, not on what you submitted as search terms, but on what they think will be most profitable to show you, based extremely loosely on every possible permutation of your search terms - including substrings from keywords.
Enforced controls are no real substitute for informed users as they get progressively cicumvented in the arms race. However keeping users uninformed generates a lot more dosh, so enforced controls are the sticking plaster.
Sadly, "informed users" are and always will be in the minority now. The internet has become a commodity thing (like watching TV), and that means 90% of people don't really give a f*ck as long as they can get their cat videos. This is why I believe making the better/safer choice the default and allowing an opt-out for people who know what they're doing is really the only way forward. As long as there is an opt out, that is.
Along with localhost, I would also default to HTTP for anything that resolves to a private network (10.x.x.x, 172.16-31.x.x, 192.168.x.x and 127.x.x.x). A lot of localised services won't support https, but as they aren't external it's not so important. Not all photocopiers, toasters and wifi dild0s have valid SSL certificates.
>"valid SSL certificates"
There are valid certificates and those which browsers now deem to be valid.
Remember, in todays internet, any certificate with a an expiry date longer than a year is now deemed untrusted/invalid...
So now all those appliances now need regular updates just to keep the certificate 'valid'.(*)
(*) I see Draytek have updated their firmware to auto regenerate the self-signed certificate so that it never actually expires, so avoid this unnecessary annual update.
In the past I had different content on my HTTPS server than I did on my HTTP server (same IP, different virtual hosts), as they were used for different tasks. For most sites; this is generally not the case, and shouldn't really be on customer/luser facing sites, as it is probably confusing, but you have to hope that you can force HTTP protocol in those cases.
There are also issues with old devices where the HTTPS is actually no longer safe, from a security perspective, and actually using the HTTPS on those devices would lead to a "false sense of security"
This post has been deleted by its author
Sometimes I wonder how us old fogies ever made it through the internet of the 90s and 00s in one piece without the Invisible Hand of Privacy guiding our every move, or alternatively beating us into submission if we dare stray off the cordoned-off path.
Oh right, I think they told us to not give out any personal information and always use a nickname online. Don't talk to strangers, basically.
I put up a page to share information, I don't use cookies, or even JS. There is zero need for httpS on these pages, but now goog decides to block it - it cannot be in the name of security - if it was the goog wouldn't be sniffing everyones data out of chrome like biden sniffing .... (hah I didn't say which one of them).
"this will improve performance since the delay incurred by redirection from an http:// endpoint to an https:// endpoint will no longer happen" ... but now everything have to run through the SSL translation.
Certainly HTTPS is essential for secure data access but the majority of websites are just junk - so I guess we'll have secure junk now?
The point being that with HTTPS, nobody "on the wire" can see precisely* which kind of junk you like looking at (pun firmly intended). This matters in many contexts, from simple avoidance of casual snooping to living under regimes that are or may become repressive (death by stoning for homosexuality, anyone?).
*Yes, they can possibly see the domain name and almost certainly the IP address, but those are different problems.
On my bluehost hosted website I noticed that https suddenly started working. So you can access my pages either with http or https without any effort on my part. There is no redirection from one to the other but all of my links on the website are relative so will inherit the prefix.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
