Universal access is at the heart of the World Wide Web. It’s also something I value when I’m building anything on the web. Whatever I’m building, I want you to be able to visit using whatever browser or device that you choose.

Just to be clear, that doesn’t mean that you’re going to have the same experience in an old browser as you are in the latest version of Firefox or Chrome. Far from it. Not only is that not feasible, I don’t believe it’s desirable either. But if you’re using an old browser, while you might not get to enjoy the newest CSS or JavaScript, you should still be able to access a website.

Applying the principle of progressive enhancement makes this emminently doable. As long as I build in a layered way, everyone gets access to the barebones HTML, even if they can’t experience newer features. Crucially, as long as I’m doing some feature detection, those newer features don’t harm older browsers.

But there’s one area where maintaining backward compatibility might well have an adverse effect on modern browsers: security.

I don’t just mean whether or not you’re serving sites over HTTPS. Even if you’re using TLS—Transport Layer Security—not all security is created equal.

Take a look at Mozilla’s very handy SSL Configuration Generator. You get to choose from three options:

  1. Modern. Services with clients that support TLS 1.3 and don’t need backward compatibility.
  2. Intermediate. General-purpose servers with a variety of clients, recommended for almost all systems.
  3. Old. Compatible with a number of very old clients, and should be used only as a last resort.

Because I value universal access, I should really go for the “old” setting. That ensures my site is accessible all the way back to Android 2.3 and Safari 1. But if I do that, I will be supporting TLS 1.0. That’s not good. My site is potentially vulnerable.

Alright then, I’ll go for “intermediate”—that’s the recommended level anyway. Now I’m no longer providing TLS 1.0 support. But that means some older browsers can no longer access my site.

This is exactly the situation I found myself in with The Session. I had a score of A+ from SSL Labs. I was feeling downright smug. Then I got emails from actual users. One had picked up an old Samsung tablet second hand. Another was using an older version of Safari. Neither could access the site.

Sure enough, if you cut off TLS 1.0, you cut off Safari below version six.

Alright, then. Can’t they just upgrade? Well …no. Apple has tied Safari to OS X. If you can’t upgrade your operating system, you can’t upgrade your browser. So if you’re using OS X Mountain Lion, you’re stuck with an insecure version of Safari.

Fortunately, you can use a different browser. It’s possible to install, say, Firefox 37 which supports TLS 1.2.

On desktop, that is. If you’re using an older iPhone or iPad and you can’t upgrade to a recent version of iOS, you’re screwed.

This isn’t an edge case. This is exactly the kind of usage that iPads excel at: you got the device a few years back just to do some web browsing and not much else. It still seems to work fine, and you have no incentive to buy a brand new iPad. And nor should you have to.

In that situation, you’re stuck using an insecure browser.

As a site owner, I can either make security my top priority, which means you’ll no longer be able to access my site. Or I can provide you access, which makes my site less secure for everyone. (That’s what I’ve done on The Session and now my score is capped at B.)

What I can’t do is tell you to install a different browser, because you literally can’t. Sure, technically you can install something called Firefox from the App Store, or you can install something called Chrome. But neither have anything to do with their desktop counterparts. They’re differently skinned versions of Safari.

Apple refuses to allow browsers with any other rendering engine to be installed. Their reasoning?


Have you published a response to this? :


Trys Mudford

Oooh, this smacks of non-functional requirements and trade-offs! 👀

Jeremy Keith raises a point that I’ve been ponding on for a long time. The web has always been backward compatible, but using https is not (specifically through versions of TLS).

He had direct feedback from one of his community members who couldn’t access the site. Apple is the problem again.

On desktop, that is. If you’re using an older iPhone or iPad and you can’t upgrade to a recent version of iOS, you’re screwed.

I’ve seen this when I’ve tested some sites with IE6 on older Windows machines - sure just a test, but real people will encounter this brick wall too.

Do we make our sites secure and lock individuals out, or do we run with insecure (non-encrypted http requests), but support everyone?

I think the answer is simple, but as always, context is what will drive the decision.


# Wednesday, March 4th, 2020 at 11:03am


# Shared by Scott Jehl on Tuesday, March 3rd, 2020 at 3:57pm

# Shared by Trys Mudford on Tuesday, March 3rd, 2020 at 4:07pm

# Shared by Gunnar Bittersmann on Tuesday, March 3rd, 2020 at 5:19pm

# Shared by Bryan J. Bell on Tuesday, March 31st, 2020 at 3:59pm


# Liked by Chris M. on Tuesday, March 3rd, 2020 at 4:03pm

# Liked by Sid Vishnoi on Tuesday, March 3rd, 2020 at 4:26pm

# Liked by Spawn Design on Tuesday, March 3rd, 2020 at 4:27pm

# Liked by Trys Mudford on Tuesday, March 3rd, 2020 at 4:28pm

# Liked by Matthias Ott on Tuesday, March 3rd, 2020 at 9:38pm

# Liked by mason conkright on Tuesday, March 3rd, 2020 at 9:38pm

# Liked by Jamie Tanna on Wednesday, March 4th, 2020 at 5:02pm

Previously on this day

6 years ago I wrote Small steps

Making marginal gains in front-end performance.

9 years ago I wrote Brighton workshops

Seb and Remy will be dropping knowledge bombs.

14 years ago I wrote Speed

Everybody down.

15 years ago I wrote Vegas by Southwest

I have good cause to celebrate in Las Vegas and Austin.

15 years ago I wrote Siam I am

One week in Thailand.

20 years ago I wrote Lost in Favicons

In the spirit of practising what I preach when it comes to web standards, I’ve re-written Jessica’s professional site, Lost in Translation, in XHTML strict and CSS.

21 years ago I wrote Domesday Book outlives electronic version

The Domesday Book, commissioned by William The Conqueror, is 1016 years old. It is still readable today.