Advent of Computing - Episode 167 - The Tape That Unwound Itself

Episode Date: October 12, 2025

Have you ever had a computer do something you can't explain? Have you ever thought a machine had a mind of its own? In 1971 Met Life was faced with this exact conundrum. Their tape drives, for some reason, were throwing tape all over the floor every night. Systems were checked and no flaws were found, but every morning an operator would walk in on an absolute mess. What could make a healthy machine spit up it's precious tape?  

It started just like any other day at the White Plains, New York branch of the Metropolitan Life Insurance Company. The first trickle of desk jockeys made their way in off the street and into the office. Doors unlocked, lights came on, coffee brewed away in some nearby pot. Everything seemed routine. That is, until someone went to check the office's new computer. The morning, just barely unwinding, was interrupted by the sounds of cursing. Somehow, the computer had spit up its tape. The machine was supposed to be automated, sending back data to MetLife's mainframe.

But overnight, something went haywire, the thing went berserk, and threw tape all over the floor. Frustrating, to be sure, but you know how computer. are. They can be capricious and downright upsetting at the best of times. Maybe it was a fluke. Maybe the curses have brought it back into line. So the operator dutifully respooled the tape and set the machine back to working. The rest of the day went on like normal with no more strange interruptions. But then the next morning came, and the routine was again irregular. Tape was sitting unspooled around the computer. There must have been something just plain wrong with the thing.

Now, MetLife isn't exactly a digital outfit. I mean, they had computers, but they didn't make them. Honeywell made their machines, and they even had a support contract with them. So Honeywell was called in to figure out what went haywire. That's when something concerning came to light. But here's the thing. When the White Plains office called Honeywell, they expected to be met with at least a little surprise. I mean, whoever heard of a computer spitting up its tape if left alone overnight.

But the Honeywell technician just sighed. Turns out the same problem have been cropping up at other MetLife offices. White Plains wasn't special. There is something deeply wrong. Boo. Did I surprise you? Welcome to Spook Month here on Advent of Computing. I'm your host, Sean Hasse, and this is episode 167, the tape that unspooled itself. Perhaps you weren't expecting an episode this week, but as long-time listeners, no, I'm not the best at planning,

and my plans, as provisional as they always are, tend to change a little bit. so I decide to shake things up. This is the first episode of my spooky coverage for the month of October. If you're new here, then let me explain the tradition. Each October, I do my best to dredge up computer ghost stories. It ends up being kind of a parade of the frustrating, confounding, and inexplicable. Last year, I ran this month as a series of weekly short episodes, which was a whole lot of fun to produce. the shorter episodes I don't have to go as deep into the research,

and it also means I can cover smaller topics that might not fit into a whole episode. So, as I was sitting down and starting to plan out Spook Month this year, I decided I wanted to do that. So I'm doing the same thing this year. You're going to get three spooky episodes back to back that are a little shorter than usual. Today, we're going to be discussing a particularly

strange chapter from the early days of hacking. That is, the MetLife weather reporting incident. This story came to my attention via the wonderful book Computer Insecurity. If you don't have a copy and hacking or computer incidents or computer law at all interests you, highly suggest tracking one down. The book is essentially an index of computer incidents that occur prior to 1983. It's a fabulous way to get leads, but enough about the sourcing. Let's talk about this specific incident. The short story is that someone figured out how to take down MetLife's weather service by telling all of their office computers to advance their tapes a little too far. The miscreants responsible? Why? A trio of Honeywell employees that were on strike.

How did they plan this caper? How did they find this grand? vulnerability? In this episode, we'll be looking at how bad security and poor system design can lead to some wacky antics. Best of all, despite some arrests and some confusing data sets, nothing serious would come of the incident. So we truly have a case of wacky antics where people might be a little upset, but no one gets hurt, nothing gets stolen. So let's just have a good time with this, shall we? The weather service incident occurred in 1971, but things started brewing a little earlier. In 1967, the Metropolitan Life Insurance Company entered a new era of automation.

That year, they started installing Honeywell computers in their field offices and networking those machines back to their main office in New York. Now, just to be up front about this, I'm pretty sure they were putting small computers in their field offices, it could have also just been a very sophisticated data processing unit. The details here are a little sparse, mainly because all the information for this is coming from newspaper articles, which are not resoundingly technical. I'm going to be working under the assumption that they had computers in their office. If it turns out they weren't fully-fledged computers that doesn't actually change the story. That just changes this one detail. The important

