The block

When unsupported becomes unrunnable

Deprecation is a soft word. It implies drift, a slow fade, a technology gently stepping aside. What happened to Flash on 31 December 2020 was not that. Adobe did not simply stop shipping patches — it built a kill switch into the final version of the runtime and, from 12 January 2021, the Player itself began refusing to run content. Every copy of the final versions of the plugin checked an internal date flag and declined to execute. Unsupported software usually still works; blocked software does not. That distinction matters enormously to anyone trying to run something built for Flash after the fact.

The mechanism was not hidden. Adobe had announced the block in its own end-of-life documentation, framing it as a security measure. The argument was coherent: Flash had accumulated serious vulnerabilities over its lifespan, and an actively running, internet-connected plugin was a genuine attack surface. Pulling the trigger centrally was tidier than waiting for users to uninstall. Microsoft went further, pushing a Windows Update that removed the plugin from the operating system entirely. A user who had never touched their settings woke up in January 2021 to find the runtime gone.

Why a backup copy was not enough

The preservation problem this created is structurally different from ordinary bit rot. Bit rot is passive — the bits decay, the medium fails, the format becomes unreadable because nothing can parse it. The block is active: the bits are fine, the format is readable, the runtime itself simply refuses. A perfectly preserved .swf file and a perfectly preserved copy of the last Flash Player installer will, if allowed to run together, still produce a refusal. The Player checks its own build date against a hardcoded threshold and exits before rendering a single frame.

Getting around this requires either running a pre-block version of the Player — one old enough that the kill switch was not yet present — or replacing the Player entirely with something that does not contain the block. The first approach is fragile. Older plugin versions carry unpatched vulnerabilities that make them unsafe to run in a connected browser. The second approach is the one the Ruffle project took: write an emulator, in Rust compiled to WebAssembly, that reimplements the runtime from scratch and contains no kill switch because it never contained one in the first place.

It implies drift, a slow fade, a technology gently stepping aside.

Flashpoint, the archival project run by BlueMaxima and a large volunteer team, solved the same problem differently. It ships the games alongside a controlled environment — a local proxy, a managed browser, and selected old Player binaries — rather than expecting a modern browser to handle them. The archive carries the runtime it needs with it, insulated from whatever the operating system or browser considers current policy.

The block as a precedent

The kill switch was not unique to Flash. Apple had used code-signing and certificate revocation to render applications unrunnable before, and the pattern appears in mobile storefronts whenever a developer's account lapses. What made the Flash block notable was its scale: a single activation point reaching into hundreds of millions of installs simultaneously, across every platform Adobe could touch. For a game that had run in every browser for fifteen years, the transition from widely playable to actively refused was measured in days.

The Internet Archive responded by serving Flash content through an in-page Ruffle instance, sidestepping the plugin layer entirely. That approach preserved access at the cost of compatibility: Ruffle's ActionScript 3 support was incomplete at launch, so games using later Flash features rendered incorrectly or not at all. The block forced the choice between imperfect emulation and no access, and imperfect emulation won. That is still the state of play.