Last Updated on December 4, 2023
As Google moves to change how its Chrome browser flags insecure websites, rival browsers may be forced to follow suit. Here’s how other browsers currently handle website security and what changes they have coming.
Google last week spelled out the schedule it will use to reverse years of advice from security experts when browsing the Web – to “look for the padlock.” Starting in July, the search giant will mark insecure URLs in its market-dominant Chrome, not those that already are secure. Google’s goal? Pressure all website owners to adopt digital certificates and encrypt the traffic of all their pages.
The decision to tag HTTP sites – those not locked down with a certificate and which don’t encrypt server-to-browser and browser-to-server communications – rather than label the safer HTTPS websites, didn’t come out of nowhere. Google has been promising as much since 2014.
Apple’s browser currently uses the traditional model of signage: It puts a small padlock icon in the address bar when a page is protected by a digital certificate and traffic between the Mac and site server is encrypted.
No padlock? That means the site does not encrypt traffic.
Recent versions of the browser, however, take additional steps in certain circumstances. If the user is at an insecure site – one not locked down with a certificate and encryption – and attempts tasks such as entering info into log-on fields or those designed to accept credit card numbers, Safari throws up a red text warning in the address bar that starts as Not Secure and then changes to Website Not Secure.
Those hard-to-miss alerts debuted with the version of Safari bundled with macOS 10.13.4, an update issued March 29. (Mac owners running OS X 10.11 (El Capitan) or macOS 10.12 (Sierra) got the same functionality in the Safari 11.1 update on the same day.)
The Website Not Secure warning also should appear if the certificate is out-of-date or illegitimate.
Mozilla’s browser is on a path similar to Google’s Chrome; it will eventually tag all sites sans encryption with a distinctive marker. But Firefox is not there yet.
Currently, Firefox shows a padlock with a red strike-through line when the user reaches an HTTP page that contains a username+password log-on combination. Placing the cursor in one of the fields – by clicking in one, for instance – adds a textual warning that reads This connection is not secure. Logins entered here could be compromised.
Otherwise, tradition still rules in Firefox: HTTPS websites are marked by green padlocks in the address bar, while regular HTTP pages are unmarked.
Mozilla has committed to reversing the iconography, though. “Firefox will eventually display the struck-through lock icon for all pages that don’t use HTTPS [emphasis added], to make clear that they are not secure,” wrote Tanvi Vyas and Peter Dolanjski, a security engineer and product manager, respectively, in a blog post over a year ago. “As our plans evolve, we will continue to post updates, but our hope is that all developers are encouraged by these changes to take the necessary steps to protect users of the Web through HTTPS.”
The mark-all-HTTP feature is tucked inside Firefox, but it’s not been enabled in the current production-quality browser, Firefox 60. Users can switch it on manually, however.
- Type about:config in Firefox’s address bar
- Search for security.insecure_connection_icon.enabled
- Double-click that item; the false under Value will change to true
You can test the change by entering an HTTP page into the address bar, like bbc.com.
Chrome still uses the usual padlock to mark HTTPS sites and does not call out unencrypted traffic (HTTP), at least at a quick glance to the address bar. (Clicking the information icon in the address bar, the symbol of a lowercase i within a circle, at the left of the URL, displays a drop-down that does call attention to existing insecure connections, however.)
And since 2017, Chrome has tagged sites that transmit either passwords or credit card information over HTTP connections as Not secure using text in the address bar.
But Google has scheduled several additional steps for this year that will move Chrome closer to a goal of overturning decades of visual signals that mark traffic encryption.
The changes begin in July with Chrome 68 – set to ship the week of July 22-28 – that will mark all HTTP sites with text that reads Not Securepreceding the URL in the address bar.
Users can enable Chrome 68’s behavior with these steps in the current Chrome 66:
- Type chrome://flags in the address bar.
- Find the item Mark non-secure origins as non-secure.
- Select Enable (mark with a Not Secure warning) and relaunch Chrome.
- Optionally, choose Enable (mark as actively dangerous)instead to display the red icon, too.
Next, Chrome 69 – slated for release during the week of Sept. 2-8 – the browser will drop the green Secure text from the address bar for HTTPS pages and show only the small padlock icon. Google characterized that as a step away from affirmatively noting a secure page, and toward a more neutral label.
Then in October, Chrome 70 will appear (during the week of Oct. 14-20), labeling any HTTP site with a small red triangle to indicate an insecure connection, along with the text Not secure in the address bar. Those signals show as soon as the user interacts with any input field.
> See Also – Is It Important To Have An SSL Certificate?
In much the same way as Apple’s Safari, Microsoft’s lead browser has stuck with the HTTPS-is-marked, HTTP-is-not model.
Edge displays a padlock icon in the address bar when the page is protected by a digital certificate, and traffic between the Windows 10 PC and server is encrypted. If there is no padlock, the site does not encrypt traffic, relying on HTTP instead.
To get the full story, however, users must click on the icon – an i within a circle – and read the text in the ensuing pop-up. “Be careful here,” Edge warns. “Your connection to this website isn’t encrypted. This makes it easier for someone to steal sensitive information like passwords.”
Unlike Safari, Firefox and Chrome, Edge does not proffer special warnings when the user visits an HTTP site sporting important input fields, like those dedicated to passwords or credit card numbers.