point is that Honeywell was setting up a data network. And 1967 is pretty early as far as networking goes. However, this isn't exactly networking as we use it these days. Honeywell, who built the entire thing, was making use of existing infrastructure. Specifically, they used AT&T's wonderful telephone network. Each branch office had its own phone number, and the main office had a number. Computers communicated by dialing those numbers and patching through switchboards. The method is simple, but effective. Phone lines had been in use for simple automation since at least the 1920s. If you want more details, I actually ran into this a few years ago when discussing Westinghouse's Electro, the marvelous smoking robot.

The connection is there, I swear. The wonderful smoking robot was actually the result of research into electronic control over phone lines. What Honeywell built for MetLife was just the latest in a long series of phone-based automation. The system worked in a daytime and a nighttime mode. During business hours, at daytime, MetLife employees would hammer away at their terminals. This would fill out forms, collect data, and file away requests. then after business hours, the local computer would switch into an automated mode. The central mainframe could then dial up machines and collect the day's data.

This is a pretty interesting setup that gets around some issues with early networking. According to a 1967 article in the Carroll Daily Times Herald, there were limitations on how many calls the central mainframe could make at any one time. Supposedly, that was capped at 60. probably imposed by the switchboard, or maybe how AT&T ran lines into MetLife's central office. MetLife had some 500 field offices at the time, so you couldn't have constant connections with all of those offices. There's also the matter of data transfer speeds. A whole day's worth of data from an office could be daunting. But the day is only eight hours long, and a computer can run 24-7 with

ease. Besides, machines don't accept overtime pay. So, with some smart automation, MetLife and Honeywell wouldn't even really need to worry about transfer speed. MetLife's mainframe had 16 whole hours to talk to each field office and collect data. That would have been plenty of time. This new network proved very, very useful for daily operations. It also opened up new opportunities. This is kind of a common pattern. A non-computer company goes digital. They realize that they have more computing power than they need for normal operations. So they start looking for some way to recoup some money or maybe get more use out of their new hardware. Some companies would rent mainframe time during off-peak hours. Others would expand to offer new services. MetLife at some

point, started offering weather forecasting services. I don't know when this started. I've been trying to find catalogs or articles or press releases, but no dice. Sometime between 1967 and 1971, the service comes online. It uses the same setup as MetLife's normal network operations. Data is stored at local offices. During the nightly transfer, that data gets pushed into the central mainframe. But there's two key differences. One is that the weather service made two pulls, one in the morning and one in the evening. The other is that it was using slightly different hardware. At least, it was isolated enough from their main day-to-day insurance processing workflow

that it could be targeted as a separate element. This is also where we get some more details on the system. The actual events of the weather system incident are described pretty well in McKnight's book, computer crime. We're still in this period where computer security is an afterthought at best. The MetLife system, however, does have a small amount of system security in place. The issue, though, is that the security setup left a pretty gaping hole in the system. When the mainframe called out to a branch office, that office computer entered a remote control mode, it was set up to accept a set of commands from the caller.

But what if the call was intercepted? How can the mainframe be sure that the office computer was actually who it thought it was, and also that the office computer wasn't going completely haywire? Well, the mainframe knows what the branch machine reported during the last call. So, to start the transaction, the mainframe would ask the branch machine to repeat back what it sent last time. It's essentially like calling someone up and being like, hey, do you remember our last conversation? And if they fail to answer, well, your friend may not be on the other end of the line. In the case of MetLife's computers, data was stored on tape, so it was just a matter of reading off the spool.

All the reporting I've seen calls this an echo check. If the mainframe received the expected data, then it went ahead with the transaction. The mainframe would then request the new data set, and once that was sent over, it would tell the branch computer to rewind the tape. I think things were probably a little more complex than that. Specifically, I doubt that old-school resource-sensitive programmers would accept transmitting data twice. It's more likely that the echo check used something like a checksum, basically a short fingerprint generated from the full data set. That would limit the amount of data sent over the network and the amount of time the network was tied up.

Plus, checksums have been a pretty standard trick for decades upon decades. Details aside, that's how things operated. So, can you spot the security hole? I'll give you a second if you want. All right, you're ready? The design is built to prevent a rogue branch computer from sending bad data to the mainframe. But this does nothing to protect the computer or the device

sitting in branch offices. Or, rather, it does next to nothing. The only thing preventing an intruder from sending commands to a branch office's computer is, well, the commands themselves. Some random hacker off the street wouldn't know what constituted a valid command. But that can be overcome. If you spend enough time probing phone signals, you could figure out those commands. It would be a matter of finding out what kind of bod rate the computer expected,

