Tag: digital-extinction-what-the-internet-forgot

Posted on by

DRM-protected downloads after authorization servers disappear

Downloaded does not mean openable. With digital rights management, a file on your hard drive is a locked container, and the key lives elsewhere, on a server run by whoever sold you the file. The seller’s computer checks that you are a customer and your device is authorized, then hands the player a license. Skip that step and even a file you paid for refuses to open. The download is real; the permission is rented.

Files that wait for permission

The mechanics explain it. The track or book is scrambled with a key that lives in a license, issued per device and per account. On the machine where you first opened the file, the player finds the key it already holds and plays it fine. On a new computer, or after a reinstall, the player must call the authorization server and ask again. That request is the whole arrangement. If the server is gone, no answer comes back, and the freshly copied file stays silent.

When the key server goes dark

In July 2008 Yahoo emailed Music Store customers: the store was closing, and with it, on September 30, the servers that retrieved license keys for songs bought through Yahoo! Music Unlimited. Each track was wrapped in DRM and needed a license before a computer would play it. Yahoo’s email, reproduced by Wired, spelled out the terms. Songs would generally keep playing on computers that already held licenses, as long as the operating system did not change. After the cutoff, you could not transfer tracks to a new machine or re-license them after a reinstall. The official advice: back up by burning the tracks to audio CD.

Nothing was destroyed. Files sat on drives, intact; what died was the tie between file and permission. Authorized machines kept playing for years, so the loss was conditional, striking when you moved to new hardware. Yahoo later offered affected customers replacement options or refunds. The broader lesson was not unique to Yahoo: several early digital-media stores discovered that closing a DRM service also meant deciding what happened to files customers had already paid for.

Recovery, and what preservation needs

Recovery costs more than the purchase did. Burning to a CD and ripping it back forces the songs through your sound system, losing quality and eating discs. Coupons re-bought the songs from a different store, in a different format. Refunds returned the money, not the music. The decryption key left with the server, so the original files stay locked at full quality.

The pattern has not aged out. When Microsoft closed its ebook store in 2019, it also shut down the DRM infrastructure required to read those books. Microsoft staff confirmed that customers would receive refunds, and contemporary coverage documented that the purchased ebooks themselves would stop being readable. A refund returned the money; it did not turn the locked file into an independently usable book.

The practical lesson runs against instinct: a copy of the file is not a backup. A DRM download stays usable only with the ecosystem around it — a server that keeps answering, an honest license, a store that replaces or unlocks content when it closes. Open formats like plain MP3 and untethered EPUB need no permission, which is why preservation keeps reaching for them. The download whose future you control is the one that opens without calling home.

Posted on by

Online art dependent on external services that no longer respond

Some internet art is a file you can save to a hard drive and open again later. Other works are machines that only run while connected to a service, and their meaning lives in that wiring, not in pixels. The second kind has a preservation problem that page-savers cannot solve, because part of the artwork sits on someone else’s servers, running under someone else’s rules. Google Will Eat Itself is a documented example.

A cannibalistic economic engine

In 2005 UBERMORGEN, Alessandro Ludovico, and Paolo Cirio released a work built around Google’s advertising infrastructure. The project site describes a network of hidden websites serving Google ads and using the resulting revenue to buy Google shares. In the artists’ own account of the mechanism, automated activity generated the clicks that produced those payments. The shares were to be handed to GTTP Ltd., a company set up for the work, which would distribute them back to the public. Google, paying for its own undoing, would eat itself.

What mattered here was not an image or a text but an arrangement through which real money moved across Google’s advertising system: ads served, clicks counted, payments accumulated, stock purchased. Rhizome’s archival description of GWEI preserves the work as a conceptual intervention into Google’s click-based advertising economy. That was the artwork. The dependence was the point — the engine only ran while Google’s program kept answering.

When the service stops answering

Google eventually disabled the accounts and challenged the project, ending the live economic mechanism. The surviving pages document that conflict, but the important preservation fact is simpler: once the external ad service stopped participating, the artwork could no longer perform the operation it had been built around.

