Category Archives: History

History, Security

Should You Trust the AirBnB Platform?

Leave a comment

Lately one of my favorite jokes in SF is we haven’t reached peak yet because no one has tried to start AirBnBurrito. How can we just continue to order burritos without some kind of abstraction to improve our burrito experience? Why isn’t there a burrito sharing platform?

Platform is the hot new buzzword. We’ve never seen platforms of sharing like these before. Think disruption. Think possibilities.

WARNING: SECURITY PROFESSIONAL OPINION AHEAD.

VIEWER DISCRETION ADVISED.

For example if you put a smooth asphalt platform down where you live, then people can drive toxic chemical emitting boxes of death all around you. Those significant increases of disease in your home area from passers-by are a benefit, really, because they spur innovations in health care. Now that you have created a platform that leads to lead poisoning and asthma you can create a platform to search for how to remove lead poisoning and asthma…

I hear you saying broken window fallacy but wait, wait hear me out.

If you put a wireless transmission platform down, or even a spinning disc with recorded music platform down, you can give musicians pennies on the dollar for their work. You can build lavish studios and host amazing parties and promotional events on the backs of the kids who actually create music and then spit out those used up kids as the next batch of kids arrives.

Too much snark in my historic examples? Ok let’s be serious, the question should arise every time you hear the word AirBnB whether you have good reasons to trust a platform. What if history is just repeating itself, benefiting a few by allowing a clever shield scheme to avoid direct responsibility for harms that are externalized or spread widely? Platform risk is complicated and should not be treated lightly.

A platform company evangelist or product manager will probably tell you their developers are all responsible people who can be trusted implicitly to do the right thing; no need to have oversight because people are just naturally good. In reality, however, when you talk to the platform engineers behind closed doors you will often find a modern version of Sinclair’s 1906 novel “The Jungle”; history has some very important lessons to be remembered.

“Developers are our worst enemy” a car ride sharing platform security team member revealed to me recently, explaining further that “developers are so sloppy with credentials we had to hang one to make an example to the others”. This is a fine point. If we don’t make examples, or talk about security issues directly and openly, a platform may enable very bad things.

Sinclair wrote in 1906 the meat-packing industry was so poorly managed that the death of employees was a very real and pressing concern. He published a book about the need to protect worker rights. The US government, loathe to be too concerned with the lower classes, pivoted from complaints about worker rights to create an agency that protected consumer trust and capital investment in food and drug platforms (FDA).

Today the new “sharing industry” data is so poorly managed that invasion of privacy is a very real and pressing concern…any guesses the direction regulators eventually will go?

With that in mind take into consideration a new light-hearted story called “Airbnb Shares The Keys To Its Infrastructure”

Pfffffft. Right off the bat I have to wonder whether the title is meant to make infosec professionals spit tea all over their monitor. Because that’s what I did.

To be fair I would gamble the title was really meant to be some kind of innocent “sharing” reference. Cue the little bunnies and kittens fluffing around. So tempting…

But to the trained security professional ear it comes across as nails on chalkboard “AirBnB goes on vacation and leaves your doors unlocked”

Ok, but nevermind the title. It is just a title. Let’s get right to the meat of the issues within the story. Let’s go right to the paragraph about…

Search for the word security: 0 hits

Search for the word confidential: 0 hits

Search for the word privacy: 0 hits

Search for the word risk: 0 hits

Search for the word trust: 1 hit!

While renting out an apartment or a house when it is empty is certainly not a new idea, Airbnb has taken it all to a new level and has built the idea of trust – of the people you are renting from as well as the people you are renting to – into its system, which has no doubt been a catalyst that has propelled its business.

Wat. Trust is built into wat system. Wat

Color me shocked. First, their supposed “new level” trust system actually has been proven to be antiquated and quite primitive. It has run into easily predictable failures that any hotel, let alone a reasonably thoughtful individual, would be prepared to handle.

…logic and decency would suggest that when you’re in danger, as Mr. Lopez claimed to be, Airbnb would come to your rescue. And in the wake of this episode, Airbnb said on Friday that it was clarifying its policies to make sure that its employees know to always call the police when someone reports an emergency in progress.

AirBnB management was unprepared for an emergency, leaving customers and employees in an untenable trust relationship. Is that the “new level”?

Second, in the text of this new story about keys to infrastructure the closest mention to anything security related that I could find was a little bit on segmentation, and that was only because a failure of availability.