then guessing it commands and reading what the computer sent back until you got something good. Given enough time, it would be possible. Hackers have gone on much more wild goose chases than this. This security measure, if you want to call it that, is, oftentimes called security through obscurity. Because who's going to spend all the time figuring that out? That sounds like an outside chance, right? Who would want to mess with a MetLife branch office?

Besides, all you'd be doing would be dealing with data collation. You wouldn't be able to corrupt data in MetLife's mainframe. You probably couldn't even steal useful data since you'd need some way to decode whatever you pulled off the phone line. That would take a computer of your own and a modem. That wasn't really possible for a scrappy group of hackers in 1971. There is another way to exploit the security hole, however. If you knew the commands to send ahead of time, then you could go hog wild.

But who would know those commands? And who would have motive? Who would want to cause annoyance for MetLife? The networking system wasn't actually developed by MetLife themselves. It was created and maintained by Honeywell. Part of that was hardware and ongoing support, but this was a big system. As it grew, it would approach 1,000 branch offices. So to keep things going, Honeywell lent MetLife a number of operators.

They would know the commands to make these machines sing because they were responsible for day-to-day operations. What about motive? Well, would you believe it had next to nothing to do with MetLife? In 1971, 25 members of the local 459 international union of electrical radio and machine workers went on strike. The strike started in September, and all the strikers were Honeywell employees.

details about the strikers sparse. In one article, a union rep claimed the strike was over Honeywell's failure to bargain in good faith. Three of the strikers, who had been working on the MetLife project, hatched a plan. There are no interviews or statements from those three strikers, so we can only guess at their motives. They could have been trying to apply a little more pressure on Honeywell, or they could have simply been messing around. It's also possible that it was done to prove a point to some unknown co-worker. Anyway, here was the grand plan. They started by getting a recording of the mainframe calling out to a branch machine.

This was likely done while they were still on the job, by just picking up a receiver after hours and waiting for the command to come down the line. We're dealing with old phone lines here, so all of the signaling on the network was done as audio. Think of the honking and screeching that old modems made, and you should be pretty close to what these hackers captured. The audio signal was saved down on a tape recorder. Specifically, the hackers only captured the signal to start an echo check. With the setup done, it was time to cause mischief, criminal or otherwise.

It would be possible to do the hack from anywhere with a telephone. Just dial a MetLife branch office and play the tape back in. the phone's receiver. The computer on the other end, the hapless machine, would assume that MetLife's mainframe had just sent them a command. Dutiful to a fault, the machine would read its tape and send over yesterday's data. Then, when the actual mainframe called, the tape would be in the wrong place. It would have already been read and never been rewound, so the command for an echo check would wreak havoc. That, to be honest, is kind of a slick hack. Also, just to add to the image here, the signal was probably stored on a cassette tape. At the time, cassettes were

kind of new, but they'd been around long enough that some computer nerds probably just had one kicking around. So we literally have a cassette tape with a special sound on it that kills a computer, or at least causes some processing issues with weather data. But still, details aside, it's pretty neat. It's the evil cassette of doom. Now, as for the havoc, well, that's where things get odd. We know this resulted in failed forecasting. The affected branch machines couldn't echo out yesterday's data,

so the mainframe was programmed to reject their connection. The hack hit as many as 25 offices. Notice how small that is. Reporting at the time is a little confused and gave conflicting numbers, and we also don't know a whole lot about this part of the network specifically. I'm taking that 25 number from the book computer crime. The hack targeted MetLife's weather systems specifically, which sound like they only used part of the larger network.

So the possible footprint was limited, even if they were able to call every office that had a weather terminal. But what about the funniest part of the story? Did the hack actually cause computers to throw tape all over the floor? That's actually attested to in two contemporary articles I've read, specifically that it spilled paper tape all over the floor. MetLife used a Honeywell-1800 mainframe at their central office, but again, I'm not sure what their brand is.

branch offices used. I was looking around because I'm interested in what the actual mechanism was here. Some of Honeywell's earlier tape drives were cabinets that had actual spools of paper tape. That would have prevented a physical failure from occurring since if the spool was pushed past its available tape, it would just, well, spin. There's a take-up reel, so it would keep the tape wound. There wouldn't really be a problem. For the tape to get ejected, we're probably dealing with some more stripped-down kind of system. There are some paper tape systems that pass the tape over a more exposed readhead. Think something like the tape side of a flexor writer or teletype.

