Agile is dead

This is an excellent post, though some might consider it a rant, about how Agile wasn't really nor became what Agile should it should have...

Agile is Dead

"Are you an IT consultant or contractor? Agile Software Development work is dead. If you practice that, you are a doorstop. If you manage that way, you are a boat-anchor. The wave has ended, it is over, and if you went for the head-fake and bought certifications, you wasted some money. Soon recruiters will be putting your resume in the circular storage container. I have been warning you for some time, and the day is here. Hah, you should have listened. Move along."

But here's the best quote:

The moral of this part of the story is that if you produce some compact politicised ideology (manifesto) consisting of principles and rules there will be unintended consequences.  Success creates a religion or cult, and defeat is being ignored.  No such doctrine is perfect.  Thinking you will change the world with a manifesto is naive, and if you succeed you may not have improved the world.

To me, given the problems that Privacy by Design has caused with privacy officers believing in some mythical "compliance" without any consideration of the software engineering or cultural aspects of developing information systems, this sums it up quite nicely!

Information wants to be free...?

I both like and dislike the quote "information wants to be free", mainly because it opens up a very nice philosophical discussion on what 'free' means but also because - and this is part I hate - it is some damned meaningless without any grounding in any form of semantics; and we've seen this before!

For the first part, this statement treats information in an anthropomorphic manner. Is it really information itself that has the need to be free? Let's assume that it does, though in a very fairy tale like way, it seems to me.

So let's then look at the word 'free', which I assume does not mean 'free' as in 'without cost' in the sense that someone has to pay for it. Though this is a curious idea in that information is somehow prostituting itself and despite all attempts someone (the information's pimp perhaps?) insists on controlling things. I guess this is the idea that information is going through some pre-1960's sexual revolution...

Rather I think the word 'free' refers to 'freedom' albeit in a Western sense of the word. Think of the use of the concept freedom as used in the US Declaration of Independence.

"We hold these truths to be self-evident, that all information is created equal, that it is endowed by its Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness"

...or should that be Existence, Communication and Semantics perhaps....?

Let's stick with the word 'freedom' and its naive or common-sense meaning. What does it mean to be free? We can turn further to the the UN Declaration of Human Rights and the EU Charter of Fundamental Rights for further clarification, though here I'm sure we go into more of a legal-political debate more than anything. Evidently freedom means either the right to do or be something or the right to be protected from something.

So the question is, if information want to be free:

• What does information want the freedom to do/be?
• What does information want the freedom from?

Under the first question, the freedom to be 'free' as in 'without cost' certainly falls. What about the freedom to be private, or the freedom not to be abused - as in excessive privacy violations? Do we further need a notion of agency - does information have an owner or provenance?

Without answering those - I don't think I can give a definitive answer anyway - here's another thought. Given that matter = energy, isn't the use of the term information quite literally another way of saying 'humans' (or 'men' as in the Declaration of Independence). In which case the question 'information wants to be free' is just an expression of man's desire to define what freedom is - ostensibly in terms of freedom to do/be and freedom from.

And here comes the practical part, which freedoms to do/be or from do we allow or deny in order to be "free"?

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.

Airmiles and Customer Service

I think we're all used to utterly rubbish customer service from airlines, especially if you have to fly in economy class. No food, no drink, Byzantine terms and conditions, cancellations and subsequent rebookings that cost money (!!!), cramped seating and paying for Wifi on board without refunds if it doesn't work. Oh and good luck if you want to speak to a human, either on the phone or at the airport

Some airlines still have a concept of customer service - SAS and Lufthansa as well as low cost challenger Norwegian at least treat passengers (sorry customers) with some degree of dignity.

I stopped flying Finnair years ago and switched my allegiance to Lufthansa and Norwegian, primary on price. When Norwegian want 600eur to fly a family to Gatwick from Helsinki while Finnair wanted over 2500eur (on a BA flight too!) with effectively the same ticketing terms and conditions. For long haul Lufthansa is my preferred airline - they serve wine and beer with the meal (all included in the price) and have the most professional and hard working cabin crew I've so far come across.

While none of the above are perfect - they could do a HUGE amount more to make the economy experience better - more on that another time.

But what really gets me is that if times are economically tough for airlines, how little they do to actually understand their customer. I mean I used to fly Finnair religiously - their customer service was excellent, food and drink on board, clean aircraft and you could change flights without being punished. Let's be honest here, Finnair were excellent, really, really excellent! I used to change whole itineraries to fly Finnair....

If you want customers then shouldn't you understand why customers aren't flying with you. Isn't this the whole point of customer loyalty programmes?

Below is my Finnair Plus statement - it's been that way for years and not once have I ever been asked why...

So privacy, security and other aspects aside, if you have a customer loyalty card of any sort and change your behaviour, eg: by stopping using that company's services and they never query why, then you were probably never getting any service anyway...

I used to have quite a tally of Finnair points, they all expired or were changed to some newer, more customer friendly scheme, for the benefits of the customer. I was never informed why or when, nor did anyone ever contact me about the change. For a customer loyalty programme you've got to admit that's pretty dire.