What survives is the wrapper around the machine. The project site still serves the concept and documentation, while Paolo Cirio’s archive preserves project material and credits. What is gone is the live relationship with Google’s advertising infrastructure. What is gone is the engine itself: no ads, no clicks, no revenue, no share purchases. The pages can describe the mechanism but cannot run it.

That is the preservation lesson. Archiving a website preserves the documentation of a dependency, not the dependency. A static copy can show visitors what GWEI claimed to do; it cannot show the artwork happening, because half of it was an external service that no longer responds. The record of the performance stays complete while the performance itself stays out of reach, and GWEI’s meaning has quietly shifted from a running machine to a surviving account of one — more than most such works get, but less than the artists built.

Posted on by

Web games whose essential server code was never preserved

Most browser games were two pieces of software wearing one name. The client was the Flash, HTML, or Java the browser ran: the menus, the sprites, the load screens. The server was what the client talked to, and it owned the things that mattered: your account, your progress, other players. When a game closed, archives usually captured the client and let the server slip away. Club Penguin is the documented case of that asymmetry.

Disney shut down the original Club Penguin on March 29, 2017 as it moved users toward Club Penguin Island; contemporary coverage made clear that the replacement was a separate product and that old items and memberships would not transfer. The Flash client files survived in many places. Disney did not release the original game-server source code publicly. The parts that made it a game — accounts, igloos, coins, moderated chat — remained software nobody could run. The client was saved. The game was not.

Where a browser game actually lives

A game server does the remembering and the comparing: save files, inventories, coin balances, scores, queues, daily-reset events. It also does the judging. The official outcome of a battle, the rare item a loot roll produced — those are decided server-side, because a server is as much referee as host. The client is the interface plus a set of politely phrased requests.

Club Penguin leaned on this harder than most. The browser loaded a Flash world, but who you were, what you owned, and whether your chat cleared the filter all lived elsewhere — on Disney’s machines.

The client is not the game

Files alone do not bring a browser game back, because the client is built to ask someone something. Flashpoint’s technical documentation explains how its local proxy and web server recreate the URLs and responses that many archived web games expect. That works well for static dependencies. It cannot magically reproduce application logic that originally lived only on a remote multiplayer or account server.

Point a saved Club Penguin client at its old address and you get a login screen going nowhere. The screen survived; what answered it did not.

Rebuilding the missing half

Because the server was never preserved, running the game again meant constructing a replacement. Fan projects worked from the client end: decompile the Flash, learn what the game asks a server to confirm, then write software that gives the right answers.

Fan projects therefore rebuilt the missing half from the client side. The archived Club Penguin Protocol project documents the reverse-engineered packet formats and control flow used between client and server. That kind of work can recreate enough behavior for a private server to function, but it reconstructs the protocol rather than recovering Disney’s original server implementation.

Rebuilt is the honest word for it. Emulation reproduces how the world behaved, not the code that made it behave that way. Where fans had observed the server’s responses, recreation is close; where they had not, it is a guess wearing the game’s costume. The original is gone either way.

The limits of recovery

Reconstruction also cannot bring back what only the original servers held. Every fan server starts players at zero, because accounts, igloos, and friends lived in Disney’s databases and left with them. The world could be rebuilt; the population could not be restored.

Reconstruction has another limit: it recreates behavior that fans observed, not the hidden business rules, databases, moderation systems, or account state that were never exposed by the client. Preserved source code would remove much of that guesswork. Without it, the rebuilt server is an informed approximation.

The same outcome repeats across the web-game era: the client is kept, the server is reconstructed from memory and inference, and the reconstruction ends when the volunteers or the tolerance do. Browser games were services, and a service is the hardest thing to archive. The saved client is a souvenir. The game was the part nobody preserved.

Posted on by

Mobile apps that cannot be reinstalled after delisting

Flappy Bird left the App Store and Google Play in February 2014, pulled by the developer who designed it and then watched it climb to the top of both download charts. It had been downloaded more than 50 million times. New players could no longer get it, and as the LA Times reported, phones with the game preinstalled were briefly listed on eBay, one reaching a bid of nearly $100,000 before the auction was pulled. The game was not destroyed. The stores just stopped handing it out, which for most people was the same thing.

