The Modern Web on Ageing Hardware: What Still Runs and What Breaks

A legacy build running Mountain Lion or Yosemite is perfectly capable of rendering a web page. Whether the machine is a genuine 2011 Mac or a Clover-booted box with a patched DSDT makes no difference here: the browser stack ages the same way on both, and the processor is rarely what stops it.

What stops it is a certificate that expired, a cipher suite the browser never learned, a JavaScript feature that arrived after the last supported build, or a video codec with no hardware path. Each has a different prognosis — some are fixable in an afternoon, one of them is terminal. Sorting them is worth doing before writing off a build that boots reliably and does everything else well.

The certificate wall

The first failure most people hit looks like a network problem and is not. The browser reports that a connection is not private, and the site loads nowhere on that machine while working fine everywhere else.

Root certificates ship with the operating system, and they expire. The DST Root CA X3 expiry at the end of September 2021 took a large number of older systems off the modern web in a single day — in the UK it was visible as banking, retail and broadcaster sites failing simultaneously on machines that had worked the previous evening, because Let's Encrypt certificates chained to it and old trust stores had no replacement. Systems that never received an OS update after that point still carry the gap.

The fix is real but manual. The current root bundle is imported into the system keychain from the command line:

sudo security add-trusted-cert -d -r trustRoot 
  -k /Library/Keychains/System.keychain isrgrootx1.pem

Browsers that maintain their own trust store — Firefox does — sidestep the OS store entirely, which is why the same site can fail in Safari and load in Firefox on the same machine. That single choice restores a large fraction of the web on a system that otherwise appears broken.

TLS versions and cipher suites

Below the certificate layer sits protocol support. TLS 1.0 and 1.1 were deprecated across the major browsers in 2020, and servers now commonly require 1.2 as a minimum, with 1.3 preferred.

An OS-bundled browser that predates TLS 1.2 support cannot negotiate with those servers at all, and no configuration recovers it. The path forward is not the system browser but a maintained third-party build, which brings its own TLS stack rather than calling into the operating system.

This is also the reason a legacy machine reaches some HTTPS sites and not others. The difference is not the site's age but the server's minimum protocol version, and it takes one command to confirm which side failed:

openssl s_client -connect example.com:443 -tls1_2 </dev/null 2>&1 | head -20

A handshake that completes here and fails in the browser points at the browser's own TLS stack rather than the network. This is why the browser choice decides most of the outcome on a legacy build: a maintained third-party build carries its own TLS stack, certificate store and JavaScript engine, none of which depend on the ageing system underneath.

JavaScript: the moving target

Rendering has aged better than scripting. HTML and CSS degrade gracefully — an unsupported property is ignored and the page still reads. JavaScript does not: one unsupported syntax construct throws a parse error and the entire bundle fails to execute, leaving a blank container where an interface should be.

The dividing line is roughly ES2015 and everything above it. Sites increasingly ship modern syntax without transpiling, because their analytics show almost no traffic from older engines. The consequence is direct: the more a page depends on client-side rendering, the sooner it goes blank on legacy hardware, while server-rendered pages keep working for years longer.

Codecs and the CPU

Video is the one area where the hardware genuinely matters. A GPU from 2011 can decode H.264 without breaking a sweat and has no path at all for VP9 or AV1, so the decoding falls to the processor. UK broadcaster players compound this by requiring a current DRM module alongside the codec, and that module stopped shipping for older browser builds years ago.

The effect is measurable rather than theoretical. Software decoding of a 1080p VP9 stream saturates several cores of an older CPU, fans spin up, and dropped frames start well before the machine runs out of memory. On battery, runtime collapses.

Two mitigations work. Extensions that force H.264 delivery restore hardware decoding on sites that still offer that variant. Lowering the requested resolution reduces the decode cost more than any other single change, and on a display of that era the visual difference is small.

Kernel extensions and drivers: the part that never improves

Everything above concerns the browser. The layer beneath it ages differently, and on a legacy build it ages worse.

Wi-Fi is the usual example. A card that worked under Mountain Lion with a patched kext gets no updated driver, and the modern security requirements it never implemented — WPA3, and in some deployments 802.11w management frame protection — are not retrofittable. A router upgraded to WPA3-only takes the machine off the network without any warning that the cause is the driver rather than the password.

