The Multics "cookie" program was patterned not after Sesame Street's cookie monster (who had barely gotten onto the air by 1970) but after the annoying "Cookie Bear" character from the Andy Williams show of the 1960s.
The idea for the program was born during a Senior House bull session in 1970. Seth Stein, an MIT freshman from Providence, volunteered a story about an IBM computer operator at Brown who liked to tease his users by locking out their terminals and manually sending them messages asking for a cookie until they typed "cookie." "Say," I immediately thought, "this concept cries out for automation!"
The programming itself was relatively simple, and was done during a vacation week on a 2741 that SIPB had recently installed into the dorm for student use.
Because of Multics' fine security, the perpetrator usually had to wait until his victim left a terminal unattended to cause the program to run in the victim's process. Occasionally, a user left one or more of his files unguarded, allowing a tormentor to insert a command to invoke the cookie program in that user's start_up command file, his abbreviations, or as an executable reminder memo (in order of difficulty for the user to find later).
The hack was made truly difficult to find and purge by an unusual feature of Multics: the ability for a program to set an alarm timer and then terminate. At the specified time, the alarm timer would invoke a program, exactly as if the user had typed a command. That program could set another alarm timer, and so on. (The closest analogy I can think of is UNIX cron, except that no processes other than the user's own were ever involved.)
So when users examined the stack with the debugger to see what program was printing out "cookie messages," it was never there!
Only two handles existed by which a user could track down the cookie monster. The first was to list out all initiated segments in his process. Although this doesn't sound like a challenge in this day of CRT's on ethernet, few people on 133-baud IBM 2741's found this a useful option. (There was always the line printer, if you could wait until the next day for the output.) The other was to examine the timer manager's chain of requested timers, in the user's static section. However, you first had to suspect that a timer was involved -- and at the time cookie was written, there was no tool to find or dump this data anyway.
Despite the comparatively arduous nature of inter-site transfer in those days (no internet; mag tape was the usual method), the cookie program spread from its birthplace at MIT to practically every Multics site in the world. Analogous programs were even coded for non-Multics systems (such as the one that ran on the MIT AI lab PDP-10). The cookie program even found its way to the high-security classified installation in the Pentagon -- where your having been "cookied" was about the last thing you wanted your C.O. to hear about.
At least one resource publication on computer viruses has named this program as the earliest known example of a computer virus. Still, I am not convinced that amused human beings count as a qualifying infection vector.
The PL/I source of the program is available.
There was a lot of discussion on USENET of folklore surrounding the cookie monster. A lot of this is probably wrong or exaggerated.
03/13/95
I saw a variant of the cookie program on GCOS at Honeywell Phoenix ca. 1978. The idea had been taken from the cookie program that had made it to System M, and this variant was running on GCOS.
It was much simpler, and was using the batch submission system.
A card was inserted in the deck that required operator input. The job would pause, and repeatedly issue requests for a cookie. The job would repeat the demand every few minutes, much like a tape mount request, until satisfied by the operator typing "cookie". Some jobs repeated this behavior more than once.
It was a favorite prank against new operators who were alone on their first-ever solo 3rd shift.