We actually had to do a big cluster migration at the end of last year to separate all data infrastructure into two separate mirrored clusters: one to run all of the business critical jobs – things that have to be run and done on time – and another one for ad hoc queries. When we had it all running on one cluster, people were so interested in learning from the data that the ad hoc queries could get in the way of some of the business critical work.

They actually had to separate clusters because load. Not because privacy. No, the lack of privacy control is exactly what led to the availability failure.

Let me just say that again to be clear. Segmentation is not described as a safety issue but only in terms of performance. And yet to me the age-old problem of having too many chefs in a kitchen is an obvious safety issue much more than a performance one.

If you’re like me you’re now dying to know how privacy is being protected in the AirBnB world of sharing data as widely as possible for profit. Surely there must be some importance of privacy meant to be implied somewhere…especially in paragraphs like this one:

Airbnb actually teaches classes in SQL to employees so everyone can learn to query the data warehouses it maintains, and it has also created a tool called Airpal to make it easier to design SQL queries and dispatch them to the Presto layer of the data warehouse. (This tool has also been open sourced.) Airpal was launched internally at Airbnb in the spring of 2014, and within the first year, over a third of all employees at the company had launched an SQL query against the data warehouse.

Great. SQL being taught internally to everyone is just great. Everyone is being told to crowd into the kitchen and sharpen their knives.

What I’m really looking for, however, is an explicit statement more like “Airbnb actually teaches classes in privacy to employees so everyone can learn to protect customer data…”.

Instead I hear a company talk light-heartedly about giving keys to everyone, training everyone to dive in and start without any mention of due diligence or care.

The article is alarming because it emphasizes trust and then gives basically no reason at all to believe in it. Is consumer safety of any real concern? If this doesn’t get regulators poking into AirBnB I am not sure what should.

And all that doesn’t even touch on the logical inconsistencies. For example contrast these statements from the same person:

  • “the bad part is that Mesos, by its nature, is a layer of abstraction and it obscures some things from you”
  • “I intuitively believe that we are making the most of our engineers to push the business forward and doing it in a cost effective way on AWS” [because abstraction obscures some things from you and that’s just great. it’s so great i look back and wish i had increased obscurity 45%]

Just to reiterate the lesson being taught here: The bad part is abstraction; it obscures things from you. That’s bad. So we should push the business forward and in a cost effective way with abstraction. Bad is good for business. See?

But forget about the illogical flaws in reasoning for now. That’s just typical of cloud platform hype. Instead ask the tough questions about whether AirBnB gives you any reason at all to trust them if they’re sharing keys to your data.

END OF WARNING

So anyway as I was saying you may want to read the new piece about hot platforms and how AirBnB is doing fun stuff these days. It’s a good fluff read on the platform. Check it out and enjoy.

History, Security

Larger than Life (Stawka większa niż życie)

Leave a comment

Today in 1939 Hitler and Stalin signed the Molotov-Ribbentrop Treaty (non-agression pact) secretly dividing Poland. To add perspective I thought I would mention a classic spy video series that is not widely known outside Poland.

Polish television, from March 1967 to October 1968 (18 episodes), told the story of secret agent Stanisław Kolicki (codename J-23), who carried a secret mission in the Nazi army as Hans Kloss. Perhaps the most famous line of the protagonist is “Mow mi Janek”:

Call me Mike
Call me Mike

The series begins in 1941, two years after the Nazis and Soviets conspired to divide and conquer Poland. Episode one shows a young Pole, Stanislaw Kolicki, escape from Konigsberg camp on the Soviet side. He begins cooperating with Soviet intelligence by providing information about German troop concentration along the border. Soviet intelligence notices a confusing similarity, identical appearance, with a captured German Hans Kloss on the German side. Codename J-23 is born and Kolicki makes a daring run into German occupied territory. He begins organizing a counterintelligence network until the Gestapo become suspicious of radio communications and hunt him. He manages to fake his own death and escape back to the Soviet side. He then convinces Soviet intelligence to allow him to return. J-23 infiltrates the Abwehr again, this time as a “real” Lieutenant Kloss posted to Nazi military intelligence.

History, Poetry, Security

Real History of the Word “Hacker”

Leave a comment

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 meadows likely pastured horses for the London market. 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 meadows likely pastured horses for the London market. 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 1602, when the first quarto of The Merry Wives of Windsor printed Mistress Page’s line that these knights will hack. 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 two 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 canonized the computing senses by the mid 1970s, 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.

History, Security

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

Leave a comment

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.