Real History of the Word “Hacker”

For many years I’ve talked about writing this up, so much that I feel guilty for telling the story before I wrote it down.

Executive summary

The term hacker used today appears to have stemmed from a word recorded in English by the 1200s, as horses for hire were referred to as hackneys. Coaches for hire took the horse’s name in the early 1600s, when London moved to restrain hackney coaches by royal proclamation in 1635 and put them under license by act in 1662. The word shortened to “hack” around 1700, imported to the colonies, and American drivers cruising for fares were still “hacking” through the 1900s.

A “hack” became defined by the 1690s as someone doing routine work for hire, the drudge writer being the type specimen. It was June 1959 when the Tech Model Railroad Club at MIT put both words in its club dictionary: a hack was a project pursued past constructive purpose, and a hacker was simply one who hacks. Club members carried the vocabulary onto the TX-0 computer and into MIT’s new artificial intelligence group in those same years, which is how a railroad club’s word attached itself to computing.

That’s right, AI is to blame. Thanks MIT.

Perhaps most interestingly, from the 1200s to today, the English term hackney/hacker is related to what appears to be a human condition; it changed in meaning only marginally despite communication evolving from ancient dirt roads of horses delivering envelopes to today’s digital networks of apps delivering packets.

When you think about people taking possession, not ownership, of a carriage or a car and poking around city streets to find riders to pay them…imagine instead people taking possession, not ownership, of an application or website and poking around networks to find assets they can profit from.

Detailed backstory

The earliest detailed mention of a word appearing similar to “hacker” that I have found so far appears in a fun story from 1396 with “hackneys” and “hackneymen”.

“Packhorse, Waggon and Post: Land Carriage and Communications under the Tudors and Stuarts, 1st Edition”, by J. Crofts, p 63

Hackneys were horses and their operators were the hackneymen. This was a form of “for hire” shared service, which provided inexpensive/efficient delivery of people, packages and communications.

Saying a hackneyman is someone for hire seems already very close to modern usage, and American cab slang completed the circle centuries later, when driving for fares became hacking and drivers became hackers.

A political hack is someone you probably think of being “coin operated”. A hack writer is someone you probably think of paying bills with low-grade publications. A hack on the street is someone you probably think of when you want to take a ride in exchange for money.

I’ll make a quick aside here for the term ‘tohaccian’, an Old English verb meaning to hack into pieces. It sits in Bosworth-Toller and philologists accept it as ancestor of the modern cutting verb. It belongs to a separate lineage from the horse. Merriam-Webster derives hackney from the name of the parish of Hackney, whose nearby meadows may have pastured horses. Two words traveled two roads and converge only in modern spelling, so the cutting verb sits aside here because this post follows the hire lineage.

When “tohaccian” goes into an Old English translator, it maps forward to “hack” and “cut”. Reverse lookups for ‘hack’ surface other cutting words, “inbesléan”, “hêawan”, “aceorfan” and so on, and the horse appears nowhere in any of them. The lookup tables confirm the split. Every road from tohaccian leads to cutting, and every road from the hackney leads to hire.

It can be fun to read through an entire list of unskilled and profit-oriented jobs over history that have been labeled as “hackers” (people cutting things notably excluded), as found in the Collins Dictionary, which also displays a chart of usage starting in the 1700s.

Merriam-Webster carries the whole thing in one entry: the horse for ordinary riding, an obsolete sense for a person who works for hire, a current sense for a carriage or automobile kept for hire, and a verb from the 15th century meaning to make common, then trite and vulgar. The entry dates the noun to the 13th century and roots the etymology in the parish of Hackney, whose nearby meadows may have pastured horses. The thesis of this post sits inside that entry as sense three, marked obsolete.

What I like about the Crofts excerpt at the top is a discussion about security of messages in transit and people stealing from the service providers (e.g. 14th century equivalent of telephone company phreaking):

Also note the title of the book I’m quoting says it is about communications during the Tudors (1485-1603), who came onto the scene 100 years after this excerpt from 1396, and also the Stuarts (1603-1714) who were another 100 years after that.

Hopefully it is obvious why 1396-1714 remains relevant to a term like “hacker” today. If not, I can offer you a bit more detail about the systemic information security threats and methods of early English times.

