Monday, 17 November 2014

A Definition of PII and Personal Data

There's been an interesting discussion on Twitter about the terms PII and "personal data", classification of information and metrics.

Personally I think the terms "PII" and "personal data" are too broadly applied. Their definitions are poor at best; when did you last see a formal definition of these terms? Indeed classifying a data set as PII only comes about from the types of data inside that data set and by measuring the amount of identifiability of that set.

There now exists two problems in that a classification system underneath that of PII isn't well established in normal terminology. Secondly metrics for information content are very much defined in terms of information entropy.

Providing these underlying classifications is critical to better comprehending the data that we are dealing with. For example, consider the following diagram:

Given any set of data, each field can be mapped into one or more of the seven broad categories on the left - If we wanted we could create much more sophisticated ontologies to express this. Within each of these we can specialise more and this is somewhat represented as we move horizontally across the diagram.

Avoiding information entropy as much as possible, we can and have derived some form of metric to at least assess the risk of data being held or processed. A high 'score' means high risk and a high degree of reidentification is possible, while a low score the opposite - though not necessarily meaning that there is no risk. Each of the categories could be further weighted such as using location is twice as risky as financial data.

There could be and are some interesting relationships between the categories, for example, identifiers such as machine addresses (IPs) can be mapped into personal identifiers and locations - depending upon the use case.

I'm not going to go into a full formalisation of the function to calculate this, but a simple function which takes in a data set's fields and produces a value, say in the range 0 to 5 to state the risk of the data set might suffice. A second function to map that value to a set of requirements to handle that risk is the needed.

What about PII?  Well, to really establish this we should go into the contents of the data and the context in which that data exists. Another, rather brutal way, is to draw a boundary line across the above diagram such that things on the right-hand-side are potentially PII and those on the left not. This might then become a useful weighting metric, that if anything appears to the right of this line then the whole data set gets tagged with being potentially PII. I guess you could also become quite clever in using this division line to normalise the risk scoring across the various information classifications.

In summary, we can therefore give the term PII (or personal data) a definition in terms of what a data set contains rather than using it as a catch-all classification. This allows us then to have a proper discussion about risk and requirements.

References

Ian Oliver. Privacy Engineering: A Data Flow and Ontological Approach. ISBN 978-1497569713


Tuesday, 11 November 2014

