Kinkkumyrkytys

At this time of year I'd like to make a serious public health announcement and make people aware of a strange, incurable, debilitating disease affecting the majority of people here in Finland at this time.

* * *

Kinkkumyrkytys (eng: hampoisoning)

A debilitating disease suffered around late December and sometimes early January by persons residing in Finland. Thought initially to be a genetic disease of the native Finnish population, it now appears to be some kind of virus that is transmitted to non-natives in that region.

The sufferer experiences symptoms of feeling too full, bloated and some nausea. It also causes the sufferer to lie or sit for extended periods of time; attempts to move or walk cause the above symptoms to become worse.

In a mechanism that is still unexplained the disease affects the vocal centres of the brain rendering the sufferer to emit grunts and be incapable of saying much more than simple sentences. Sufferers have been known to complain bitterly and say phrases such as "Ei ruokaa...", "Ei enää kinkkua taas...".

Curiously regardless of the nationality and language of the sufferer, these phrases are always in Finnish leading to speculation that this is some new class of neurological disorder. Because of the above utterances, it is believed that this is how the disease obtained its name.

In extreme cases the sufferer becomes a vegetable and can only blankly stare at contentless, bright, flashing pictures known as Finnish Christmas TV without comprehension for hours on end. In some serious cases people have been known to binge watch "Vain Elämä" - the prognosis in these cases is however extremely grave bordering on absolutely no hope at all.

Interestingly while sufferers have a complete aversion to roast ham at this time, other foods also cause the sufferers additional agony. These include: mätti (fish eggs), lipeäkala, joululimppu (Christmas bread), various kinds of "laatikko-" food including lanttu (swede), porkkana (carrot) and peruna (potato).

It has been suggested by some researchers that there may be a connection with excessive amounts of Christmas good consumed in Finland. However this research has been extensively denounced as being "pasta" - a Finnish term meaning "obviously not true you ignorant fool...pass me more ham and an extra helping of that lovely lanttulaatikko too!"

A secondary debate on whether lipeäkala is food or a chemical/biological weapon is tending towards the latter.

The symptoms of this disease continue for a number of days and the sufferer returns to full health quickly afterwards. However no immunity is gained and it is likely that the symptoms will reappear at the same time next year,

Some alternative therapists have suggested a treatment called "Tipaton tammikuu" involving consuming homoeopathic amounts of alcohol for a month. This rather dangerous and unethical therapy has been denounced as being "pasta".

100,000 page views

100,000 page views isn't huge...but for a blog that was meant to be a way of collecting links and thoughts and not really aimed at anyone in particular - though you might see a strong leaning to things such a privacy, astronomy, mathematics, computer science - I consider this to be quite a milestone.

And here it is, reached at 22:27 on 22 December 2015:

Nadolig Llawen

Hyvää Joulua

God Jul

Merry Christmas

Engineers for Privacy Professionals

As many discussions on this blog have pointed out, there is a mismatch between engineering and legal when it comes to privacy; one can even argue there's a mismatch between these two groups and privacy advocates too, but that's another story...

It is critical for anyone involved in privacy to understand that without the complete trust and involvement of the engineers who build the systems that are supposed to be compliant with whatever privacy policy exists, that compliance will be at best, fragile.

At the IAPP's DPIntensive meeting earlier this year I gave a presentation on the subject, here's the link to the slides.

Engineering Privacy Engineering from Ian Oliver

The main learning is that unless engineering is an equal part in your privacy discussions then you're really just playing at compliance.

Privacy isn't just about privacy policies or long winded legal documents but about education, learning and understanding that everyone depends upon everyone else in order for your business to successfully (and legally!) function.

I wrote about how privacy should be taught earlier with the quote:

It often surprises me that many of the people advocating privacy don't actually understand the things that they're trying to keep private, specifically information. Indeed the terms data and information are used interchangeably and there is often little understanding of the actual nature and semantics of said, data and information.

This is also seen in how we train our staff in privacy aspects - with the dreaded "privacy awareness training":

One thing that came up was the need for training and that privacy awareness training hasn't had the effect hoped for. Given that awareness training is exactly that, is it no surprise that once the, usually, one hour presentation on how we should all care about privacy is made nothing happens?

 
Actually, everyone is acutely aware of privacy in the first place and privacy awareness training rapidly becomes an exercise in CYA - as security expert Bruce Schneier might have put it - and have no effect whatsoever on the overall quality of development, customer privacy and company culture.

