Network & egress — keeping a work's connections alive

Many born-digital works are not self-contained. They phone home: a net-art piece loads a page from its author’s server, a Flash animation pulls a playlist, a Director projector fetches text from a host that has been gone since 2012. When that host is dead, moved, or now serves something hostile, the work doesn’t just lose a feature — it can break outright, hang, or throw an error and stop.

So preserving a work often means preserving its reach: making the network behave, from inside the guest, the way it did when the work was made — and controlling that reach tightly, because a museum machine reaching the open internet is a liability, not a feature. This page explains the machinery that does both.

Start from containment: one isolated network per work

Every revived work runs on its own isolated network. Two works are never on the same wire, and by default a guest cannot reach the live internet, the museum LAN, or any other work at all.

This is a property of the topology, not a firewall rule bolted on afterward. Each project gets a private virtual network — its own bridge, its own subnet, its own gateway — defined with no route out. Traffic that tries to leave the bridge is rejected by the host. The only address a guest can talk to is its gateway, and everything a work is allowed to reach is something the gateway chooses to answer.

That gateway is also how the toolkit knows which work is speaking. Because each project owns a distinct subnet, the address a guest routed to identifies the project unambiguously — a guest cannot pretend to be another work by forging a packet. Egress, in other words, is closed by default and opened deliberately, one work at a time.

The isolated network and its gateway are automatic — you don’t configure them. What you decide is what the gateway serves: nothing, an archive, a live fallback, or a purpose-built backend. The rest of this page is about those choices.

Serving the dead web: archive replay

The most common need is simple to state: a work reaches hosts that no longer exist, and you want it to see what it saw originally instead of a dead connection or a squatted domain.

The toolkit answers this with a per-project web-archive proxy (internally “wbc”, the wayback-cache-proxy). Turn it on for a work and the gateway can serve the work’s HTTP requests from archived captures rather than the live web:

Archived captures (WARC files) you upload for the work are served back exactly as recorded. A companion replay engine indexes them and picks the capture nearest your chosen date.
A target date. You pin the moment the work should believe it is — say, the year it was exhibited — and the proxy prefers captures closest to that date.
A live fallback to the public Internet Archive, which you can leave on (fill gaps your WARCs don’t cover) or switch off (serve only what you have captured, so the work can never touch the live network).
Period-accurate throttling. The proxy can simulate a 14.4k modem through DSL, because for some works the pace of loading — the slow reveal of an image over a dial-up line — is part of what they are.

These resolve in a defined order: your uploaded captures first, then a hot cache, then the live archive last (if enabled). A work therefore sees your curated material in preference to anything fetched live.

Archive replay is off by default and a deliberate choice. It is the answer when a work’s original servers are simply gone and the web archive remembers them.

HTTPS, and why old machines need old certificates

A work that used https:// is harder: to serve an archived response for a secure request, the proxy has to terminate the TLS connection itself, which means the guest must trust the proxy’s certificate. The toolkit installs a per-project root certificate into the guest for this.

The honest complication is that ancient operating systems can’t validate modern certificates. A pre-service-pack Windows XP has no SHA-256 in its crypto stack at all. So the proxy mints certificates in an era-appropriate profile — an older signature for old guests, a modern one for recent ones — chosen from the guest’s OS and patch level. You mostly don’t touch this; it’s called out because “the work can’t reach an HTTPS host” on a period machine is usually this, not the network.

The doors: how a guest’s traffic actually gets caught

Knowing what to serve is only half of it. The other half is catching the guest’s outbound traffic in the first place — and works from different eras ask for the network in fundamentally different ways. The toolkit has a door for each.

The front door — a proxy the work is pointed at

The straightforward case: a work (or its browser) honours the system’s configured HTTP proxy. The toolkit points that proxy setting at the gateway, and every request arrives as a normal proxy request the gateway can route. Internet Explorer, well-behaved browsers, and most modern apps go through this door.

The side door — raw sockets that ignore the proxy

Period works frequently don’t honour any proxy. A Macromedia Director “net Xtra”, a Flash URLLoader, a Java applet, or hand-rolled Winsock code does its own DNS lookup and opens a raw TCP connection straight to an IP on port 80. It never consults the proxy setting, so pointing the proxy somewhere useful is invisible to it — the work sails past and hits the dead live web.

