In my blog post, “The Quiet HTTPS Revolution,” I noted that almost every network connection from my phone and laptop is protected by the HTTPS protocol. In this letter, I call on browser and OS manufacturers to eliminate unprotected connections by the end of 2025. Failing to do so would neglect their duty to safeguard all users.
Let’s first look to the past. In 1995, Netscape introduced the SSL security protocol to protect internet connections. SSL was a foundational protocol that developers could layer with higher-level protocols. A common use case was layering HTTP on top of SSL to create HTTPS connections.
I played a small part in this evolution. In 1998, I took over as the manager of Netscape’s NSS cryptography libraries. My work included collaborating with certification authorities (CAs) enrolled in our root certificate program and working with the UI team to ensure end-users could recognize when a website was encrypted using HTTPS. At the time, few websites used HTTPS for all their web pages. Most relied on SSL solely to secure usernames and passwords during login.
Fast forward to early 2025, and the landscape has transformed dramatically. Google reports that most Windows Chrome users load web pages over HTTPS more than 90% of the time. In the United States, Chrome users load 98% of their pages over HTTPS. Android users globally benefit from HTTPS protections at least 94% of the time, with U.S. users reaching 99%.
Similarly, Firefox users load pages over HTTPS more than 80% of the time globally, and 93% of the time in the U.S.
Why has HTTPS adoption increased? Credit is due to standards bodies like the IETF, software library developers, browser makers, operating system vendors, website maintainers, CAs like Let’s Encrypt, and many others. These groups have tirelessly driven the “quiet HTTPS revolution.”
However, as HTTPS adoption has surged, the threat landscape has also evolved. While attacks by “evil baristas” have been overstated, attackers can — and do — control parts of networks to eavesdrop on or modify our connections. Treating all networks as hostile is no longer paranoid; it’s today’s objective reality. Foreign intelligence operations have compromised multiple telecommunications systems, underscoring that risks extend far beyond coffee shop Wi-Fi.
Given these risks and our proximity to universal HTTPS adoption, it’s time for software manufacturers to take decisive action in two main areas.
First, mobile OS manufacturers must enforce HTTPS for all apps. The iPhone and Android operating systems should prohibit apps from establishing non-encrypted connections and reject apps that fail to secure all network interactions. There will, of course, be some exceptions, but those should be hard for the app developers to justify. There has been progress in this area, such as iOS 18.2 making HTTPS the default for web page loads. Also, in my tests, apps seemed to load pages over HTTPS almost all of the time. But we need to transition from “almost all” to “all”.
Second, all browser makers should complete the web’s migration to HTTPS with the goal of ensuring users never encounter unprotected websites. This requires making it increasingly difficult to access unprotected pages in desktop browsers and ensuring all assets, such as images and JavaScript, are securely loaded.
Undoubtedly, there will be pushback to eliminating non-HTTPS pages. Some websites are abandoned, while others are run by sole proprietors unaware of the need to upgrade. Financial, cultural, or local barriers may also exist. While some of these concerns are valid, we must acknowledge that all networks are hostile, and it is malpractice for software makers to expose their customers to preventable risks. Asking users to decide whether to “trust” a site is both unrealistic and unfair, as most lack the technical background to make such judgments. And we can all fall for a scam.
Software makers can do more than enforce HTTPS. They can foster community support to address non-HTTPS sites. For example:
- Create a list of non-secure domains.
- Contact the owners of those sites directly, or via vetted agents.
- Provide resources to help site owners migrate to HTTPS.
- Facilitate connections between site owners and volunteers willing to assist.
- Collaborate with organizations like the Internet Archive to preserve abandoned sites.
- Partner with hosting providers to offer migration discounts.
- Support initiatives like Let’s Encrypt through community contributions.
These companies should set a firm deadline for completing the migration. I propose October 31, 2025. Think of it as banishing the ghosts of unsafe connections by Halloween. This date provides enough time for a phased transition while minimizing ongoing risks to users. By this date, there should be no reason for non-technical users to encounter unprotected sites.
In the 30 years since SSLv2’s publication in 1995, we’ve made extraordinary progress. The software companies need to finish the job in 2025.
