Chrome will soon try HTTPS first when a user types an address in the browser
Google Chrome users have several options when it comes to loading sites and web applications in the browser. They may click on links, use bookmarks, or type in the address bar to open sites directly.
If a user types a full domain name with protocol, it is opened as it is, but what happens when the user does not specify the protocol? When you type ghacks.net and hit the Enter-key, is Chrome loading the HTTPS site directly or trying HTTP first?
It turns out that Chrome is trying the HTTP version by default; this made sense for a very long time as most sites did not use HTTPS. Now, with the ever increasing percentage of HTTPS sites, it is the share of sites using the HTTP protocol that is getting smaller and smaller.
Google plans to introduce functionality in the company's Chrome web browser to make HTTPS the default.
A recent Chromium commit, spotted by Windows Latest, confirms the plan.
Default typed omnibox navigations to HTTPS: Initial implementation
Presently, when a user types a domain name in the omnibox such as "example.com", Chrome navigations to the HTTP version of the site (http://example.com). However, the web is increasingly moving towards HTTPS, and we now want to optimize omnibox navigations and first-load performance for HTTPS, rather than HTTP.
The initial version of the implementation is just a first step according to Google. It will modify code so that omnibox and auto-complete codes use HTTPS as the default. Google calls this "upgraded HTTPS navigations".
Chrome will fall back to HTTP if HTTPS is not supported by the site in question. SSL errors are ignored by Chrome if the HTTPS connection fails provided that it was part of an HTTPS upgrade.
The current implementation is not ready for general use according to Google. One shortcoming is that it waits for the HTTPS connection to load or to fail before trying HTTP. Future versions will cancel the load automatically to try HTTP connections.
The feature will be implemented in Chromium and it will, as such, become part of other Chromium-based web browsers such as Vivaldi, Microsoft Edge, Opera or Brave as well.
Google did not reveal performance information; it seems unlikely that users will notice a positive effect but it is quite possible that HTTP sites may load slower, at least initially because of the change.
Mozilla introduced an optional HTTPS-only mode in Firefox recently in Firefox 80.
Surprising but not surprising. If https first affected ad revenue, Google would have done this long ago.
Finally! Better late than never.
All these settings will be useful for something when HTTP3 arrives? :[
Good. The entire web should be served over HTTPS.
As if this does not happen already? In any (reasonable) up-to-date browser? Even if you type: http://192.168.1.xxx/name.of.local.test.or.development.website
(where xxx is a number between 1 and 254)
you more often than not get https put automatically in front. That is already pretty infuriating, if I’m honest.
Wish there was a good way to turn all those “helpful” functions off in browsers, if I type in where I want to visit, that is exactly where I want to visit. Not where Chrome/FireFox/Opera thinks I should go. Sure, I have turned off those features, using the about:config pages, but it appears those changes are not really respected by browsers.
It wouldn’t be so bad if their guess was correct about 80% of the time. But in my case that percentage lies around 20%. Been online since 1996, been building/repairing computers even before that, been working in IT all that time too. Just to indicate that the “guiding hand” of modern browsers, pushing a pro-user to a location that wasn’t specified, isn’t appreciated.
Actually, it doesn’t happen like that already. Open the browser’s dev tools and watch what happens if you type in ghacks.net and hit enter. First, the browser tries http://ghacks.net/, assuming you want HTTP 99.99% of the time. The site wants you to use HTTPS instead, so it sends back a 307 redirect response pointing to https://ghacks.net/. The browser requests that, but the site responds with a 301 redirect to https://www.ghacks.net/. The browser makes that third quest and finally gets here.
The change is the browser skipping a step ahead and assuming HTTPS first, since that’s what most sites use now anyway, saving you from making, and waiting for, an unnecessary HTTP request. One that has potentially serious security & privacy ramifications should the request be intercepted.
And note that without that “helpful function,” every time you type in “ghacks.net” and hit enter, the response would be: “Error: You failed to type out the protocol and subdomain for that URL; try again, silly human!”
Strange behavior. If I type 192.168.1.1 (nothing secret about that) to access my LAN router or enter the IP’s of any device on my LAN, the connection URL shows as http with a not secure symbol. FF and Chromium do the same thing.
This option is not good a good choice if there is not an option to fallback automatically to HTTP instead if HTTPS is not available at once. At least this option should exist. In Firefox is a mess, it does not work good near always, also including when trying to make some kind of whitelist (sometimes it works, sometimes not, with no reason), and I gave up completely of dealing with it because the advice of “non HTTP is not available” is able to stop navigation including sites inside in a HTTPS site itself (non secured content activate this option in FF, so what?). :[
The fallback level can be set in FF. Lots of info on how to do that online.
I meant “automatic fallback” with no advice about to continue or not to the site. :[
I think you missed the line in the article:
“Chrome will fall back to HTTP if HTTPS is not supported by the site in question.”
That’s the problem, which time is enough to resolve the non HTTPS supported site? In Firefox some sites takes more than 5 seconds to discover what to do and then appears an advice about what to continue or not, even inside HTTPS sites when non secured content is founded! :[