Forbes has quite a bit to say about this...

So, if you happen to work in the customer service dept of an airline and wish to discuss the above and how you can win me back as a customer, and a loyal one at that, let me know...

Happy Time Travelling Day

As today is the day when Marty McFly arrives in the future (or present as it is now - at least until tomorrow) I thought it might be fun to reference back to the only thing that makes Titanic a bearable film...the fact that it is a prequel to Terminator.

If Jack hadn't saved Rose then the ship would have turned around in search for her, thereby avoiding the collision with the iceberg...and all the things that would have entailed from that.

Obviously Jack's mission was to save Rose - presumably she's somehow related to Sarah Connor - and unfortunately 1500 people die in the collateral damage.

Don't believe me, go read the thread on Reddit 

I particularly like the idea that Jack is really The Doctor rescuing a relation to a future potential companion...Rose... :-)

Now scientists have searched for time travellers making comments on social media, apparently without success. But then again time travellers might have very strict rules about such things...as seen in the 1992 film Timescape.

However there is evidence that Twitter featured on the cover of Amiga magazine in April 1988! Well, not quite..but you never know...

Anyway, next week's lottery numbers are 4,7,14,19,22,34 ... I think, sorry can't read my handwriting...

...oh, and I shouldn't say this, but next week James Cameron told me last week he was a time traveller....

#ICanChangeThePast2
#ICannotChangeThePast2

Google Blogger and EU Cookie Laws

This is very kind of Google...providing you with an automatically generated privacy notice to European customers as detailed on the Blogger settings page:

This to me highlights a few problems with privacy laws and compliance:

• Firstly, you have to understand EU privacy laws
• You have to understand how to write such a notice
• You have to understand what systems such as Google Analytics etc actually collect and process.
• You might have to provide an opt-out mechanism such as Google's Analytics Opt-Out.

For 99.999% of bloggers (+/- a few %age points), I strongly doubt that any of this is understood or even known about at all.

So while Google might come in for some criticism for its dominance in the information gathering domain, they at least try to make things easier for their customers.

Then there's the EU Cookie Consent Kit which guides you through at least one part of the consent notice maze.

As an exercise, write a simple website...now work out what privacy notice you should display. Just to make it interesting, you are not allowed to have any contact with a privacy lawyer nor anyone who has a detailed knowledge about such things.

This quote by Einstein (often misattributed to Feynmann) sums up privacy laws and the average person writing a blog:

You do not really understand something unless you can explain it to your grandmother

Our privacy laws have become so complicated and often so misaligned with technology that they can not be easily understood by the average Internet user.

How not to collect data

Would you give your personal details to someone without knowing what they're going to be used for? How about if I said, "give me your name, email address and post code" and I'll make you a member of our exclusive most-favoured customer club? But, I'm not going to tell you what the terms and conditions are, how I'll use the data or even who I am except by vague implication in the latter case?

How about if I wrote the above on a piece of paper and left it on an official looking stand in a shop...yes?

Seen in a shop in Finland:

The text says:

Join now as a favoured customer and you'll hear always as the first about our fantastic offers and wonderful happenings. 

If you want to join as our favoured customer just fill this form with the needed information and hand it to the staff and we will take care of the rest. 

Name:_____________________________________________________
Email:_____________________________________________________
Postcode:___________________________________________________

I tried asking the store staff but they say it is a different company's problem and they have no idea of how the forms will be used. So far I've had no luck in contacting the company to which the forms probably belong...

Privacy Awareness Training (more thoughts)

I had the pleasure of presenting at the IAPP's DPIntensive workshop in London this month. After my session I got to talk with many about how to move privacy forward beyond an insular group discussion properly towards the engineers whose job it is to build the systems that implement these privacy rules.

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?

Primarily this is because awareness training is by its very nature very abstract at best and irrelevant at worst. Awareness training is also rarely followed up by more context relevant training, for example, for the software architects or programmers or marketers and so on.

There are various reasons for this, mainly, that to continue training in such a manner takes a great deal of effort to set up and comes with an interesting catch-22 problem: the privacy department/group/... probably doesn't have any engineers; which makes generating relevant training for engineers remarkably difficult.

Worse is that because of the current nature of privacy - it is primarily a legal discipline, albeit one trying to break through to engineering - very few engineers move towards or even into privacy.

One member of the audience at the DPIntensive workshop remarked on this stating that this was one of their biggest problems, especially as they had so much to learn from engineering.

The other major difficulty is that the structures that need to be put in place in order to translate between a legal discipline and an engineering one are undoubtedly complex. Consider a linguist trying to create a translation into an as yet not understood language: first one must understand the script, the syntactic structure and then the semantic ones - not to mention the whole problem of the pragmatic structures and idioms that exist before a degree of fluency is reached that makes translation or even basic conversation possible.

So, the problem with privacy awareness training is that it becomes almost impossible to follow up and continue beyond anything more than a broad, common denominator.