Why a working copy stops being enough

A delisted app lives on a device, but it reaches new devices through a store, and the store is the first point of failure. For years, a previously purchased iOS app stayed downloadable from the Purchased tab even after it vanished from search. That was policy, though, not physics, and policies get revised.

They were revised on a large scale with iOS 11. Apple’s 64-bit transition notice was precise: support for 32-bit apps was gone, and 32-bit apps already installed on an upgraded device would not launch. That is a compatibility failure rather than a simple delisting failure, but for preservation the result is similar: keeping the binary is not enough if the current operating system refuses to execute it. A working old app may require a compatible old device and operating system.

Android reaches a similar place by different routes. Android 14 blocks ordinary installation of apps targeting below API 23, and Android 15 raises that floor to API 24; Google’s Android 15 behavior documentation records the change and notes that already-installed older apps remain after an upgrade. Google Play has a separate distribution policy: as of August 31, 2026, stale apps that do not meet the current target-API requirement become unavailable to new users on newer Android versions. The store and the operating system therefore impose two different kinds of aging.

And none of that touches the backend. A delisted app that needs a login, a feed, or a marketplace is a corpse in a chair even when it installs cleanly. Plenty of apps survived delisting only to die when a company shut down its servers or let its certificates expire.

What preservation actually keeps

The two platforms recover differently. Android packages can often be preserved and installed on compatible systems outside Google Play, although newer Android versions increasingly block very old targets by default. On iOS, Apple still provides a purchase-history redownload path, but redownload does not solve incompatibility and it depends on Apple continuing to serve a compatible copy. A preserved binary, a compatible operating system, and any required backend all matter separately.

A preserved copy is therefore evidence more than it is a working program. Archives hold the binary, the screenshots, the documentation, and the review threads — a fair record of what the app was and who used it. Getting it running again requires a compatible-enough operating system, an acceptable signature, and sometimes a live server that no longer exists.

A previous download was never an archive. Delisting removes the reinstall, update, and trust channels along with the store page, so the software does not die so much as become unreachable — and unreachable is how most software now goes extinct. If you have an app you care about, keep the file, keep the version that matches your device, and assume the store will not be holding it for you.

Posted on by

Browser extensions removed from official distribution catalogs

On August 31, 2026, Google removed the remaining Manifest V2 extensions from the Chrome Web Store, including uBlock Origin. Google’s own Manifest V2 timeline now records that date as the final store removal. The code had never left GitHub. What the catalog took away was the normal Chrome distribution path around the code.

A listing is more than a download button

A catalog entry is where a tool is discovered and trusted. It carries the package, automatic updates, install counts, ratings, reviews, screenshots, permission disclosures, and a stable installation path. Remove it and new users lose the normal route to the software. In this case the runtime changed too: Chrome disabled Manifest V2 everywhere with Chrome 138, and the enterprise escape hatch disappeared with Chrome 139. A preserved store package therefore does not restore normal operation in current Chrome.

Why uBlock Origin left

uBlock Origin did not disappear because its source vanished. It became incompatible with Chrome’s extension platform transition from Manifest V2 to Manifest V3. The current uBlock Origin repository explicitly notes that its Chrome Web Store listing was removed on August 31, 2026 while the full extension remains available for Firefox. A different project, uBlock Origin Lite, targets Manifest V3 with a reduced architecture suited to Chrome’s newer rules.

A precedent, not a novelty

None of this is new. Firefox 57 removed support for legacy XUL extensions, leaving preserved add-on files dependent on old Firefox versions or ports to the newer WebExtensions system. Catalog removal and runtime incompatibility are related problems, but they are not the same problem.

The parts that survive separately

An extension is at least three things: source code, a packaged artifact, and documentation. uBlock Origin’s source lives on GitHub, installable releases ship alongside it, and its wiki and filter lists live in their own repositories. None of it sat in the store. What the catalog controlled was the review history, the user base, the update channel, and a single trusted URL.

A preserved copy isn’t a working install

