Yesterday, Apple released Safari version 18.2, included with iOS 18.2 and macOS 15.2, as a separate update for macOS 14 and 13. I've already discussed one new feature of Safari 18.2, Copy Link with Highlight, in another blog post. Now I'd like to discuss another new feature, automatic https upgrade. From Apple's announcement:
Safari 18.2 on iOS, iPadOS, and visionOS will always try to load webpages over secure connections first, i.e. HTTPS by default. Only if the secure page load fails will Safari fall back to non-secure HTTP.
In addition, on all platforms, Safari 18.2 also adds an optional Security setting to enforce secure connections and show a warning before attempting a non-secure fallback. The user then gets to choose if they want to cancel or continue over HTTP. The label of the setting is “Not Secure Connection Warning” on iOS, iPadOS, and VisionOS. It is “Warn before connecting to a website over a non-secure connection” on macOS.
I believe there's an oversight in the first paragraph, because HTTPS by default appears to apply to macOS as well as to iOS, iPadOS, and visionOS.
Here's an example: if you click the insecure http link http://example.org, Safari 18.2 will automatically, silently load the secure https link https://example.org instead.
There's a confusing caveat: the https upgrade feature does not apply to URLs entered in the Safari address bar. So if you copy and paste the URL rather than clicking it, Safari will load the insecure http link, not the secure https link.
I've seen mixed results with bookmarks: if you bookmark an http URL, macOS Safari loads the bookmark as insecure http, whereas iOS Safari upgrades the connection and loads the bookmark as secure https.
Adding to the confusion, macOS Safari does upgrade the connection to https if you select an http URL as a Top Hit in the address bar, even if that URL is a bookmark!
All of the behavior I've described above occurs automatically in Safari 18.2, whether you like it or not. Safari 18.2 has also added a new setting called "Warning before connecting to a website over HTTP" on macOS (slightly contrary to the wording quoted above from Apple's blog post) and "Not Secure Connection Warning" on iOS (somewhat ambiguous, ought to be rephrased as "Insecure Connection Warning").
Ironically, you probably won't ever see this warning, and you might conclude that the new Safari setting doesn't work. That's what I thought at first. There are two reasons for the confusion: (1) Safari won't warn you if it can perform automatic https upgrade, because then you don't need to be warned; (2) Safari warns you only in situations where it would apply automatic https upgrade. To elaborate on the second reason, we already know that Safari does not apply https upgrade to URLs that you enter into the address bar. Thus, if you paste an http URL into the address bar and load it, Safari will neither upgrade the connection to https nor warn you about loading over an insecure connection. In other words, if you're entering a URL manually, Safari assumes that you know what you're doing and thus does precisely what you specify, without second-guessing you.
So when would you see the warning? Two conditions need to apply: (1) Safari attempts to perform an https upgrade, and (2) Safari fails to perform the https upgrade. If you want to see the warning in action, you can click on a link to an http-only website, http://httpforever.com for example. An http-only website lacks a valid certificate, so it can't use an https connection.
Again, you won't see this warning if you paste http://httpforever.com into the address bar. The warning appears only when you click the link (or when you select an "Open" item in the Safari contextual menu). By the way, you will see the connection warning in the contextual menu's link preview, so kudos to Apple for testing that scenario.
One more thing: I found a bug. The new Safari setting doesn't work right with http://localhost URLs. Instead of showing the warning, Safari blocks the URL, with no option to load.
I'll file a bug report with WebKit after I've published this blog post.