Such training however are fantastic for metrics ... make the training compulsory and you'll get 99% of the company taking the training - which normally lasts an hour, can be delivered by webcast or similar. Working with metrics and a delivery mechanism like that makes it an amazing vehicle for improving 'management' metrics. Which in this case are exactly the wrong metrics, at least from the point of view of the good of the company.

So next time you create a privacy awareness training consider :

• whether that training is aimed at a particular audience, or it is broad and generic
• how that training is to be followed up
• what effects do you expect to see
• measurement of must be made on what effects of the training actually went into practice

We can go further and ask what cultural changes happened due to the training, from the point of view of:

• the programmers
• the engineers
• the overall R&D
• the management
• the marketing department
• the legal department
• the privacy group

Unless all of the above can be answered then the privacy awareness training will have no overall or lasting effect.

Quote of the Day about Truth

Emile Zola:

 “If you shut up truth and bury it under the ground, it will but grow, and gather to itself such explosive power that the day it bursts through it will blow up everything in its way.”

Privacy and Governance

Actually this is a presentation by Prof. Alastair Scotland of the UK's NHS on governance and, ultimately, patient safety. If you work in governance, privacy, software engineering and any management discipline related with these then this is one video you must watch today.

If it took the NHS 10 years to get this far, then in areas such as privacy which share many of the same characteristics of being a flawed system (in the general sense) with many safety-critical features, we've a huge amount of work to do outside of the mainly philosophical and legal debates about what privacy is.


Alastair Scotland.mp4 from Guy Murray on Vimeo.

Semiotic Analysis of a Privacy Policy