Holding a .crx or .xpi file is not having a working extension. The browser is the gatekeeper: current Chrome rejects MV2 outright, so even a faithfully archived copy is inert there; Firefox and older Chromium are what still run it. The extension also expects an update server and, on Firefox, a signed package — a sideloaded copy loses both. And uBlock Origin refreshes its block lists from several third-party hosts on a schedule, so an offline copy eventually blocks only whatever lists were last cached. For software whose whole job is to stop untrusted content, an unverified preserved copy also means trusting whoever packaged it — the kind of decision that deserves source you can inspect.

That is the real loss when an extension leaves its catalog: not the code, which survives wherever its project publishes it, but the context that made it discoverable, updatable, and trustworthy. A store listing was never a backup.

Posted on by

RealAudio and RealVideo collections tied to obsolete playback systems

When Progressive Networks shipped RealAudio 1.0 in April 1995, it gave the web its first practical way to hear sound without downloading a whole file first. RealVideo followed two years later. Radio stations, news desks, and hobbyists built collections around the pair. Those collections are still out there. What is increasingly difficult is opening them.

How early streaming collections were delivered

Sites rarely uploaded audio for visitors to grab. A page usually carried a .ram or .rm link — a metafile, often plain text containing a stream URL. Click it and RealPlayer started, connected, and played the sound live — or as a “pseudo-stream” that could be saved. Some sites never had the sound on a hard disk at all; the link pointed at an encoder that only existed while the server ran.

The Library of Congress sees the result in its web archive of U.S. government audio. Audio formatted as RealMedia made up about a fifth of the captured files, yet a large share of those were metafiles: extensions and media types that promised sound but held only links to streams or other files. The bits for the audio itself were never in the crawls.

Codecs, players, and missing files

RealMedia playback leaned on RealPlayer, and the formats accumulated multiple codec generations. The Library of Congress describes both RealAudio and RealVideo as proprietary formats with limited public documentation. Modern tools such as FFmpeg and VLC can decode many surviving files, but compatibility varies with codec and file generation.

Whole catalogs also aged out of service. The BBC finally dropped RealMedia in 2009, with BBC World Service holding on until March 2011, leaving years of programs trapped in the format. When a .ram host goes dark, what dies is a folder full of URLs to nothing.

What conversion and emulation can preserve

The rescue path is conversion, not a time-traveling player. In 2009 the Internet Archive’s audio team announced it could finally turn .ra and .rm uploads into playable derivatives, using ffmpeg. Curators today can do the same locally: decode to FLAC or MP3 with ffmpeg or a tool such as VLC. Old RealPlayer installs on emulated Windows boxes work for a handful of files, but they scale badly and still choke on the closed codecs.

The limits stay honest. Streams that were never recorded are simply gone. Some codecs lack working open-source decoders. And the audio was typically low-bitrate mono squeezed for dial-up, so even a flawless conversion preserves a scratchy original. Files with their data intact can be moved to neutral formats; ones that were only metafiles cannot. The tie to obsolete playback is the fragile part — which is exactly why the files, not the players, are what deserve saving.

Posted on by

VRML worlds separated from their original viewing software

A saved VRML world is usually missing most of itself. The .wrl file, the plain-text heart of a 1990s virtual reality scene, survives in archives by the thousand, but it rarely arrived alone. The geometry it contains is real; everything that made it recognizable as a place was fetched from somewhere else.

The world shipped in pieces

A VRML scene listed its outside links in plain sight. Textures came through ImageTexture (Texture2 in the 1.0 days), sounds through AudioClip, and whole sub-scenes through Inline nodes — URLs the viewer hit at load time. The Library of Congress’s format description for the VRML family notes it was meant for a “distributed web environment,” hyperlinking out by design. The Castle example that floated through 1990s tutorials, built by Mike McCue at Paper Software, shipped castle.wrl with GIF textures and inlined pieces; a surviving copy kept at TECFA records that the original has since “disappeared from the Web.”

A VRML viewer therefore may need to retrieve an entire bundle of referenced resources before the scene looks complete. A lone .wrl can be a stage with its props absent.

The viewer was part of the appearance