Those types of readers don't always have a take-up reel. You can also load in just a ribbon of tape instead of a whole spool. Point is, the more comic part of this caper is actually possible. and that sets some tight parameters on how MetLife's offices were running their tape drives. But that's not quite as interesting as the simple answer that, yes, it's entirely possible that this hack did lead to tapes being thrown on the floor by their drives. So rounding things up, we get two consequences when a machine's hit by this hack. First, it messed up MetLife's weather services, which supposedly came at a bad time.

According to computer crime, this was right in the middle of a storm. So customers were kind of relying on that data, and when it was needed, it was nowhere to be found. And secondly, the hack messed up some office floors. However, that's not awful. The hack didn't result in actual lost data. The data is still there. It's just thrown on the ground. And it didn't actually target insurance systems.

It only targeted weather reporting systems. that piggybacked on MetLife's larger data network. It was just annoying. But it did point to a possible flaw in MetLife's network. And worse, at the beginning, MetLife had no way of explaining this. As a pro myself, I can tell you that unexplained events, especially unexplained events that point to some kind of systemic flaw, they raise a very red flag.

MetLife called in Honeywell to determine if this was something wrong with their software or hardware. They also called in AT&T to see if there was an issue with the phone lines. Neither line of inquiry went anywhere. All systems appeared fine. There had to be some other explanation, possibly a human factor involved. And this is where we go full ghost story. So cast yourself back to 1971. The new-fangled computer hardware at your office is acting up.

It's throwing tape all over the floor every night. You, a poor desk clerk, are called into your boss's office. They want you to spend the night in the office and watch for anything suspicious, maybe even catch the machine in the act. So, you hole up in the machine room. We can only imagine that you're armed with a cup of coffee, a flashlight, and a blanket. The tactic, as silly as it sounds, actually worked out.

They sat down a clerk overnight in the West Plain office of MetLife, and that clerk watched as a call came in over the switchboard. That call made its way to the office's machine, and then the tape reader came to life, and it never rewound. The trick was revealed. It had to be some kind of digital intruder, or, as another period, hack attack would call it, a midnight writer. From there, it was straight to the cops.

AT&T helped trace the number to a local union hall, but funnily enough, not the local 459's hall. The three hackers were actually using a phone from a meeting hall used by a different chapter of their union. A warrant was issued, and police carried out a no-knock raid on the union hall. The three hackers were caught in the act, arrested as they were dialing in office. Their tape recorder was even impounded. So, debacle over, right? Well, not exactly. This is 1971.

The Computer Fraud and Abuse Act is enacted in 1986. That's the first time we get specific laws around digital law. crime. So how do you deal with something that looks like crime around a computer when there are no laws about crime committed around computers? The district attorney charged the three hackers with aggravated harassment. That's not exactly a major crime. One computer world article points out that this is the same charge used when someone makes annoying phone calls to a victim. The trio was even released on a pretty low bail. Honeywell and MetLife both refused to press charges, so the issue just dried up. It was more a blip than anything. Now, you may ask,

why wouldn't Honeywell or MetLife want to press? This comes back to, in large part, the era. Pressing charges would lead to a trial. There isn't any established body of law around digital crime, so the trial could get weird. the proceedings will be that the companies have to admit there is a security flaw in their system. They will have to reveal how they were hacked. That's a bad look at best. Many computer crimes in the period just didn't go to court because of this. No one wanted to get embarrassed. At the end of the day, this is kind of the classic hack, and it seems like the attack was designed as just that. There was no long-term damage, except maybe the reputation of MetLife's

weather service that they ran on the side. Could have also been a little bit of an embarrassment for whoever at Honeywell designed the security part of the system, but no data was actually lost. The only financial cost incurred was overtime for a desk jockey to watch a tape drive. It's just harmless mischief that raised the blood pressure for a few dudes and white collars. But that way, I think it's just plain funny. These hackers had access to MetLife's system before they went on strike. It would have been just as easy to do something truly malicious. That's the undercurrent for a lot of these funny early hacks. If they had recorded some different commands and used different numbers, I don't doubt they could have stolen vital data. They could

have injected fake data by tricking the mainframe. They could have stolen the identities of MetLife's clients. Instead, they chose to just make a mess on a few office floors. All right, that does it for the first episode of Spook Month 2025. I'll be back next week with another short story about the more frustrating and downright frightening aspects of computing. Until then, you can find links to my Patreon and everything else over at advent ofcomputing.com. And as always, have a great rest of your day.