Ashley Madison: When Will Privacy Breach Liability Be Taken As Seriously As Other Safety Breach Liabilities?

In the wake of the Ashley Madison privacy breach, people have killed themselves. This is a breach that should be no different from a breach of any other safety promise from a vendor: it has been the case for years that when privacy is breached, people die. It has just happened in remote areas where the Western world can drone people based on surveillance data without news crews reporting much about it. With people dying from the Ashley Madison breach, the very real fallout from privacy breaches becomes more visible and tangible.

People in the privacy sphere have long talked about how data breaches aren’t solely the fault of a “rogue hacker”, as mainstream media (with a considerable vested interest in the matter) like to put it, but also a matter of following best privacy practices and having solid security engineering. If you don’t build a bridge to best practices, people die. If you don’t build a computer system to best practices, people die. Why is it the vendor’s fault in one case, but not in the other?

In other words, why is privacy always your own responsibility, and never the liability of those who promise it to you?

In this case, we have a database of twenty million people who are seeking to break somebody’s trust. Regardless of what one thinks of that as such, it’s arguably very sensitive information, in a database that Ashley Madison promised to keep private – and even charged heftily to delete profiles from (which, it turned out, wasn’t actually done). There are thousands and thousands of other companies that have sensitive data on you, in various forms, and which likewise have promised you in various ways to safeguard that confidence.

Sadly, such promises are mostly in the form of “privacy policies” that have something in common with “environmental policies”, “diversity policies”, and “social responsibility policies”, in that more often than not, they are write-only documents: they are ticks in a box, rather than something intended to ever be read – and much less adhered to. “Do you have a privacy policy? Yes, we have a privacy policy.” (“What does it say? I have not the faintest idea.”)

From experience, we can tell that companies typically don’t care the slightest to safeguard your private data – mostly because there’s no penalty whatsoever for ignoring their own privacy policies. They can sell a promise that doesn’t exist, one that there was never any intention to deliver on (or even awareness of what the written promise was!) and there’s no consequence at all.

Compare this to a “building construction safety policy”, which most certainly isn’t a write-only document: it’s read thousands of times daily at construction sites to make sure people don’t die from substandard engineering. Further, construction engineers who are ordered to cut corners blankly refuse to do so out of professional conduct, whereas in software engineering, it’s rare that software engineers are even aware they are cutting corners in security and safety. There is no requirement to deliver on your promises. There is not even a requirement to be aware of what safety you promised.

When somebody kicks their sneakers at the concrete base of a building and it collapses from the soft impact of an ordinary kick, we don’t blame the person kicking (the “hacker”). We blame the constructors who obviously tried to get away with cornercut cheap substandard engineering. Why isn’t this also the case with software engineering and sensitive databases containing private data?

Privacy is safety.

A privacy breach should be considered as serious as any other safety breach.

In the meantime, sadly, your privacy remains your own responsibility.