Which plugin you had also set what you saw. Netscape’s Live3D read VRML 1.0 and added proprietary extensions such as animated textures, while SGI’s Cosmo Player pushed the newer 2.0/97 spec; worlds tuned for one ran fully only in it. Even ordinary files were hostage to interpretation. Relative links, plugin-specific behavior, and vendor extensions could change what appeared when the same world was opened in a different viewer.

Recovering an intelligible version

Recovery means reassembling the package and matching it to software. An open-source viewer such as FreeWRL, Xj3D, or view3dscene reads the plain-text geometry without complaint, but it can only fetch files that still exist. Textures stored beside the .wrl come back if they were gathered too; an Inline world renders as nothing when its URL has gone dark.

The limits of recovery

Even a complete file set hits viewer differences. NIST’s Digital Library of Mathematical Functions, which still offers VRML/X3D behind a WebGL display, reports that some browsers “are not capable of handling the complex files necessary for our visualizations” and that it found no viewer working consistently on Linux — which is why its modern default is WebGL instead.

What survives, what is gone

Geometry is the survivor: vertices, faces, and materials remain readable ASCII. Appearance and behavior are the casualties. A recovered world without its textures is gray shapes; without its plugin-era extensions, animation, sensors, and scripted touches are lost regardless of whether the code survived. The DLMF could move on; the old worlds have no successor runtime waiting for them. Only the pieces someone thought to keep still render.

Posted on by

Shockwave projects and their preservation obstacles

Shockwave rarely gets the memorial Flash does, and the preservation gap explains why. When Flash died, Ruffle was already reviving animations in the browser; Shockwave never got an equal. Its player was a closed binary, its files packed by a now-dead authoring tool, and for years the practical runtime was a patched Windows projector. So its works survive mostly as files that cannot always be finished.

The Director runtime in the browser

Shockwave was Macromedia Director’s browser playback system. Director was a major multimedia authoring tool of the CD-ROM era, and its compacted .dcr movies later became web-deliverable through the Shockwave plugin. Flashpoint’s history of Shockwave 3D documents how Director evolved into a browser-game platform. Educational tours, animated intros, and virtual exhibits leaned on it; Macromedia’s shockwave.com, launched in 1999, hosted hundreds of original browser games including some with real 3D.

A file is only part of the work

Saving a Shockwave project means keeping more than one .dcr. Director movies reach outward, loading external casts, sounds, and the .w3d 3D worlds that Shockwave 3D fetched at runtime, plus Xtras, the compiled add-ons shipped with content. The application/x-director type alone spans casts, Xtras, and more. The runtime had to match the author’s version too; Adobe’s last Shockwave releases dropped .dir playback, leaving only the compacted web format.

Flashpoint carried most of the burden, building SPR projectors, patched standalone players remade from each Director version so a game believes it sits in its original environment. It works, Windows-only and game by game; the team has configured more than a thousand Shockwave games.

What survived, and its limits

Adobe retired Director on February 1, 2017, discontinued Shockwave for macOS a month later, and ended the Windows Shockwave Player on April 9, 2019. The shockwave.com library went dark before any preservation plan existed. The Internet Archive captured many .dcr files, but pages that detected the plugin sometimes refused to serve the movie at all.

Even intact file sets hit walls. Orbit Spherez, a marble platformer from Candystand, still runs in Flashpoint, but the Shockwave 3D world files for levels 4 through 6 were never recovered, and it crashes on a missing level. Nobody can finish it. Modern Flash emulation does not solve the Director problem, and newer Director-compatible players are still reverse-engineering an old proprietary runtime. Anything the work needed beyond the files—from a leaderboard to a service hosted on the original website—never lived in the .dcr at all.

Posted on by

Java applets and the loss of browser-based demonstrations

For about fifteen years, “interactive” in a browser usually meant a Java applet. Teachers who wanted to show how a circuit behaved or how gas molecules bounce could point a class at a web page and watch the physics run in place, no installation, no downloads. Few sites demonstrated the appeal better than PhET, and its history shows what happens when the runtime underneath that experience disappears.

What applets did for the classroom