The same applies to Bluetooth stacks and to storage controllers behind unsupported chipsets: they do not degrade gradually, they stop the day something on the other side changes. The practical response is to keep the network side under your own control — a router in WPA2 compatibility mode, or a cheap USB adapter with a driver that still exists for that OS version.

Long sessions, live streams and sockets

Loading a page is the easy part. Staying connected for two hours is where a legacy build shows its limits, and three things break in that window.

Persistent connections come first. Anything that updates without a page reload — live scores, chat, a table that refreshes on its own — holds a WebSocket open. On an unstable Wi-Fi link, or through a kext that drops the interface when the machine idles, that socket closes and the page silently stops updating while still looking alive. Disabling sleep for the network interface removes most of it:

sudo pmset -a tcpkeepalive 1 womp 1

Session expiry comes second. A dropped socket often means a re-authentication on the next action, and on an old build that lands as an unexpected login screen mid-session rather than as an error. Services operating under UK rules tend to time sessions out faster than the average site, which makes the effect more noticeable here than elsewhere.

Live video is third, and it compounds both. A streamed table or a match feed decodes continuously rather than in bursts, so the software-decoding cost described above is paid for the whole session, not for a two-minute clip. On a 2011-class GPU that is the difference between a page that works and a machine that thermally throttles into unusability after twenty minutes.

The practical order: fix the network layer first, then the codec, then judge whether the service itself is viable on that hardware.

Money and identity in an old browser

Payment pages fail before anything else on a legacy build, and in the UK there is a specific reason for it.

Strong Customer Authentication became mandatory for UK e-commerce on 14 March 2022, which means a card payment now routes through a 3-D Secure challenge hosted by the issuing bank. That challenge is a separate page, loaded in an iframe, built with current JavaScript and served under the bank's own TLS policy. Every failure mode described above applies to it at once, and the visible symptom is a blank frame or a spinner that never resolves — with the payment already authorised on the card and hanging unconfirmed.

Two related breakages sit alongside it. Third-party cookie restrictions, configured years ago when the advice was to block everything, cut the channel the 3-D Secure frame uses to report success back to the merchant. And identity checks asking for a document upload rely on File and camera APIs that a build from that era either lacks or gates behind permissions it never learned to grant.

The practical rule on a legacy machine in the UK: keep browsing, reading and streaming on the old build, and do the payment step on a supported device.

Accounts on an unsupported OS

An operating system past its support window stops receiving security patches, and that changes what should and should not be done from it.

A browser vulnerability patched upstream stays open on a build that no longer receives updates, and password managers drop support for old OS versions long before browsers do, so the machine ends up either without a manager or running an outdated one.

Three habits cover most of it. Two-factor authentication lives on a phone rather than the desktop, so a compromised browser session cannot complete a login by itself. Sessions are ended explicitly instead of left open. And accounts holding money or verified identity documents are not opened from that machine at all — the rule that applies to a public computer applies here for the same reason.

None of this makes the old build unusable. It defines what it is for: reading, streaming, development, testing — everything that does not authenticate against money.

Which classes of service survive

Not all sites fail equally, and the pattern is predictable once the layers above are understood.

Server-rendered pages, forms and documentation survive nearly everything. Applications that render entirely on the client fail first. Anything requiring a native helper — a desktop client, a signed installer, a system extension — fails immediately and permanently, because minimum OS versions are enforced at install time and cannot be argued with.

Services that keep everything in the browser outlive those requiring a native client by years. As a seven casino review notes, the platform runs slots, live dealer tables and the sportsbook at one address on desktop and mobile, with the account and session carried across both and nothing to install on either. On ageing hardware that architecture matters more than it sounds: the failure modes reduce to a certificate, a codec or a dropped socket, all of which are solvable, rather than an unsupported OS version at install time, which is not.

The same test applies to any service chosen for a machine that will not be upgraded again. The question is not how heavy the interface looks, but whether anything has to be installed, and whether the session survives a network hiccup without losing state.

What is worth doing, in order

For a machine that has to stay on the modern web:

1. Import a current root certificate bundle into the system keychain.
2. Install a maintained third-party browser and stop using the system one.
3. Force H.264 where video is involved, and cap the resolution.
4. Prefer server-rendered versions of services where both exist.
5. Add memory before considering anything else — old browsers on modern sites are memory-bound long before they are CPU-bound.

None of this makes an unsupported OS supported. It keeps a working machine useful for several more years, which is usually the actual goal.