Pretty much every service has a privacy policy attached to it; these policies state the data collection, usage, purpose and expectations that the customer has to agree with before using that said service. But at another level they also attempt to signify (that's going to be a key word) that the consumer can trust the company providing the service at some level. Ok, so there's been huge amounts of press about certain social media and search service provides "abusing" this trust and so on, but we still use the services provided by those companies.

So this gets me thinking, when a privacy policy is written, could we analyse that text to understand better the motives and expectations from both the customer and the service provider perspective? Effectively can we make a semiotic analysis of a privacy policy.

What would we gain by this? It is imperative that any texts of this nature portray the right image to the consumer, thus this can be used in the drafting of such a text to ensure that this this right image is correctly portrayed. For example, the oft seen statement:

"Your privacy is important to us"

is a sign in the semiotic sense, and in this case probably an 'icon' in its near universal usage. Signs are a relationship between the 'object' and 'interpretant', respectively the subject matter at hand and the clarified meaning respectively.

Pierce's Semiotic Trangle

The object may be that we (the writer of the statement) are trying to state a matter of fact about how trust worthy we are, or at least we want to emphasise that we can be trusted.

The interpretant of this, if we are the customer, can of course vary from total trust to utter cynicism. I guess of late the latter interpretation tends to be true. Understanding the variation in interpretants is a clear method for understanding what is being conveyed by the policy itself and whether the right impression is being given to the consumer.

At a very granular level the whole policy itself is a sign and the very existance of that policy and its structure, is it long and full of legalese or short and simple? Then there's the content (as described above) which may or may not depend upon the size of the policy....as in the World's Worst Privacy Policy.

References:

Andy Greenberg (2012) The World's Worst Privacy Policy. Forbes 25 Jan 2012.

Aside:

Found this paper while researching for this: Philippe Codognet's THE SEMIOTICS OF THE WEB, it starts with a quote:

I am not sure that the web weaved by Persephone in this Orphic tale, cited in exergue of Michel Serres’ La communication , is what we are currently used to call the World Wide Web. Our computer web on the internet is nevertheless akin Persephone’s in its aims : representing and covering the entire universe. Our learned ignorance is conceiving an infinite virtual world whose center is everywhere and circumference nowhere ...

Must admit, I find that very, very nice. Best I've got is getting quotes about existential crises and cosmological structures in a paper about the Semantic Web with Ora Lassila.

Fail fast, fail often, fail always

Apparently failing fast and failing often will lead to an eventual success, assuming of course that you are able to give the project or whatever it is time to develop and mature to a sufficient degree so that "failure" can be meaningfully assessed.

Failure does not necessarily mean that the project will not be a success, but rather that the technology, knowledge and product doesn't necessarily satisfy the current business goals. This is quite different from something that is a failure.

The mentality that everything should be an immediate success and that the smallest flaw is evidence of failure is killing not just research and innovation but the whole research and development process.

Furthermore the tendency to rapidly kill projects perceived to be failures without understanding what can be learned from those project and applied to bolster the next or parallel projects will eventually kill your business.

Innovation only comes from allowing scientists and engineers time to develop their ideas and not by rapidly killing those ideas before enough learning can be gained from them to benefit the overall business.

Indeed, if you do want to fail fast and fail often, ensure that you are learning from your mistakes and capitalising on the technologies and knowledge gained so that the fail often doesn't become fail always.

Understanding Software Engineering Accidents

The cause of 99.999...% of accidents is easy to ascertain, quite simply it is the pilot's/driver's fault. In the cases of two recent aviation and railway accidents (Asiana 214 and the Galicia's train crash) these were caused by the pilot and driver respectively....?

Finding the causes of an accident don't actually involve finding who is to blame but rather the whole context of what led up to the point where an accident was inevitable. And then even after that exploring what actually occurred during and after the accident.

The reasoning here is that if we concentrate on who to blame then we will miss all the circumstances that allowed that accident to occur in the first place. For example., in the case of the Galician train crash it has been ascertained that the driver was speeding, on the phone and had a history of breaking the rules. However this misses the more subtle questions of why did the train derail, why could the driver break the speed limit, what was the reasoning of the phone call, why did the carriages fail catastrophically after the derailment, did the safety systems work sufficiently, what state was the signalling in, did the driver override systems, was the driver sufficiently trained etc etc etc.

In other words, the whole context of the systems and organisation needs to be taken into account before appointing final blame; and even then very, very rarely is it single point of failure: the Swiss Cheese Model.

If we apply this model to software engineering and specifically accidents such as hacking and data breaches we become very aware of how many holes in our computing Swiss cheese we have.

Take a simple data breach where "hackers" have accessed a database on some server via an SQL injection via some web pages. If we apply our earlier thinking, it is obviously the fault of the 'stupid' system administrators who can't secure a system and the 'stupid' software engineers who can't write good code. Hindsight is great here isn't it?

To answer 'who to blame?' or better still 'why did things go wrong and how can we prevent this in the future?' we need to put ourselves, as other accident investigators do, in the position of those software engineers, system administrators, architects, hackers and managers AT THE POINT IN TIME WHERE THEY ACTED, and NEVER in hindsight.

Why did the trained, intelligent software engineer write code susceptible to SQLi in the first place?

Maybe they were under time pressure, no proper, formal design documentation, coding standards, never trained to spot those kinds of errors? Actually just stating that we have a failure of discipline is already pointing to wholesale failures across our whole organisation rather than just one individual.

Even if in the above case this was malice by the programmer, then why didn't the testing pick this up? Why was the code released without testing or checking? Now we have a failure elsewhere too.

Were there no procedures for this? Was the code signed-off by management with the risk in place? Now the net widens further across the organisation

and so on...

In aviation there is a term to explain most accidents: loss of situational awareness, which when explored invariably ends up with a multitude of 'wrong' choices being made over a longer period of time rather than just at those few critical minutes or hours in the cockpit.

I'm of the opinion that in software engineering that we almost always operate in a mode where we have no or little situational awareness. Our systems are complex, we lack formal models of our systems that clearly and concisely explain how the system works; indeed one of the maxims used by some practitioners of agile methods actively eschews the use of formality and modelling tools. Coupled with tight deadlines, a code-is-king mentality and rapidly and inconsistently changing requirements we have a fantastic recipe for disaster.

Bringing this back to an aviation analogy again, consider Turkish Airlines Flight 1951 which crashed as Schiphol in 2009. It was initially easy to blame the pilots for allowíng the plane to stall on final approach, but the whole accident investigation revealed deficiencies in the training, the approach procedures of Schiphol, a non-fault tolerant autothrottle and radar combination, a massively high workload situation for the pilots and ultimately a fault which manifested itself in precisely the behaviour that the pilots were requiring and expecting on their approach, that is the aircraft was losing speed.

As an exercise, how does the above accident map to what we experience every day in software engineering? Given high workloads, changing requirements, inconsistent planning and deadlines to get something (anything!) out that sort of works and we start getting answers to why intelligent administrators and programmers make mistakes.

Privacy, Continuity and Performance...

Of the "big four" non-functional aspects of a system: security, privacy, continuity and performance, typically privacy and security are viewed together; there is no doubt about their relationship.

The relationship between privacy (more generally information management) and continuity and performance is much more subtle. Certain decisions in these areas have an effect upon the information management aspects. Consider a piece of middleware that for both continuity and performance reasons

1. batches incoming data (for later processing or sending to some other system)
2. caches authentication data (for "fast(er)" login)

Both require data to be held for a certain period of time and data to be removed. There are also implications for the storage of that data in terms of whether it is secured through some means (eg: encrypted file system, database, fields...) and the internal processing and communication mechanisms.

We are primarily concerned with minimising the amount of data held and avoiding a single point of failure which would allow access to all the data. We have three basic options:

The monolithic system has potentially greater performance characteristics, but less so with regards to continuity and privacy - these latter two having a single point of failure. The facade while providing a single API decreases the performance but potentially facilitates better continuity through decoupling internally the authentication and data-handling and the decoupled system places much more responsibility onto the client for handling the correct calling sequences but better deals with privacy by reducing the amount of available data via any one API and component.

However as we decouple the system we increase the amount of inter-component communication and introduce a different set of information management and continuity issues, such as securing these data-flows and the leaky abstraction of network/communication failures.

The point here is not to provide a definitive answer of whether one solution is better than another but to emphasise the subtle interaction between privacy, continuity and performance in differing architectural solutions.

Kubler-Ross and Getting Ideas Accepted

When discussing new or challenging ideas, or even anything that challenges or even questions the existing schools of thought (or business process!) there is often much "push-back" with responses such as "that'll never work", "impossible" etc...sometimes even when confronted with the evidence and demonstration.

Dealing with this is often soul destroying from the innovator's perspective and getting past this is 90% of the challenge of getting new ideas and view points accepted. So having a mechanism to understand the responses would be useful. I think the Kubler-Ross model might be useful here to examine people's responses.

The model itself was developed for psychologists to understand the process of grief. While the model has sparked some controversy, this does not detract from the basic principle of the model. The model consists of five sequential stages:

1. Denial - "we're fine", "everything works"
2. Anger - "NO!"
3. Bargaining - "Ok, so how do you fix this?"
4. Depression - "Why bother...?", "Too difficult"
5. Acceptance - "Let's do this!!!"

When applied to challenging ideas, the person rejecting those ideas has to proceed through the above stages - and the challenger has to also acknowledge this and work within this.

Let's say we have a process and metrics for some purpose - the process is complicated and dogmatic, the metrics measure some completion rate but not effort or compliance. A challenge to this might be met with the following responses:

1. Denial - the process works! No-one has complained! We have metrics! We're CMM Level 3!
2. Anger - Why are you complaining? We don't need to change!
3. Bargaining - OK, we'll consider your ideas and changes but we're not promising anything. Can you come up with a project plan, budget, strategy, PowerPoints etc...?
4. Depression - OK, there are problems, but we can't deal with them. It's too late and complex to change. Let's create a project plan, strategy and vision. How can we ever capture those metrics?
5. Acceptance - You're right, let's run with this

Actually the last state - acceptance - probably works very well in a more agile environment, but agility requires both a deep and holistic and ultimately an approach grounded in the theory of the subject at hand. Do not underestimate getting management support either, and conversely as a manger giving real support is similarly critical.

This model must be used in an introspective and reflective manner to ensure that you as the originator and presenter of the idea do not fall into the trap of stages 1 and 2 yourself. Understanding your reactions in the above terms is very enlightening regarding your own behaviour.

If you do reach stage 3 in the discussions then this is time that you need to be absolutely sure in how your idea works, what the flaws are and how it integrates and improves what came previously. At this stage you have the chance to get everyone on board but after this however it is extremely difficult to turn people to your idea.

Stage 4 is depression all round, you will probably have accepted many changes to your idea and let go of some cherished ideas. Worse is that you've probably challenged the existing school and dogma to such a degree you are going to get a lot of "push back" on the ideas. In some respects this is where ideas do die either "naturally" or through "suicide" to use some dark terminology. To get through this stage you need to be the supporter of everyone. Indeed emphasis on the previous school of thought as being the catalyst to the newer ideas is critical to get through this; after all, wasn't it the previous systems that sparked the need for change in the first place?

Stage 5 is requires real leadership of the innovation and building of the team to carry this forward. Like it not, teamwork and ensuring that everyone, even the detractors, have a voice is critical. Sometimes your challenge might free some of the original detractors out of their earlier beliefs - this can come as quite a relief to these people and offer them badly needed, new challenges and purpose.

There are many more things one could write on this and there are many books and theories on how to manage innovation and invention elsewhere. The idea here was to relate some experiences with the Kubler-Ross model and understand things in that context, which personally I've found to be a very useful tool.

Semantic Isolation and Privacy

Somewhat side-tracked in writing these (pt1, pt2, pt2.5) and thinking about how best to explain some of the issues, especially when getting to the deeper semantic levels. However a work discussion about Apple and Amazon's security flaws and the case of Mat Honan provided an interesting answer which I think describes the problem quite well.

In the above incident hackers used information from Amazon to, primarily, social engineer Apple's customer service into believing that the hackers were Mat Honan. From the Wired article (linked above and [1]), Honan provides the quote:

But what happened to me exposes vital security flaws in several customer service systems, most notably Apple’s and Amazon’s. Apple tech support gave the hackers access to my iCloud account. Amazon tech support gave them the ability to see a piece of information — a partial credit card number — that Apple used to release information. In short, the very four digits that Amazon considers unimportant enough to display in the clear on the web are precisely the same ones that Apple considers secure enough to perform identity verification. The disconnect exposes flaws in data management policies endemic to the entire technology industry, and points to a looming nightmare as we enter the era of cloud computing and connected devices.

Both accounts at Apple and Amazon have a user identifier and passwords; they also have a set of other criteria to establish whether a given human is who they say they are. In Amazon's case they ask for email, address and the titles of some books you've bought from them - at least last time I called. In Apple's case it looks like they wanted some more personal information, in this case the "least significant digits" of a credit card number. I say least significant because these particular digits are often printed in plain text on receipts. As far as Visa, MasterCard, Diners etc consider, these digits have no meaning - though I have an issue with that as we shall see.

In Amazon's context the data about a user is semantically isolated from Apple's context. This is a level deeper than saying that they both had user identifiers but to what Real World concept and instance those identifiers meant and represented. The trouble here started when the realisation was made that the instance that the Amazon identifer related to could be the same as the thing that the Apple identifier related to, in this case the Real World Mat Honan. To make this complete it also turns out that the meaningless four least significant credit card digits in Amazon's context were the proof of identity in Apple's context.

We can argue that the data and identity management procedures in both cases were at fault, however in analysis this was actually hard to see: How could 4 random digits, effectively uniquely identify a person and without an understanding of each other's semantic view of the world, who would have realised?

The whole hack described in Mat Honan's article goes into a lot more detail on how this information was found out. Indeed much of the information required is already public and it is just a case of putting all this together and effectively using that to make a consistent profile.

As for credit card numbers, the practice of displaying the final four digits or the "least significant digits" in certain semantic contexts is called PAN truncation. However as the whole number has a well defined structure (ISO/IEC 7812), check summing and only a limited number of options for the rest of the digits is becomes feasible to reconstruct much of the number anyway, especially as some receipts also print the card type - at least enough to sound convincing in a social engineering situation if necessary. Furthermore as described in the article faking credit card numbers because of their structure actually now becomes a method of generating data to prove identity in some cases. In summary, there are no "random digits" or "least significant digits" in a data structure with particular meanings associated with each part of that structure.

The situation gets worse when more information can be provided for the social engineering exercise: for example, in Finland it used to be common before chip and pin terminals for a shop cashier to ask for identity, where the customer would show a "valid identitiy document" (this varied by cashier, shop and day-to-day in some cases) and certain details would be written down: usually the last four (least significant aparently) digits of a Finnish social security number or a whole passport number plus other varied details depending upon the shop and phase of moon etc.


References

[1] Mat Honan. 2012 How Apple and Amazon Security Flaws Led to My Epic Hacking. Wired Aug 6, 2012

Semantic Isolation (Pt.2)

As discussed in part 1, we identified problems with the definition of data siloing resulting from the proliferation of individual service, app etc specific database. 

These siloed databases have massive amounts of overlapping content but generally can not be semantically matched and used together. This is preventing consolidation and unification of the data which then leads not only to more proliferation and irreconcilable duplication of data but also actively prevents more expansive application and analytics of that data to be created.

To start solving this data siloing problem we investigate, initially, two aspects to enable de-isolation of data:

• linkability of identifiers
• interoperability of semantics

In this posting I'll concentrate on identifiers and discuss semantic interoperability in a later part.

Identifiers really mean the primary keys used over the plurality of sioled data sets. These come in a number of forms: user IDs, email (typically as username), device IDs, session IDs etc as well as encrypted, hashed and processed versions of these. Additionally structured or compound variants add to the complexity.

As a privacy person I could also mention so called anonymous data sets where identifiers can be inferred from other properties such as consistent locations over the data - something I tend to explain as the "2 location problem" where no personal identifiers are stored but a number of locations, eg: start and end points in navigation routes could be used as inferred identifiers.

Aside: Making this more interesting is profiling based upon a deeper, more semantic investigation on the contents irrespective of the key or identifier present in the database, cf: AOL search logs. We do not discuss this here at this time.

The main problems regarding linkability are:

• ·         the semantics of the identifier
• ·         the structure of the identifier
• ·         the representation of the identifier

The semantics of an identifier relate to which concepts that identifier represents. Taking unique user identifiers, for example, usernames, we need to understand how these relate to a person. It is often taken for granted that that user identifier equals unique person. Similarly with device identifiers and addresses such as IP addresses being equated with a single machine.

For example, we might have a structured or compound identifier containing a user ID which is matched against one device ID which is further composed of individual session IDs. We might also form a view of the real-world as shown in green. The red dashed lines show how we relate our identifier concepts with real-world concepts.

Note how what we a seemingly simple mapping now be complicated by other factors such as whether the device ID identifier refers to something the identifier user owns or uses. There is also an interesting mismatch between the multiplicities in the identifier structure and the real-world. We can argue that the above is a poor model of the real-world, but it serves the purpose to focus discussion on what we want the identifiers to actually identify.

Identifying the real-world concepts and then understanding how the identifiers’ semantics are grounded in these gives us our first clue into what can and cannot be successfully unified. This process has to be repeated for each individual data set or asset being considered and assurance sought that the semantics or real-world mappings do coincide sufficiently such that we can be sure that the pairs of identifiers are really referring to the same concepts, ie: they are both identifying the same things at the same level of granularity.

The structure of the identifier refers to whether that identifier acts as a compound key. Typically often seen is a mix of, say, user identifiers, device identifiers and session identifiers. While we might have identified a mix of many-to-many relationships between the real-world concepts, at this level we start to see some kind of invariants over that structure. Ideally this should refine the space of configurations of identifiers to real-world concepts.

Additionally we also have to look at the temporal aspect of the identifiers: does there exist a strong compositional structure versus a looser aggregate structure over time?

Note that we actually encounter the structure when working out the semantics, we present it second however to emphasise concentration on the semantics of the identifiers not their internal construction.

The representation of an identifier can cause some problems and we particularly refer here to obfuscated identifiers that have been transformed using hashing or encryption. Encrypted identifiers can always be reversed to reveal their original forms whereas cryptographic hashing is one-way. The latter should always be used with a suitable salt to add randomness to the hash. Doing this may turn an identifier into a kind of session identifier rather than one that identifies a real-world person or device – this depends greatly upon any regeneration.

When dealing with hashed identifiers we will find partial matches, typically when working with session identifiers. This leads to various questions about anonymity, especially when we can match the contents of the partial identifiers to "accidentally" reveal more of the structure. At worst we can limit the isolation of a data silo, at least to some internal level, for example, device or session only rather than a specific real-world person.

One might argue that we have addressed our concerns in some kind of reverse order; starting with semantics. However the key to understanding any information system is to understand what real-world concepts that information system is actually modeling and working “backwards” gives us the framework in which to perform our analysis of the linkability of identifiers.

Once identifiers in two data set or assets have linked based upon the correspondence of their representation, syntax and semantics then we have the initial unification.

Google Wardriving, Wifi, Privacy and an Engineer to fault?

Information Week has an article about Google collecting Wifi identifiers and snooping on unencrypted traffic over people's networks:

Google Wardriving: How Engineering Trumped Privacy

Blame the Street View data collection practices on a "more is more" engineering mindset. And rethink your notions about privacy for unencrypted Wi-Fi data.Mathew J. Schwartz | May 01, 2012 10:50 AM

During a two-year period, Google captured oodles of Wi-Fi data worldwide as part of its Street View program. But why? 

Blame the engineering ethos that's prevalent at high-technology companies like Google. You know the "more is more" mindset: more bells and whistles equals greater goodness. 

But an unfiltered engineering mindset would help explain theapparent thinking behind the Street View wardriving program: "Well, if this Wi-Fi data is flying around and no one is encrypting it, what reasonable expectation do they have that it won't be sniffed and stored?"

This whole episode is starting to look like it is just about finding a suitable scapegoat whereas in reality the failures were multiple and in this instance happened to line us, cf: the Swiss-cheese analogy used in aircraft accident investigations.

I strongly doubt a "rouge engineer" was responsible - it takes many engineers to build and deploy these systems (look at the average size of an R&D team in most larger companies and the process/personnel infrastructure surrounding those). Now, admittedly it is possible that this code was added by a single engineer but do Google really have such lax software engineering practices?

R&D teams are under pressure to collect as much information as possible from applications and services, or, have the ability to collect and collect just in case. Mechanisms to collect WiFi data and snoop on the contents are easily available and part of the usual networking infrastructure tool kits - they need to be otherwise the features you rely upon in your operating systems etc wouldn't work.

According to reports the engineers asked for help from legal; in which case we have two points of failure, one that the engineers might have been asking the wrong questions and that legal didn't understand or respond. The failure might also have been at product/programme management level which might have blocked these requests or overridden them. It might just have been that engineering and legal acted correctly within the context of working in Google.

The statement in the Information Week article "an unfiltered engineering mindset would help explain the apparent thinking" is extremely misleading - the failures are multiple and most likely actually don't just involve engineering at all - the real blame is most likely elsewhere: product, programme management?

Also, even if Google have taken the so called Privacy-by-Design [1] ideas on-board, their communication and implementation might be very different from what is intended. As a similar example, Agile Methods have a similar set of statements and their implementation in many cases is grossly misunderstood (at best).

While statements of principle like PbD or even the Agile Manifesto [2] are fine, their implementation both technically and within the culture of the company as a whole are neglected at best and utterly misunderstood at worst. In here lies the real problems...unfortunately therein lies too many hard questions: changing a culture whilst maintaining maturity of method and process is hard.

I was also wondering about the title of the article "Engineering Trumped Privacy" and though it both misleading and somewhat offensive (to engineering), however the meaning of the work "trumped" can be taken in a slightly different way to mean "engineering exposed flaws in the overall implementation and understanding of privacy".

Finally, I do think the statement "never attribute to malice what can be explained by stupidity" applied here. At various levels in Google I don't think there was any intention of doing anything "bad", but for a company that tells everyone else not to be evil, malice does seem a logical choice fuelled by whatever conspiracy theory you choose.

Just like a pilot is "always" at blame in an aircraft crash, I wonder how Marcus Miller is feeling today...

References

[1] http://www.ipc.on.ca/images/resources/7foundationalprinciples.pdf

[2] http://agilemanifesto.org/

Privacy, Dataflow and Nissenbaum ... formalisation?

I read the article by Alexis Madrigal of The Atlantic about Helen Nissenbaum's approach to privacy. It is good to see someone talking about sharing of information as being good for privacy. Maybe this is one of the rare instances that the notion of privacy has been liberated from being all about hiding your data, protecting the "consumer" to actually, in my opinion, being about how data flows.

To quote from the article and given a good example:

This may sound simple, but it actually leads to different analyses of current privacy dilemmas and may suggest better ways of dealing with data on the Internet. A quick example: remember the hubbub over Google Street View in Europe? Germans, in particular, objected to the photo-taking cars. Many people, using the standard privacy paradigm, were like, "What's the problem? You're standing out in the street? It's public!" But Nissenbaum argues that the reason some people were upset is that reciprocity was a key part of the informational arrangement. If I'm out in the street, I can see who can see me, and know what's happening. If Google's car buzzes by, I haven't agreed to that encounter. Ergo, privacy violation.

First thing here is that Nissenbaum gets us past the privacy as a binary thing: its private or public where private means hidden. Nissenbaum actually promotes the idea of how we perceive the data flow rather than whether something is private or public; again quoting from the article:

Nissenbaum argues that the real problem "is the inapproproriateness of the flow of information due to the mediation of technology." In her scheme, there are senders and receivers of messages, who communicate different types of information with very specific expectations of how it will be used. Privacy violations occur not when too much data accumulates or people can't direct it, but when one of the receivers or transmission principles change. The key academic term is "context-relative informational norms." Bust a norm and people get upset. 

For a while I've been working on formalising architectures, ontologies, taxonomies and so on for privacy (privacy engineering) - the common factor in all of these is the data-flow. Actually I think some of this is quite simple when thought of in this manner, firstly we construct a simple data-flow model:

Aside: this is quite informal and the following just sketches out a line of thinking rather than being a definition.

Some information I flows from A to B. For this information I we can extract a number of aspects: sensitivity, information type, identity (amount of) etc. We can also ask the question of this particular interaction (A,I,B) of whether that information I is relevant to the particular set of transactions or services that B provides. If B requires a set of information H to work for fulfil the contract with A then I<=H in this case, which allows A to supply less but should discourage B asking for more.

We can also look at other factors in this to make that decision: the longevity of information in B, the ownership of the information once passed to B and importantly, whether B passes this information on - we come to this latter point later. Ultimately we can assign a weight to this data-flow, though what form of metric this is I don't have a good idea about at the moment but let's call it 'm', ie: a(I) is some measure of the 'amount of information' weighted by the various aspects and classifications. The above I<=H should then be rewritten as a(I)<=a(H) which better takes into account of the weightings of the information classifications.

This we can continue through a number of other flows and introduce a typing or taxonomic structure for the nodes:

As B is a bank then the amount of information required tends to be high, if C is on-line shop, then this tends to be lower and so on. Such a rule might be:

forall u:User, b:Bank, c:OnlineShop, d:NewsSite |
    a( u-->b ) => a( u-->c ) and
    a( u-->c ) => a( u-->d )
    ...

For each node, we can better describe the expectation in terms of this metric, ie: a(b) where b is the Bank node from above, we get the rule from earlier:

forall u:User, b:Bank |
    a( u-->b ) <= a(b)

Now our weighting function a deals with particular instances, where as we have stated that that there are expectation, so let's introduce a new function that computes a range for a given type, for example r(Bank) returns a range [ r_min, r_max ]. Then for a particular instance of Bank we get

forall b:Bank |
      r_min(Bank) <= a(b) <= r_max(Bank)

If a given instance, for example e in the above data-flow requires something outside the range for its type then we are "busting a norm" for that particular type, and following on from the above rules:

forall u:User, b:Bank |
      r_min(Bank) <= a(b) <= r_max(Bank)
         and
      a( u-->b ) <= a(b)

The next thing is to look at the next level in the data-flow graph, to where do B,C,D and E send their information, how much and how do these data-flows affect the first - I guess there's a very interesting feedback loop there. A few other things spring to mind as well: do we see a power law operating over the weighting of the data-flows? Does it matter to where and how much data flows?

Introduce a temporal dimension and plot the above over time and you get a picture of the change in norms and consumer expectations.

Getting back to Nissenbaum's thesis which is that the expectation of privacy over data-flows is the key and not whether the data-flows at all, I think we could reasonably model this.

Unintended Consequences in Academia

Found this via a posting on Facebook; a very interesting look at the unintended consequences of trying to measure the output of academics, and just like any other metric the issues that come up on how that particular metric gets misused. Sort of reminds me of the classic software engineering metric leading to bonus payments: bug fixing....

Perverse Incentives in Academia

 In particular I quite like these two:

Researchers rewarded for increased number of citations.

Researchers do work that is relevant and influential.

H-index obsession; list of references no longer included in page limit at many conferences.

Teachers rewarded for increased student test scores.

Improve teacher effectiveness.

Teaching to the tests; emphasis on short-term learning.

Of course, one issue here is that you are trying to measure some seriously intelligent people and here's a very good discussion on managing intelligent people by Scott Berkun - I'm not sure he has all the answers but just acknowledging this is a step to proper understanding.

Finally, a nod to that classic tome of unintended consequences (and the economic theory that drives this): Freakonomics by Levitt and Dubner.