Carl Wieman launched the Physics Education Technology project, PhET, at the University of Colorado Boulder in 2002 with part of his Nobel Prize money, having learned that audiences remembered the working simulations in his talks especially well. CU Boulder described the project at launch. Many early simulations used Java or Flash because those runtimes let one interactive demonstration reach multiple desktop platforms through a browser. Students could pump gas into an Ideal Gas tank, drag wires into a circuit, and get immediate feedback — everything the design papers of the time promised educational software would be.

The trick was that the experience depended on the browser, not the file. An applet was compiled code that a plugin executed inside the page. That was convenient for viewers and fragile for everyone else.

What survived, and what didn’t

Over a decade, browsers slowly stopped trusting the plugin machinery. Chrome disabled the plugin system applets ran on, Firefox followed, and Apple stopped shipping and supporting Java in its browsers. For PhET, the shift to Chromebooks and iPads in classrooms made the Java simulations unreachable for exactly the students they were built for. The project responded by rebuilding much of its catalog in HTML5 and by keeping other simulations available through alternative runtimes and downloads. The Java files themselves never vanished — PhET’s code was open, and the jars could still be opened as desktop applications. What stopped was the one-click experience.

In 2022 PhET partnered with Leaning Technologies to run dozens of legacy Java simulations in the browser again using CheerpJ. The original Java programs were not individually rewritten into HTML; another compatibility layer was inserted between them and the modern browser. PhET’s current help documentation still notes device and feature limitations for older simulations.

The judgment: nothing about the physics was lost. The jars existed, the code was conceived, and reconstructing them was possible because someone kept the artifacts. The loss was the environment — the assumption that a demonstration mentioned on a page would run when you opened it. PhET could afford reconstruction because it is an institution with source control. Thousands of smaller applet pages, dead and unmaintained, are preserved nowhere.

Applets proved that browsers could genuinely teach. What their removal proved is that a web full of interactive demonstrations only outlives its runtime when the people who built them bother to keep the parts.

Posted on by

Flash works that survive as files but no longer run in browsers

Keeping a Flash work was two jobs: saving the .swf file, and saving a way to run it. Most people did the first and skipped the second; the browser brought the player along. That stopped being true as 2020 turned into 2021, and thousands of saved files suddenly had no runtime to call home.

A file without a runtime

A .swf is not a self-contained movie. It is shapes, timelines, audio, and ActionScript written for Adobe Flash Player, and without that player it is inert. An MP4 plays in whatever you have; a .swf plays almost nowhere. Adobe stopped supporting Flash Player on December 31, 2020 and began blocking Flash content from running in the player in January 2021. Browser support had already been shrinking for years.

Browsers removed the player

The removals were staggered across browsers and operating systems, which is how the file-versus-player confusion set in. By early 2021, the major browsers had removed Flash playback. A modern browser will not run a .swf simply because the file still exists. The file survived fine. The thing that interpreted it disappeared from the normal browsing environment.

Files outlived their players

Homestar Runner is the cleanest documented case. The animated site ran on Flash for two decades, and when the plug-in died the .swf files went nowhere: the old Flash version stayed online at old.homestarrunner.com, while the main site was rebuilt around the Ruffle emulator. Its post-Flash update page is honest about the seams. The cartoons and many games play again, but games made after about 2007 “will probably be pretty janky,” and toons built on embedded video just show a blank box. The files lived on. The runtime they were written for had left the browser.

Emulation recovers most, not everything

Recovery works because emulation replaces the missing runtime. Ruffle, a Flash emulator written in Rust and compiled to WebAssembly, mimics enough of Flash’s behavior that the Internet Archive began playing archived Flash items in the browser with it in 2020. Flashpoint uses additional preservation techniques and standalone projectors for works that need more than a simple browser emulator. Both approaches hit the same hard limit: anything a work expected from a live server, an external file, or a multiplayer backend must be preserved separately or reconstructed.

Save more than the file: the .swf, the .fla if it exists, the author, the original site, and whether the work reached beyond itself. Files are easier to keep than works. A .swf that outlives Flash Player is a relic that proves something existed — not a guarantee that it can be watched. Keep a runtime or an emulator, and plenty of it can be.