I guess we're still pretty naive about privacy and unless we have a cultural change this naivety will come back to haunt us for a very, very long time with some awful business repercussions.

Books on Privacy...gift suggestions

Need a good book on privacy? A Gift for Christmas, or even something for the New Year....follow this handy flowchart:

From Amazon (US, CA, UK, DE, etc etc...), Barnes and Noble and good booksellers near you...

Privacy Engineering
A dataflow and ontological approach

ISBN-13: 978-1497569713
ISBN-10: 1497569710
264 Pages, B/W on White Paper

Twitter Discussion on Privacy and Engineering

Related with the upcoming DSummit conference in Malmö in May I've been involved in a fascinating discussion on Twitter with some of the big privacy people there.

The main point being raised is the need for a proper dialog between engineers and lawyers. I think we've seen this before, but still it is not being properly addressed and until it is privacy will remain a compliance activity rooted in a tick-box mentality with dreadful repercussions.

One only needs to take a look at the potential penalties in the EU's GDPR ... a potential fine of 4% of global turnover for a privacy violation!

The crux of this is that if you want to construct systems with privacy as an aspect, it has to be a first class aspect of that system's design. That means privacy is under the collective responsibility of lawyers, engineers and management and not the sole preserve of any of these groups.

Belief in high-level privacy impact assessments and "compliance", and placing trust in a legalese privacy policy is woefully insufficient, not to mention from a business perspective one step short of insanity.

Unfortunately going beyond this is considered by some - and I've seen too many examples of this - to be difficult and unnecessary and that legal compliance - whatever that means - is enough...

As we move to a "BigData" future, the knowledge of basic data handling, quality and governance at both engineering and legal levels is critical - not just for privacy but for basic business reasons, including consumer trust and quality of product.

How to do this is not difficult, but it does require thinking and small, but extremely beneficial cultural change...

Agreed. Need to translate high level privacy principles & PbD, into specific engineering reqs @mdennedy @i_j_oliver https://t.co/a4hgcUhGnJ

— Privacy Matters (@PrivacyMatters) December 20, 2015

and here's a recommendation to get those principles into use:

@daraghobrien I found @i_j_oliver's and @mdennedy's books on privacy engineering of enormous value @ll1t

— Privacy Matters (@PrivacyMatters) December 21, 2015

You can start here:Privacy Engineering and A Privacy Engineer's Manifesto

More Data Breach Excuses

This particular case reported on the BBC has a nice excuse...

Adele tickets: Fans claim personal data has been breachedBy Mark SavageMusic reporterFans buying tickets for Adele's tour have told the BBC they were shown the address and credit card details of customers other than themselves.
But several fans said they saw other people's shopping baskets, including payment details, upon check out.
Ticketing company Songkick said due to the "extreme load" on the site some customers could see others' account details. It apologised for any "alarm".
"At no time was anyone able to access another person's password, nor their payment or credit card details (which are not retained by Songkick)," it said.

So let's go through this and start with the last paragraph which states that no-one was able to access another person's password nor their payment or credit card details, yet, in the first paragraph it states that people were able to see payment details. 

I assume it means that the full credit card number, expiry date and CVC number were not available, however whoever makes these statements really needs to check with the engineers and really understand what they are being told.

The one I particularly like is that these errors happened due to "extreme load". Which suggests that the underlying system - UI, middleware, database etc were not implemented with concurrency in mind. 

I could imaging that the system probably wasn't load tested and/or that probably someone didn't use BASIC TRANSACTIONS which are present in, well, all databases - it has been part of the SQL standard for years and years. 

Worse is that someone probably tried to reinvent transactions or semaphores in an inherently distributed system and failed. Probably the system only worked up until now because various race conditions had never materialised - not even in testing - assuming that the tests had been properly created.

I can also imagine that the developers were rushed and probably forced to use some new technology that they didn't understand and that some manager somewhere had probably read an article about NoSQL and demanded that everything become a bizarre mix of Java, Clojure, Python, Ruby, XML, JSON, MongoDB and whatever web framework is currently in vogue.

Of course, at the end of the day it will be the engineers' fault ... which fails to address the issue of how such a system got signed off in the first place, let along from where came the requirements.

Furthermore I can imagine that testing was skipped or done badly because of a manager's false idea of what agile is...

So what we have here is a simple system that fails because of a misunderstanding of technology, non-functional requirements and most likely mis-management. I'd be willing to wager on that if we as engineers actually performed proper post-mortems or accident analyses on system failures instead of being forced to patch them up.

Ironically if they'd written in it COBOL it would all have worked fine... :-)