For these, the toolkit uses a transparent intercept. A host firewall rule catches that guest’s outbound port-80 traffic — whatever IP it resolved — and redirects it to a small listener on the gateway. The listener reads the primitive request the work sent, reconstructs the full URL from the Host: header the work included, and hands it to the same archive/routing machinery the front door uses. To the work, nothing changed: it opened a socket to a server and got a reply. It never learns that the server it reached was the gateway.

This is the difference between a work that can be told where the network is and one that can’t. The front door asks the work to cooperate; the side door requires no cooperation at all, which is exactly what a 2001 projector that has no proxy setting needs.

The problem behind the side door: names that no longer resolve

The transparent intercept can only catch a connection once the work has an IP to connect to. A work whose baked-in target is www.some-dead-host.example first has to resolve that name — and if the host is gone, its DNS lookup fails, the work never opens a socket, and there is nothing to intercept. It fails one step earlier than the firewall can reach.

The old fix was to hand-patch each work: find the dead hostname in the binary, replace it with a working address. That is fragile, per-work, and easy to get wrong.

The toolkit does it generically instead. The autopsy already recorded every host the work reaches as part of the analysis. The toolkit reads that list and, for each dead name, writes a DNS record on the project’s own resolver that points the name at the gateway. Now the work’s lookup succeeds, it connects to the gateway, the transparent intercept catches it, and the request flows into archive replay or a backend — with no edit to the work itself.

This is the core idea worth holding onto: redirect the name to a gateway you control, and let one generic mechanism handle every work. Hand-patching touches the artwork and has to be redone for every piece; redirecting the name touches nothing inside the work and applies uniformly. Preserving the original bytes of the work matters, so a fix that leaves them untouched is the right one.

When a work needs a live backend, not an archive

Some works don’t want a frozen page — they want a service. A piece might have talked to an API that returned changing data, or expected a server that did real computation. An archived snapshot of one response won’t revive that; the interaction was the point.

For these, the toolkit can run a backend plugin for the work: a small purpose-built service, written for that piece, that the gateway serves in-process. When the work calls its host, the plugin answers directly — with the right method, the right body, live logic — standing in for the server that’s gone.

This runs through a router that offers each request to an ordered ladder. The plugin gets first refusal: it can answer the request, or it can say “this path is mine but there’s nothing here” — a clean, honest 404 that stops the ladder rather than silently falling through to some archived or live content that would be wrong. Anything the plugin doesn’t claim falls through to archive replay and, if you allow it, the live fallback. A work can therefore have a bespoke backend for the handful of calls that need one and archive replay for everything else, in the same session.

Crucially, a work that only needs its plugin doesn’t need the archive stack at all — the gateway runs the plugin and nothing else, and an unclaimed request is a definitive miss, not a quiet substitution.

What’s automatic, and what’s your decision

The toolkit sets up the plumbing so you can focus on the judgements. Drawing the line explicitly:

Automatic, once a work is running:

The isolated per-work network and its gateway.
Pointing the guest’s proxy at the gateway (when the work honours a proxy).
The transparent intercept for raw-socket works, and the host firewall rules it needs.
DNS redirection of the work’s known dead hostnames to the gateway, read from the autopsy’s recorded network reach.
Era-appropriate certificate handling for HTTPS-terminating replay.

Your decision, per work:

Whether to enable archive replay at all, and which captures (WARC files) to provide.
The target date the work should believe it is.
Whether the live internet is reachable as a fallback — a real security choice, off by default in the strict sense that nothing leaves the gateway unless you say so.
Whether to simulate period bandwidth, and how slow.
Whether a work needs a backend plugin rather than a static archive — a piece of real work to write, reserved for pieces where the interaction, not the page, is the art.

None of this is guessing. The transport question — does this work honour a proxy, or does it open raw sockets? — is answered during the autopsy and carried across into the workbench, so the right door is opened without you diagnosing it by hand. What you bring is the curatorial judgement: how much reach a work should have, against what it saw when it was alive, and how tightly to close the rest.