For example cryptography historians recently hosted an exposition on Tudor secrecy methods and attacks, discussing security management within an ancient “hub” of communications.

…secrets of Henry VIII and Elizabeth I will be revealed at Bletchley Park. It was during their reigns that a code system developed so complex it was not broken for nearly 300 years. Tudor spymasters and code breakers were the power behind the throne leading to the defeat of the Spanish Armada and the execution of Mary, Queen of Scots.

17th through 19th century

As another aside, remember how the dictionary mentioned “vulgar” and “commonplace”. The best example of that is The Merry Wives of Windsor, where Mistress Page says these knights will hack. The line lives only in the 1623 First Folio; the 1602 quarto version of her speech skips the knighting riff, and editors read the joke as a swipe at the flood of new knights James I created after 1603. Editors split on the gloss, some reading it as becoming common and cheap, several reading it plainly as whoring. Every gloss keeps the hire sense and drags it into the gutter:

“The Merry Wives of Windsor”
by William Shakespeare, p 73

A Philosophical and Practical Treatise on Horses” John Lawrence, 1796. Pages 164-5 wrote that hack or hackney was a general term for a “tough and everlasting” (Page 239) road horse, not necessarily an inferior one or one for hire.

We see this usage again in 1893 when Rush Shippen Huidekoper writes on pages 296-7 of “The Hackney Horse” about “the hackney, or common road horse”

Carriages had carried the horse’s name for three centuries by then. Hackney coaches ply London streets in the 1620s, a royal proclamation moved to restrain them in 1635, and an act of 1662 put four hundred under license. Statute law kept the term alive into the railway age, as we can see in the London Hackney Carriage Act, 1831 and from several rules in a “The Hackney Carriage Pocket Directory for 1832

  • Numbered plates to be placed upon hackney carriages — Penalty for concealing plates, or preventing persons inspecting and taking the number thereof.
  • Hackney carriages standing in any street to be deemed to be plying for hire, and the driver thereof refusing to go with any person liable to a penalty of 40s.
  • Number of persons to be carried in a hackney carriage to be painted thereon.–Penalty for neglect, or refusal to carry the number, 40s.
  • Deposit to be made for carriages waiting.–Penalty on the driver refusing to wait, or to account for the desposit, 40s.
  • A clear space of ten feet to be left after every four hackney carriages on any standing.–Penalty 20s.

MIT 1950s

Peter R. Samson in Tech Model Railroad Club of MIT in June 1959 publishes “AN ABRIDGED DICTIONARY of the TMRC LANGUAGE.”

1) something done without constructive end; 2) a project undertaken on bad self-advice; 3) an entropy booster; 4) to produce, or attempt to produce, a hack3.

HACKER: one who hacks, or makes them

The Jargon File begun in 1975, canonized the computing senses. The entry below shows the file as it stood by the early 1980s, opening its hacker entry with the axe and the cutting lineage, which shows how completely the two roads had merged by then:

HACK n. 1. Originally a quick job that produces what is needed, but not well. 2. The result of that job. 3. NEAT HACK: A clever technique. Also, a brilliant practical joke, where neatness is correlated with cleverness, harmlessness, and surprise value. Example: the Caltech Rose Bowl card display switch circa 1961. 4. REAL HACK: A crock (occasionally affectionate). v. 5. With “together”, to throw something together so it will work. 6. To bear emotionally or physically. “I can’t hack this heat!” 7. To work on something (typically a program). In specific sense: “What are you doing?” “I’m hacking TECO.” In general sense: “What do you do around here?” “I hack TECO.” (The former is time-immediate, the latter time-extended.) More generally, “I hack x” is roughly equivalent to “x is my bag”. “I hack solid-state physics.” 8. To pull a prank on. See definition 3 and HACKER (def #6). 9. v.i. To waste time (as opposed to TOOL). “Watcha up to?” “Oh, just hacking.” 10. HACK UP (ON): To hack, but generally implies that the result is meanings 1-2. 11. HACK VALUE: Term used as the reason or motivation for expending effort toward a seemingly useless goal, the point being that the accomplished goal is a hack. For example, MacLISP has code to read and print roman numerals, which was installed purely for hack value. HAPPY HACKING: A farewell. HOW’S HACKING?: A friendly greeting among hackers. HACK HACK: A somewhat pointless but friendly comment, often used as a temporary farewell. [The word HACK doesn’t really have 69 different meanings. In fact, HACK has only one meaning, an extremely subtle and profound one which defies articulation. Which connotation a given HACK-token has depends in similarly profound ways on the context. Similar comments apply to a couple other hacker jargon items, most notably RANDOM. – Agre]

HACKER [originally, someone who makes furniture with an axe] n. 1. A person who enjoys learning the details of programming systems and how to stretch their capabilities, as opposed to most users who prefer to learn only the minimum necessary. 2. One who programs enthusiastically, or who enjoys programming rather than just theorizing about programming. 3. A person capable of appreciating hack value (q.v.). 4. A person who is good at programming quickly. Not everything a hacker produces is a hack. 5. An expert at a particular program, or one who frequently does work using it or on it; example: “A SAIL hacker”. (Definitions 1 to 5 are correlated, and people who fit them congregate.) 6. A malicious or inquisitive meddler who tries to discover information by poking around. Hence “password hacker”, “network hacker”.

HACKISH adj. Being or involving a hack. HACKISHNESS n.

So hacker has a particular lineage. Meanwhile, thieves were cracking cribs in the flash slang of the early 1800s, safe crackers followed, and by November 1969 newspaper coverage of the Fall Joint Computer Conference in Las Vegas warned firms about the “computer cracker”, the computer framed as a vault of information.

A Common Security Fallacy? Too Big to Fail (KISS)

Often I have journalists asking me to answer questions or send advice for a story. My reply takes a bit of time and reflection. Then, usually, although not always, I get an update something like this:

Loved what you had to say but had to cut something out. Editors, you know how it is. Had to make room for answers from my other experts…I’m sure you can understand. Look forward to hearing your answer next time

I DO understand. I see the famous names of people they’re quoting and the clever things they’re saying. They won, I lost. It happens. And then I started to wonder why not just publish my answers here too. That really was the point of having a blog. Maybe I should create a new category.

So without further ado, here’s something that I wrote that otherwise probably never will see the light of day:

Journalist: Tell me about a most common security fallacy

Me: let me start with a truism: KISS (keep it simple stupid)

this has always been true in security and will likely always be true. simpler systems are easier to secure because they are less sophisticated, more easily understood. complex systems tend to need to be broken down into bite-sited KISS and relationships modeled carefully or they’re doomed to unanticipated failures.

so the answer to one of most common security fallacies is…

too big to fail. also known as they’re big and have a lot to lose so they wouldn’t do the wrong thing. or there’s no way a company that big doesn’t have a lot of talent, so i don’t need to worry about security.

we’ve seen the largest orgs fail repeatedly at basic security (google, facebook, dropbox, salesforce, oracle!) because internal and external culture tends to give a pass on accountability. i just heard a journalist say giant anti-virus vendors would not have a back door because it would not be in their best interest. yet tell me how accountable they really are when they say “oops, we overlooked that” as they often do in their existing business model.

for a little historic context it’s the type of error made at the turn of the century with meat production in chicago. a book called “the jungle” pointed out that a huge fast-growth industrial giant could actually have atrocious safety, yet be protected by sheer size and momentum from any correction. it would take an object of equal or greater force (e.g. an authority granted by governance over a large population) to make an impact on their security.

so the saying should be “too big to be simple”. the larger an organization the more likely it could have hidden breaches or lingering risks, which is what we saw with heartland, tjx, target, walmart and so on. also the larger an organization the less likely it may have chemistry or incentives in place to do the right thing for customer safety.

there’s also an argument against being safe just because simple, but it is not nearly as common a fallacy.

Roll Your Own Kali 2.0 ISO

I noticed the good Kali folks have pre-released steps to make your own ISO for their upcoming 2.0 release.

# Workshop 01 – Rolling your own Kali 2.0 ISOs

I also noticed the steps do not work as written, mostly because files moved from archive to www. So here’s what worked for me:

Use existing Kali instance to prepare

$ sudo apt-get install live-build

This will install debootstrap 1.0.48+kali3, live-boot-doc 4.0.2-1, live-build 4.0.401kali7*, live-config-doc 4.0.2-1, and live-manual-html 1%3a3.0.2-1

Clone the builds

$ git clone git://git.kali.org/live-build-config.git
$ cd live-build-config

Add tools

$ echo “cryptsetup
> gparted
> amap” >> kali-config/variant-light/package-lists/kali.list.chroot

Enable SSH service at boot

$ echo ‘update-rc.d -f ssh enable’ >> kali-config/common/hooks/01-start-ssh.chroot
$ chmod 755 kali-config/common/hooks/01-start-ssh.chroot

Add your own public SSH key

$ mkdir -p kali-config/common/includes.chroot/username/.ssh/
$ cp ~/.ssh/id_rsa.pub kali-config/common/includes.chroot/username/.ssh/authorized_keys

Add unattented install option

$ vi kali-config/common/hooks/02-unattended-boot.binary

#!/bin/sh

cat >>binary/isolinux/install.cfg <
$ chmod 755 kali-config/common/hooks/02-unattended-boot.binary
$ ls -al kali-config/common/hooks/

Create the unattended seed

$ wget https://www.kali.org/dojo/preseed.cfg -O ./kali-config/common/includes.installer/preseed.cfg

Install wallpaper (BlackHat or DEFCON blue)

$ wget https://www.kali.org/dojo/wp-blue.png -O kali-config/common/includes.chroot/usr/share/images/desktop-base/kali-wallpaper_1920x1080.png

NOTE: the images/desktop-base directory has disappeared in later builds. just add it back in with mkdir

Build the ISO

$ ./build.sh –variant light –distribution sana –verbose

After successful build the live-build-config/images subdirectory will have a 900M “kali-linux-light-sana” iso file.


* NOTE: If you want to use another platform such as Ubuntu 14.04 you may find the usual package (sudo apt-get install live-build) causes problems. When you run the build.sh script it checks versions and fails like this:

ERROR: You need live-build (>= 4.0.4-1kali6), you have 3.0~a57-1ubuntu11.2

It should be possible to meet the dependencies and edit config files using the Debian live-build:

$ git clone git://live-systems.org/git/live-build.git

However because “kali” is specified in the live-build version check…after several attempts on other systems to work around I gave up and took the easy path — use an old kali system to build a new kali.


Updated to add: Rolling a trusted ISO is fun but obviously a docker pull is far easier and more risky. Note the need for signed repository images if you’re going this route instead.

  • docker pull kalilinux/kali-linux-docker
  • docker run -t -i kalilinux/kali-linux-docker
  • /bin/bash apt-get install metasploit-framework

Saving the Bobcat: Lessons in Segmentation and Surveillance

California has just passed a statewide law banning harm to the bobcat.

The decision of the Commission reflects a growing sensibility in this state that wildlife should not be stalked, trapped, shot, or beaten to death for sport or frivolous goods

The move came after it was revealed that attackers had advanced in two significant ways: monitoring the Internet to find targets and then using lures to pull the targets out of state parks where they were protected.

trappers monitor social media for wildlife lovers’ bobcat photos to determine where to set their traps

Bobcats under attack

The state finally was forced to react after 30,000 signatures called for action to deal with the obvious social harm. California decided to expand scope of protection from porous safe zones to the entire state.

Those familiar with PCI DSS compliance realize this is like a CIO agreeing to monitor every system under their authority for motivated attackers, instead of defining scope as only those few servers where PII should be found.

Justification of a statewide ban was based not just on evidence of attackers bypassing perimeters with ease. Conservationists pointed out that the authorities have failed to maintain any reasonable monitoring of harm to state assets.

[California] could not determine whether trapping jeopardized the species because they had no current scientific data

Thus we have an excellent study in nature of what we deal with constantly in infosec; a classic case of attackers adapting methods for personal gain while community/defenders are slow to build and examine feedback loops or reliable logs of harm.

Should it have taken 30,000 signatures before the state realized they had such obvious perimeter breaches?

Fortunately, bobcats now are protected better. The species will have a chance of survival, or at least protection from attack, as scientists figure out how best to design sustainable defenses.

Action taken sooner is far better than later. Once the species is driven to extinction it may be impossible to restore/recover, as has been the case with many other animals including the bear on the state flag.

a blog about the poetry of information security, since 1995