First International Workshop on Privacy Engineering (IWPE'15)

CFP:
First International Workshop on Privacy Engineering
(IWPE'15)


21 May 2015 - The Fairmont, San Jose, CA 



IMPORTANT DATES:
Deadline of paper submission:  23 January, 2015
Notification of acceptance:    16 February, 2015 
Accepted Paper camera ready:   3 March, 2015  



We are pleased to invite you to participate in the premier annual event of the International Workshop on Privacy Engineering (IWPE'15).

Ongoing news reports regarding global surveillance programs, massive personal data breaches in corporate databases, and notorious examples of personal tragedies due to privacy violations have intensified societal demands for privacy-friendly systems. In response, current legislative and standardization processes worldwide aim to strengthen individual’s privacy by introducing legal and organizational frameworks that personal data collectors and processors must follow.

However, in practice, these initiatives alone are not enough to guarantee that organizations and software developers will be able to identify and adopt appropriate privacy engineering techniques in their daily practices. Even if so, it is difficult to systematically evaluate whether the systems they develop using such techniques comply with legal frameworks, provide necessary technical assurances, and fulfill users’ privacy requirements. It is evident that research is needed in developing techniques that can aid the translation of legal and normative concepts, as well as user expectations into systems requirements. Furthermore, methods that can support organizations and engineers in developing (socio-)technical systems that address these requirements is of increasing value to respond to the existing societal challenges associated with privacy.

In this context, privacy engineering research is emerging as an important topic. Engineers are increasingly expected to build and maintain privacy-preserving and data-protection compliant systems in different ICT domains such as health, energy, transportation, social computing, law enforcement, public services; based on different infrastructures such as cloud, grid, or mobile computing and architectures. While there is a consensus on the benefits of an engineering approach to privacy, concrete proposals for processes, models, methodologies, techniques and tools that support engineers and organizations in this endeavor are few and in need of immediate attention.

To cover this gap, the topics of the International Workshop on Privacy Engineering (IWPE'15) focus on all the aspects surrounding privacy engineering, ranging from its theoretical foundations, engineering approaches, and support infrastructures, to its practical application in projects of different scale. Specifically, we are seeking the following kinds of papers: (1) technical solution papers that illustrate a novel formalism, method or other research finding with preliminary evaluation; (2) experience and practice papers that describe a case study, challenge or lessons learned from in a specific domain; (3) early evaluations of tools and other infrastructure that support engineering tasks in privacy requirements, design, implementation, testing, etc.; (4) interdisciplinary studies or critical reviews of existing privacy engineering concepts, methods and frameworks; or (5) vision papers that take a clear position informed by evidence based on a thorough literature review.

IWPE’15 welcomes papers that focus on novel solutions on the recent developments in the general area of privacy engineering. Topics of interests include, but are not limited to:

  • Integration of law and policy compliance into the development process
  • Privacy impact assessment
  • Privacy risk management models
  • Privacy breach recovery Methods
  • Technical standards, heuristics and best practices for privacy engineering
  • Privacy engineering in technical standards
  • Privacy requirements elicitation and analysis methods
  • User privacy and data protection requirements
  • Management of privacy requirements with other system requirements
  • Privacy requirements operationalization
  • Privacy engineering strategies and design patterns
  • Privacy architectures
  • Privacy engineering and databases
  • Privacy engineering in the context of interaction design and usability
  • Privacy testing and evaluation methods
  • Validation and verification of privacy requirements
  • Engineering Privacy Enhancing Technologies
  • Models and approaches for the verification of privacy properties
  • Tools supporting privacy engineering
  • Teaching and training privacy engineering
  • Adaptations of privacy engineering into specific software development processes
  • Pilots and real-world applications
  • Privacy engineering and accountability
  • Organizational, legal, political and economic aspects of privacy engineering


This topic list is not meant to be exhaustive; since IWPE'15 is interested in all aspects of privacy engineering. However, papers without a clear application to privacy engineering will be considered out of scope and may be rejected without full review.



PAPER FORMAT & SUBMISSION

We solicit unpublished short position papers (up to 4 pages) and long papers reporting technical, research or industry experience (up to 8 pages) on all dimensions of the privacy engineering domain. Each paper, written in English, must follow IEEE Proceedings format. Submission of a paper should be regarded as an undertaking that, should the paper be accepted, at least one of the authors will attend the workshop to present the paper. All papers must be submitted via EasyChair at https://www.easychair.org/conferences/?conf=iwpe15

All IWPE'15 Papers will be published in IEEE eXplore, which is indexed by EI Engineering Index, ISI Conference Proceedings Citation Index (CPCI-S), Scopus etc.



If you have any questions regarding IWPE'15, please contact:

Jose M. del Alamo (jm.delalamo@upm.es)
Norman Sadeh (sadeh@cs.cmu.edu)
Seda Gurses (seda@nyu.edu)
Dawn Jutla (dawn.jutla@smu.ca)

Spam and Category Theory

A long time ago I came across an interesting article on the n-Category Cafe about a presentation by Fernando Zalamea on Sheaf Logic and Philosophical Synthesis.

For some reason over the past week this blog has been inundated with requests to the page I wrote on this - basically a reminder for myself to read up on this work.

I happy with a few tens of hits to this blog per day, but yesterday's 135 hits to that one page all came from the home of philosophy: France. So a merci to those who found a way to this blog and maybe onto Zalamea's original presentation - glad to be of assistance.

Part of me is delighted by the collective interest in this topic, while part of me suspects that this is spam.

Hmmmm....

Thursday, 30 October 2014

Finnish Literature

I got a request the other day for a or a few quintessential Finnish books, those that capture the Finnish psych or those that have stood the test of time and become the books of the nation. While you might consider the national epic The Kalevala, it would actually miss the point in that it needs to have author, style and content to qualify.

Actually qualifying the criteria is almost impossible so it is a lot easier to specify the books by example and the quality properties be extracted or inferred from those.

There are three books:
Translations in other languages are available.

Tuesday, 28 October 2014

Interview on KUCI 88.9FM

I've been interviewed by Mari Frank of the Privacy Piracy programme broadcast on Irvine (California) based radio station KUCI 88.9 FM.

Available via the KUCI website and on iTunes

Protect Your Privacy in the Information Age
Now on every MONDAY morning from 8:00 AM - 8:30 AM, Pacific Time
on 88.9 FM in Irvine
and WORLDWIDE live audio streaming at www.kuci.org

I talk about privacy engineering, my book and some topics related to the adoption of engineering practices in privacy. The show will be broadcast on November the 3rd and please refer to KUCI's programme listings for more information.

I guess this is the nearest I'm going to get to Hollywood.

Monday, 13 October 2014

Whiskeygate

No one is really sure who said what and the air is full of denials and the Nuremberg Defense, but it seems like Finland is trying to suppress the word "wisky", or more specifically the Finnish "viski" just in case it corrupt, well, everyone....just think of the children...or maybe it is for my safety and security...but even if it saves just one person...

Yes, this is true:


News  |  
HS: Finnish officials ban the word "whisky" on private blog 
Organisers of a beer and whisky fair in Helsinki have been granted a license on condition that search engines do not link to the event’s website when users search for “whisky”, according to a report in Helsingin Sanomat. The officials have also asked the beer and whisky fair to remove the word “whisky” from their logo and the event’s official name.

Anyway Finnish taxes being put to work by our elected and unelected officials...good thing there's nothing else to worry about such as the economy, jobs, overly high taxation, food prices, energy prices, energy dependence, flying squirrels, child benefit reductions hirvikarpaset and a government that wants to avoid all hard decisions at all costs.

After all, banning words, moving kunta boundaries and pay rises of 6000 euros per month are far more important than the people of Finland.

Can anyone say Streisand Effect?

Whisky, Whiskey, Viski, Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski,Whisky, Whiskey, Viski ....

Thursday, 9 October 2014

Privacy Awareness Training

Awareness of the implications of information loss, data breach and privacy in general is well known, though interestingly rarely acted upon in general practice. Consider the situation I've just witnessed: someone talking loudly in a Skype conversation about some very personal details of his life, plus the odd snipped of financial information and a few names, in a coffee shop - and a relatively crowded coffee shop at that.

We actually spend a disproportionate amount of time worrying about technical solutions to privacy and yet while we are told every day about the dangers of using our technological goodies: phones, laptops, tablets etc, we seem almost oblivious about the data leakage we commit even without technology. Or maybe in the case of a video call in a crowded coffee shop, with the help of technology.

We probably panic more about sharing pictures on Facebook than exposing all our personal details in public in the manner above.

I'm also reminded of any case that happened in the UK. A man - a parent of a child at the school - was prevented taking his DSLR camera to a school sports day on grounds that he might accidentally take pictures of other children with the camera. As we all know, a big expensive camera takes good pictures. Ironically every other parent took a mobile phone - most with just as good picture resolution as the DSLR and most likely all capable of upload to various social media sites along with the all precious meta-data: location, time stamps etc. Just to add irony here he probably had a telephoto lens so that he could take a picture of just his child...you might like to compare the capabilities of a telephoto lens with that of a camera phone. Further irony comes from the fact that how many picture were uploaded with the childrens' details to social media during and after the event without the permission of all present.

Let's us not forget the fact that an internet connected (or should I say radio network connected) mobile device is already exposing much more information than a non-network connected DSLR camera every will or can. I note in Canon's latest models this however is changing...

Buy hey, let's not let common sense and knowledge get in the way of blind panic and misunderstandings.

Let's for a moment concentrate on opposite end of the privacy spectrum, that of the software engineer or programmer trying to construct a system that processes data. For the most part these engineers receive very little in the way of specific training on algorithms, techniques etc for privacy and information processing in general.

When did you last educate your programmers and engineers on the latest data processing or security techniques?

So this brings me to the state of privacy awareness training. Most companies now mandate this for their employees and mandated training normally has a very high view rate. What is less understood is the amount of understanding gained or relevance from this training. In fact privacy awareness training is rapidly becomming the new sexual harrasment training: watch this 1 hour video and reverse 100s of years of cultural indoctrination and be reborn into a new egalitarian society...wow!

And this is one of the problems of privacy awareness training, that a short, generic introduction to the dangers of information loss and privacy magically solves everything. I am sure that many of the companies that have suffered data breaches of late have such training in place. Even the NSA surely has such training, though the outcome after this education is now well known.

One could enter into a huge sociological and cultural discussion about this, but one thing has always struck me about privacy awareness training:

It caters for the lowest common denominator

Awareness training invariably tells me of the dangers of information breaches, maybe some interesting anecdotes about Target, AOL, NSA etc, the dangers of the internet etc.

It never tells me about programming techniques, system design techniques, practical methods of protecting my email, social media use, the differences between DSLRs and mobile phones etc.

In a nutshell, privacy awareness training is rarely, if ever, relevant to the audience. By making privacy awareness training so generic it actually never properly educates the audience about privacy and information security.

Constructing training that properly addresses each of its target audiences is hard and takes time - that is not to be denied - but we can not continue with generic, information content-less material that while is tells about privacy, it does not educate.

Anyway, the man opposite me is continuing with a call to his therapist/lover...he's been through rough time recently it seems, and it is good to talk...about your religious beliefs, former marriage, your views on men/women/relationships, your friends, your financial situation etc...

Tuesday, 30 September 2014

Wither the Privacy Hero...

The Hero in computing is a well known phenomena - think of the lone programmer, sysadmin or hacker for example. However the hero also occurs in all domains including privacy. The privacy hero is the one who has hand crafted the privacy policy, set down in stone a lengthly list of privacy requirements and compliance activies without consulting the engineers and users who have to implement and use these.

As many disciplines, especially that of medicine, have discovered, the hero is the most dangerous person there is. By working against the odds, he (or she) usually creates a victory where all is solved [1]. Be it uring a patient or creating the rules by which the company is saved from an inglorious admission of a data breach. Even if there is a breach or the patient later dies, it can't be the hero's fault, but the others such as the failed care of the nurses or the engineers who never listened. In reality the nurses and the engineers are usually patching the damages caused by the hero.

Our current cultural setups in privacy, and especially now we're starting to get engineers actively involved in the privacy debate, needs to change from the Privacy Heros to a much tightly integrated team of experts.

In [2], Atul Gawande clearly states that the nurses, technicians and other personel "work for" the hero doctor. In privacy we still have the same attitude, software engineers "work for" the Privacy Officers.

We suffer from a huge lack of teamwork - the privacy hero's word is the Truth and that's it. Within the current culture of privacy, the engineers who are battling to implement or even comprehend privacy requirements written and explained at a completely different level of asbtraction than is necessary do not play any major part in those requirements.

Consider the defintions of personal data or PII for example, have these even been properly grounded in the undelying mathematical theories of what information is; or even for that matter in terms that can be properly understood by software engineers in their domain. Even within the legal domain, these terms have been defined in such a way that they are underspecified and open to legal interpretation.

In order to move from a highly ineffective privacy priesthood to a true, all encompasing and all relevant discipline based on a mutually supporting combination of legal, scientific and engineering principles we must change our culture from that of the Hero to that of the Team.

References

[1] Suzanne Gordon, Patrick Mendenhall and Bonnie Blair O'Connor. Beyond the Checklist
[2] Atul Gawande, Better
[3] Ian Oliver. Privacy Engineering: A Dataflow and Ontological Approach.

Wednesday, 24 September 2014

Finland's Privacy Niche

From last month, but now it is safe to post this more publicly: an article I was interviewed for by the Helsinki Times:

Finland finds niche in privacy and information security
21 Aug 2014
By David Cord
"FACEBOOK can send SMS messages on your phone, record your photos and track your location. The National Security Agency is reading your emails. Cyber criminals are trying to snatch your credit card details. In an era where we are rapidly losing all privacy online there is a demand by consumers to protect and control their personal information. As this demand grows, Finland has an opportunity to become the global leader in privacy and information security..."

Thursday, 18 September 2014

Scotland, Independence, Wales, the UK etc...


Well, what ever happens today in Scotland, I think that Salmond has won: the concessions that have been offered Scotland by the leaders of the main parties in the UK are generous to say the least. In effect a no vote will trigger practically everything but independence and full financial autonomy, while a yes vote will lead to much protracted negotiations and to be honest I'm not sure either side in this has a good idea of how these will turn out.

The questions of economy, currency union and EU membership are academic to a point. Firstly Scotland's economy will probably do quite well, though the independence vote is not specifically about the economy but rather the right of a people to decide their own future - democratically. Currency union might well become a moot point - if Scotland enters a currency union with the UK pound then there isn't really much the UK could do about it; there are alternatives such as pegging a Scottish currency against the EU in much the same way as Montenegro has done. Even if Scotland's currency did devalue then this could be a good thing for inward investment.

EU membership is interesting, especially as Spain and quite probably Belgium has vested interests in quelling their own internal independence movements - even then the pressure from their local voters and even smaller EU nations which might feel threatened by over dominance by larger members might sway this. EU membership also solves the currency issue.

Border controls and the like? Well Scotland couldn't become a Schengen country unless the UK joined too and I strongly doubt that we'd see passport checks at any time in the future other than in the more fanciful predictions.

My main issue however is - regardless of yes or no - is what happens to Wales and to a smaller extend to Northern Ireland and England. Certainly some Welsh politicians seem blissfully unaware or even naive of the implications. Even the Conservative Party in Wales has come out much more in favour of devolution of powers to Wales than Labour.

Politicians always has vested interests anyway: the Conservatives know that their only chance of any power in Wales is through the Senedd while Labour can always sit back and count on votes from their heartlands both in Wales and England. If Scotland leave, or even in Westminster is reorganised to solve the West Lothian Question this might change as Welsh MPs would have little influence even if they did vote on English specific legislations. There's an interesting discussion about this on the TrueWales web site in an article written by Rachel Banner (24 Jan 2012): The West Lothian Question.

Ironically it has been Welsh MPs who have probably made some of the most important decisions regarding England the UK: Nye Bevan and the NHS, Lloyd George and Home Rule (which unfortunately didn't come to pass due to World War 1) and even back to the Welsh advisors to Queen Elizabeth the First who promoted the idea of naval supremacy.

If we come back to what has been offered Scotland now and since the 1998 devolution votes one must seriously ask the question of why Scotland gets so much at the expense of the rest of the nations of the UK. I'm still unsure why every change to devolution in Wales requires a referendum such as that back in 2011 which granted Wales the power to make laws specific to the needs of the nation. Are politicians so weak and afraid of their decisions? Surely the populace voted those MPs into power to make such decisions for the good of the people and so they should take the responsibility themselves rather than pass it off to often under informed voters?

So on Friday, will Wales be offered DevoMax? I doubt it - no politician is that brave.

Wednesday, 20 August 2014

Design by Contract and Security

I've worked with design-by-contract for a long while; in fact its use as an essential programming concept was brought to my attention by one of my professors who didn't just teach it but demanded it as a fundamental part of any design or program. It remains today an integral technique in my toolbox of programming and design techniques. As an aside, Eiffel supports DbC as part of its programming model; it makes it one of the most elegant and easy languages not just to program in but to develop in.

DbC of course is related to the validation that one should make on web page forms and various concepts in strong typing of functions etc. Generalising DbC into other areas such as security, privacy should be an obvious step, but one seemingly not taken.

Via Schneier's brilliant security blog is a link to an article entitled Security As A Class Of Interface Guarantee. It is a long read but one more than worthwhile for software developers certainly; and maybe for any security and privacy engineers too. Actually if there's one article on security and development you read today it must be this one! Here's small sample:
Security Is Part Of Every Interface 
I prefer to think of security as a class of interface guarantee. In particular, security guarantees are a kind of correctness guarantee. At every interface of every kind — user interface, programming language syntax and semantics, in-process APIs, kernel APIs, RPC and network protocols, ceremonies — explicit and implicit design guarantees(promises, contracts) are in place, and determine the degree of “security” (however defined) the system can possibly achieve. 
Design guarantees might or might not actually hold in the implementation — software tends to have bugs, after all. Callers and callees can sometimes (but not always) defend themselves against untrustworthy callees and callers (respectively) in various ways that depend on the circumstances and on the nature of caller and callee. In this sense an interface is an attack surface — but properly constructed, it can also be a defense surface.

At the end of the article is a suprise link to a tweet :-)

Obvious isn't it...?!

Friday, 8 August 2014

Loyalty Cards

Tangentially related to privacy which I'll discuss later regarding information asymmetry, but first I wanted to comment on this article that appeared on LinkedIn: Business Travelers Are Saying "Buh-bye" to Loyalty Programs - Here's Why by Christopher Elliott, a "Reader advocate" for National Geographic Traveler

"After years of putting up with blackout dates, broken promises and bait-and-switch games, American travellers — particularly air travellers — are saying “Enough!”
They’re refusing to play the loyalty-program game, jettisoning blind brand allegiance in favor of a more pragmatic view of travel. Price and convenience are trumping mindless devotion to an airline, a car rental company or a hotel."

This applies equally to European travellers to I suspect. But let's look at the price-quality-customer service dimensions. I did as the article states a few years ago and switched allegiance from one to another, despite accumulating a sizeable amount of points and occasionally using them to upgrade it actually became too difficult to actually use those points.

I remember a few cases clearly. The first was trying to enter a business lounge at Helsinki Airport - according to the "loyalty" scheme terms and conditions I had enough flights to qualify for an upgrade to the next tier, thus allowing me access to the business lounge. Except that there was a mistranslation between the English translation and the "correct" terms and conditions. The airline customer service basically stated it wasn't their fault. Given that the lounge at the time was empty, but staffed by no less than three "customer representatives" make it all a little too surreal.

The second was at Heathrow when lounge entry was not just dependent on the card but on the airline that issued to card, despite both airlines being part of the same alliance. It worked like this: if you gained the second tier on airline A you could enter business lounges run by the alliance that A was a member of, except, if the lounges were at an airport where airline B, also of the same alliance, was the major carrier.

The third was when trying to book a flight with air miles. For my selected flight I had enough miles and successfully made the booking until it came to select my seats, where upon the whole process failed and I was unceremoniously ditched out of the booking process with a terse error about the flight no longer being available to points holders. It turns out this was an artefact of the internal IT systems and actually you had to call the customers service department to book the flights - after a long hold where you were constantly told that all of the customer service representatives were busy, but you really are valued by the company you're trying to spend you money with.

After a few flights across the Atlantic I switched to Lufthansa - Frankfurt and Munich are clean, efficient and as pleasant as airports go. Lufthansa may not have good economy seating on long haul but the crews are some of the most professional (and smiling!) I've had the pleasure to be on an aircraft with.

I actually have no idea actually how to redeem the points I've collected with Lufthansa and SAS - they'll probably expire or have expired without my knowledge without me ever receiving any bonus from my loyalty as a customer.

A few years ago a colleague of mine called a major Nordic airline in response to a request for customer feedback. It turns out that they couldn't care why he stopped flying with them. Surely with all the data analytics being applied to our data collected, the airline never stopped for a moment to question why customers suddenly stopped flying with them. 

Now due to primarily economic reasons, I fly with whoever gives me the best deal. Given that the terms and conditions are pretty much the same regardless whether you fly a national carrier or a "cheap" airline, price will always win. 

Given that many established, major airlines decided to compete with the cheap carriers by matching their standards and terms, it is no wonder that the loyalty of the customer to the airline has all but disappeared?

Then, we come to credit cards and store cards...will these go the same way as air miles as customers realise that the deal they get is barely worth the loyalty?

But as a final statement, given that this is all about customer loyalty - has anyone ever been contacted by an airline, shop or other about why they stopped using those products offered?

References:

Thursday, 7 August 2014

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.

Tuesday, 5 August 2014

On Finding Reasonable Measures To Bridge the Gap Between Privacy Engineers and Lawyers

This article originally appeared on the Privacy Association website on 29th July 2014.

On Finding Reasonable Measures To Bridge the Gap Between Privacy Engineers and Lawyers


Getting privacy lawyers and software engineers to work together to implement privacy is a perennial problem. Peter Swire, CIPP/US, and Annie Anton's article "Engineers and Lawyers in Privacy Protection: Can We All Just Get Along?" has explored this as has The Privacy Engineer's Manifesto, of which their article is part.

But here's the problem: We cannot keep addressing privacy from a top-down, legally driven perspective. No amount of additional processes and compliance checks is going to change the fact that software itself is so complex. Software engineering is often assumed to be the final stage and by some a mere consequence of many requirements from a large number of often conflicting sources.

Often privacy issues are “solved” by hashing an identifier, encrypting a communications link or anonymizing a data set, for some definition of anonymization. Many of these are piecemeal, ineffective, Band-Aid type solutions—the proverbial rearranging of deck chairs on the Titanic. Privacy Theater at its worst … or best.

So how do we address this?

First, maybe we should realize that we don't really understand each other’s disciplines. Very few lawyers are trained software engineers and vice-versa; therefore, constructing a lingua franca between these groups is part of that first step.

Often, understanding ideas that are simple in one domain do not translate to the other. For example, the use of the term “reasonable” means nothing in the software engineering domain. Plus, the simple act of “encryption” to a software engineer hides an enormous complexity of network protocols, key management, performance, encryption libraries and so on. Similarly, the now-ubiquitous use of “app” by lawyers to mean something that runs on your phone means a lot more to the software engineer.

What does “app” really mean to software engineers?

That little piece of code that downloads your news feed each morning and presents it in a friendly way—allowing you the scroll through using your touch screen device and maybe now and again presenting an advert because you didn't want to buy the paid version—is, in fact, not a tiny bit of code at all.

Effectively, what runs on your device is a multi-layered, complex interaction of hundreds of components, each sharing the device's memory, long-term storage, network components, display, keyboard, microphone, camera, speaker, GPS and so on. Each of those individual components interacts with layers underneath the interface, passing messages between components, scheduling when pieces of code must run and which piece of code gets the notification that you've just touched the screen as well as how and where data is stored.

When the app needs to get the next news item “from the web,” we have a huge interaction of network protocols that marshal the contents of the news feed, check its consistency, perform error-correction, marshal the individual segments of message from the network, manage addressing messages and internal format. There are protocols underneath this that decide on the routing between networks and those that control the electrical pulses over wires or antennae. This itself is repeated many, many times as messages are passed between routing points all over the Internet and includes cell towers, home wireless routers, undersea cables and satellite connections. Even the use of privacy-preserving technologies—encryption, for example—can be rendered virtually meaningless because underneath lies a veritable treasure trove of metadata. And that is just the networking component!

Let's for the moment look at the application's development itself, probably coded in some language such as Java, which itself is a clever beast that theoretically runs anywhere because it runs on top of a virtual machine and can be ported to almost any computing platform. The language contains many features to make a programmer's life easier by abstracting away complex details of the underlying mechanisms of how computers work. These are brought together through a vast library of publicly available libraries for a plethora of tasks—from generating random numbers to big data analytics—in only a 'few' lines of well-chosen code.

Even without diving deep into the code and components of which it’s made, similar complexity awaits in understanding where our content flows. Maybe your smartphone’s news app gets data from a news server and gives you the opportunity to share it through your favorite social network. Where does your data flow after these points? To advertisers, marketers, system administrators and so on? Through what components? And what kinds of processing? How about cross-referencing? Where is that data logged and who has access?

Constructing a full map or data flow of a typical software system—even a simple mobile app—becomes a spider web of interacting information flows, further complicated by layering over the logical and physical architectures, the geographical distribution and concepts such as controller and processor. Not to mention the actual content of the data, its provenance, the details of its collection, the risks, the links with policies and so on. And yet we still have not considered the security, performance and other functional and nonfunctional aspects!

Software engineers have enough of a problem managing this complexity without having to learn and comprehend legal language, too. Indeed, privacy won't get a foothold in software engineering until a path from “reasonable” can be traced through the myriad requirements to those millions of lines of code that actually implement “reasonable.”

Engineers love a challenge, but often when solutions are laid out before them in terms of policy and vague concepts—concepts which to us might be perfectly reasonable (there's that word again!)—then those engineers are just going to ignore or, worse, mis-implement those requirements. Not out of any malicious intent but because those requirements are almost meaningless in their domain. Even concepts such as data minimization can lose much if not all of their meaning as we move through the layers of code and interaction.

Life as a software engineer is hard: juggling a complex framework of requirements, ideas, systems, components and so on without interpreting what a privacy policy actually means across and inside the Internet-wide environment in which we work.

Software isn't a black box protected by a privacy policy and a suite of magic privacy-enhancing technologies but a veritable Pandora's Box of who-knows-what of “things.”

As privacy professionals, we should open that box often to fully comprehend what is really going on when we say “reasonable.” As software engineers, we'll more than make you welcome in our world, and we'd probably relish the chance to explore yours. But until we both get visibility in our respective domains and make the effort to understand each other's languages and how these relate to each other, this isn't going to happen—at least not in any “reasonable” way
.

Sunday, 3 August 2014

Messenger 10 year Anniversary

One of the first posts I made on this blog was about the Messenger probe to Mercury - at the time it had just made the 3rd fly-by before orbit insertion about 18 months later. On 1st August it celebrated 10 years since its launch.

So a large beer to all involved!

So now we have Messenger at Mercury, Venus Express performing dangerous aerobraking manoeuvres in Venus' atmosphere, a fleet robots trundling over Mars - not forgetting a small fleet of satellites around the planet, Juno on its way to Jupiter and venerable Cassini still going strong around Saturn.

Then there are the three that I'm most anticipating:

and then in just a few days, Rosetta finally arrives at 67P/Churyumov-Gerasimenk after 10 years. At this moment she's 3 days away with about 500 km to go! She's caring a lander called Philae which'll deeply later this year. ESA have a good track record of this kind of landings in exotic places with Huygens.

Can't wait!

In the meantime: