Privacy Engineering for Today - DIMECC Presentation

Here is my presentation from the DIMECC 9th Annual Seminary on Business innovation in Finland.

Privacy Engineering for Today from Ian Oliver

Requirements Engineering and Privacy

A lot of travelling this month to conferences and speaking about privacy engineering (as usual). I just spent a week in Beijing at RE'16 (Requirements Engineering 2016) where I both presented a paper on privacy requirements and participated in a panel session on digitalisation and telecommunications - more on that later.

Anyway, here are the slides from the privacy paper:

Experiences in the Development and Usage of a Privacy Requirements Framework from Ian Oliver

And here is the abstract:

"Any reasonable implementation of privacy requirements can not be made through legal compliance alone. The belief that a software system can be developed without privacy being an integral concept, or that a privacy policy is sufficient as requirements or compliance check is at best dangerous for the users, customers and business involved. While requirements frameworks exist, the specialisation of these into the privacy domain have not been made in such a manner that they unify both the legal and engineering domains. In order to achieve this one must develop ontological structures to aid communication between these domains, provide a commonly acceptable semantics and a framework by which requirements expressed at different levels of abstractness can be linked together and support refinement. An effect of this is to almost completely remove the terms ‘personal data’ and ‘PII’ from common usage and force a deeper understanding of the data and information being processed. Once such a structure is in place - even if just partially or sparsely populated - provides a formal framework by which not only requirements can be obtained, their application (or not) be justified and a proper risk analysis made. This has further advantages in that privacy requirements and their potential implementations can be explored through the software development process and support ideas such as agile methods and ‘DevOps’ rather than being an ‘add-on’ exercise - a privacy impact assessment - poorly executed at inappropriate times."

Ian Oliver (2016) Experiences in the Development and Usage of a Privacy Requirements Framework. Requirements Engineering 2016 (RE'16), Beijing, China, September 12-17, 2016

2nd IW5GS - Programme

The 2nd International Workshop on 5G Security

IW5GS2016

Xi'an, China

June 19, 2016

http://www.mobimedia.org/2016/show/program-final

IW5GS-01: (June 19, 2016, Sunday, 10: 30 – 12:30, Room B)

Session Chair: Valtteri Niemi (Email: valtteri.niemi@helsinki.fi)

Keynote 1: 5G Security for IoT

Speaker: Dr. Zhiyuan Hu, Nokia Shanghai Bell  (zhiyuan.hu@alcatel-sbell.com.cn)

Keynote 2: 5G Security: Forward Thinking

Speaker: Bo Zhang, Huawei (liufei19@huawei.com)

IW5GS-02: (June 19, 2016, Sunday, 14: 00 – 16:30, Room B)

Session Chair: Siddharth Prakash Rao (Siddharth.rao@aalto.fi); Ian Oliver (ian.oliver@nokia.com)

Paper 1: Protecting IMSI and User Privacy in 5G Networks

Karl Norrman, Elena Dubrova, Mats Näslund

Paper 2: Privacy of the Long-Term Identities in Cellular Networks

Philip Ginzboorg, Valtteri Niemi

Paper 3: Error-Correcting Message Authentication for 5G

Elena Dubrova, Mats Näslund, Göran Selander, Karl Norrman

Paper 4: Privacy in LTE networks

Siddharth Prakash Rao, Bhanu Teja Kotte, Silke Holtmanns

Paper 5: A Survey on Software-Defined Networking Security

Shanshan Bian, Peng Zhang, Zheng Yan

Paper 6: Designing Hybrid Cloud Computing Framework using OpenStack for Supporting Multimedia with Security and Privacy

Isaac Cushman, Lei Chen, Danda B. Rawat, and Nhien-An Le-Khac

International Workshop on 5G Security - Programme

The 1st IEEE International Workshop on 5G Security held in conjunction with IEEE TrustCom-15

There is a fast on-going change in the technical architectures and topologies of the Internet: in the near future 5G and next generation 4G/LTE network architectures will be based on or migrated to Software Defined Networking (SDN) and Network Functions Virtualization (NFV). These create new virtual network elements each affecting the logic of the network operation, traffic management and introducing new and novel security challenges. Aspects such as security of orchestration, management functionality as well as surveillance and privacy are brought to the fore. At the same time they introduce new ways of dealing with attack prevention, management and recovery.

The one-day workshop will consist of papers, presentations and demonstrations on the subject of advanced network security. While primarily related to 5G networks, experiences from 4G/LTE, 3G and earlier, including case studies on practicalities of known attacks and novel attack vectors will be considered for acceptance. An invited keynote speech will be given setting out the overall area of security in network development and operations.

IW5GS Programme
TrustCom 2015 Helsinki, Finland
Friday 21, August 2015

10h05-11h50 – Session I

• Ian Oliver, Silke Holtmanns, Workshop Opening
• Günther Horn and Peter Schneider, Towards 5G Security
• Siddharth Prakash Rao, Silke Holtmanns, Ian Oliver and Tuomas Aura. Unblocking stolen mobile devices using SS7-MAP vulnerabilities
• Vikramajeet Khatri and Joerg Abendroth, Mobile Guard Demo - Network Based Malware Detection

13h10-14h55 – Session II

• Ian Oliver, Aspects of 5G Security
• Nicolae Paladi and Christian Gehrmann. Towards Secure SDN-based Multi-tenant Virtualized Networks
• Elena Dubrova, Mats Näslund and Göran Selander. CRC-Based Message Authentication for 5G Mobile Technology
• Prajwol Kumar Nakarmi, Oscar Ohlsson and Michael Liljenstam. An Air Interface Signaling Protection Function for Mobile Networks: GSM Experiments and Beyond

15h15-17h00 – Session III

• Bengt Shalin, keynote talk
• Mingjun Wang and Zheng Yan. Security in D2D Communications: A Review
• Karl Norrman, Mats Näslund, Bengt Sahlin and Jari Arkko. A USIM compatible 5G AKA protocol with perfect forward secrecy
• Silke Holtmanns,Ian Oliver, Workshop Closing

UK Ontology Network 2015 Presentation

I really have been a bit lax here of late - not that I have little to write, but rather time (as always!) and the day job takes me away from privacy into new uncharted, more security research related areas - which I will admit is great fun!

Back in April I attending a fascinating little workshop run by the UK Ontology Network to talk about ontologies for privacy. What makes this workshop fun is the sheer amount of interaction between the participants: the distinction between presenter and audience is completely blurred. As a presenter you get a 5 minute slot then after a number of presenters on similar subjects, a 20 minute panel session where the audience really gets into the conversation.

I'm going to be unfair to all the presenters at UKON 2015 but I'm going to pick out a presentation by Adam Nogradi on Sparqlycode - a tool for semantically annotating source code and establishing compliance against, in this case, certain security guarantees. Of course, to move to a different area all you need is an ontology for your subject area, say, privacy, and you have a tool for privacy compliance...more on this later :-)

So here's my presentation based on the work in the book Privacy Engineering: A Dataflow and Ontological Approach.

Ontologies for Privacy from Ian Oliver

And the book containing a much more detailed description can be bought from Amazon, Barnes and Nobles etc etc.

Automating Privacy Compliance

I was at the 2015 meeting of the UK Ontology Network in Leeds earlier this month where, amongst many, there was a presentation about a tool called Sparqlycode - which if you get the chance you must check out!

Anyway, Paul Worral of Interition Ltd wrote a very nice summary of my work:

Ian Oliver [Nokia Networks, Espoo, Finland] presented Ontologies for Privacy.  The whole idea behind Sparqlycode is to provide an information tier for software that enables it to be linked to knowledge about the business.  Ian's work is a perfect example of this. He demonstrates how high-level policies on Personally Identifiable Information should and can be directly related to the code responsible for adhering to them. Ian has authored a book on the subject, Privacy Engineering. I bought it and hope to have some examples of how it can be applied to Sparqlycode soon.

I look forward to seeing how this works out, but it certainly is in the direction of where I hoped. It'll be very interesting to see how this particular approach matches with a more data-flow based modelling approach.

At UKON2015 there was also an extremely interesting presentation about a tool called TawnyOWL for programmatically generating ontologies. Given that Clojure is my current language of choice this seems a perfect fit for the privacy ontologies themselves.

Modelling Privacy

Here's a teaser from the next book on privacy. ETA late 2015, December - just in time for Christmas - if I work really hard!

It will compliment the existing book Privacy Engineering and build upon more of the data flow modelling, use of taxonomies and techniques for analysing models such as those from safety critical engineering, eg: FMEA, RCA etc.

In the meantime, Privacy Engineering is available from Amazon.com, Amazon.co.uk, CreateSpace as well as Barnes and Noble and even book stores such as CDON.fi here in Finland.

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

Privacy Engineering Book

Privacy Engineering

A dataflow and ontological approach

An essential companion book for those of us who have to model systems from small mobile apps to large, cloudified BigData system from the perspective of privacy and personal data handling.

Available via Amazon (US, UK and all Amazon worldwide sites), CreateSpace and selected bookstores such as Barnes and Noble. Kindle version available, also with Kindle Match Book enabling you to the Kindle version for just 2.99USD when purchasing the paperback.

Table of Contents:

1. Introduction
2. Case Study
3. Privacy Engineering Process Structure
4. Data Flow Modelling
5. Security and Information Classifications
6. Additional Classification Structures
7. Requirements
8. Risk and Assessments
9. Notice and Consent
10. Privacy Enhancing Techniques
11. Auditing and Inspections
12. Developing a Privacy Programme

Information privacy is the major defining issue of today's Internet enabled World. To construct information systems from small mobile 'apps' to huge, heterogeneous, cloudified systems requires merging together skills from software engineering, legal, security and many other disciplines - including some outside of these fields! 

Only through properly modelling the system under development can we full appreciate the complexity of where personal data and information flows; and more importantly, effectively communicate this. This book presents an approach based upon data flow modelling, coupled with standardised terminological frameworks, classifications and ontologies to properly annotate and describe the flow of information into, out of and across these systems. 

Also provided are structures and frameworks for the engineering process, requirements and audits; and even the privacy programme itself, but takes a pragmatic approach and encourages using and modifying the tools and techniques presented as the local context and needs require.

Published July 2014

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

Foundations of Privacy - Another Idea

This got triggered by a post on LinkedIn about what a degree in privacy might contain. I've certainly thought about this before, at least in terms of software engineering, and even have a whole course that could be taken over a semester ready to go.

Aside: CMU has the "World's First Privacy Engineering Course": a Master of Science in Information Technology—Privacy Engineering (MSIT-PE) degree. So, close, but a major university here in Finland turned down the chance to create something similar a few years back...

That aside, I've been wondering about how to present they various levels of things we need to consider to properly define privacy and put it on strong foundations. Though in the guise of information theory we already have this, though admittedly Shannon's seminal work from the 1930's is maybe a little too deep. On the other hand understanding concepts such as channels, entropy are fundamental building blocks, so maybe they should be there along with privacy law - now that would make some course!

Even just sketching out areas to present and what might be contained therein...how about this, even if a linear map from morality to mathematics is too constraining?

There are missing bits - we still have a  semantic gap between the "legal world" and the "engineering world"; parts that I'm hoping that things such as the many conferences, academic works and books such as the excellent Privacy Engineer's Manifesto and Privacy Engineering will play a role in defining. Maybe the semantic gap goes away once we start looking at this...is there even a semantic gap? 

However, imagine for a moment starting anywhere in this stack and working up and down and keeping everything linked together in the context of privacy and information security. Imagine seeing the link between EU privacy laws and type theory, or between the construction of policies and entropy, the algebra of HIPAA, a side course in homotopy type theory and privacy...maybe with that last one I'm getting carried away, but, this is exactly what we need to have in place.

Each layer provides the semantics to the layer above - what do our morals and ethics means in terms of formalised laws, what do laws mean in terms of policies, what do policies mean in terms of software engineering structures, and down to the core mathematics and algebras of information.

Privacy and privacy engineering in particular almost has everything: law, algebra, morals, ethics, semantics, policy, software, entropy, information, data, BigData, Semantic Web etc etc etc. Furthermore, we have links to areas such as security, cryptography, economic theory etc!

Aren't these the very things any practitioner of privacy (engineering) should know, or at least have knowledge of? Imagine if lawyers understood information theory and semantics, and, software engineers understood law? 

OK, so there might be various ways of putting this stack together, competing theories of privacy etc, but that would be the real beauty here - a complete theory of privacy from the core mathematics through physics, computation, type theory, software engineering, policies, law and even ethics and morals.

But again, no more naivety, no more terminological or ontological confusions, policies and laws being traceable right down to the computation structures and code. Quite a tall order, but such a course bringing all these together really would be wonderful...

And wouldn't that be something!

Legal Document Humour

I know software engineers and legal speak different languages, but...

Daniel Solove (2006) A Taxonomy of Privacy. University of Pennsylvania Law Review. 154(3)

Not quite as naive about privacy as before

A while back I wrote an article on how were we being naive about privacy in that we're all talking about the subject but no-one seems to be actually asking the question of what it is.

In order to answer this we've* taken an ontological approach by decomposing concepts into things such as information type, security class, jurisdiction, purpose, usage, provenance etc. All those concepts which make sense to the engineers who have to build information systems.

*Ora Lassila (he of RDF fame) has had a pretty big (huge!) hand in all of this too. Hey! We even got demonstration and prototype implementations working!

No work like this is even done in isolation - ontological approaches aren't new and certainly security, privacy, risk management etc have been tackled in one way or another - Solove, Schneier just to name two big names and a host of other researchers along too.

Now this is where I have a lot of hope: there is quite a bit a work in this area - that is, formalising concepts of privacy and in particular risk and risk avoidance in this ontological manner. There's even work on matching ontologies together. We start to see the real, fundamental structure of privacy and its conceptual basis.

What this means in the long term (and even the short!) is that we have a common terminological and semantic framework from lawyers to programmers coming into place.

We're missing some parts of course: how do all these ontologies fit together?  Can we unify the notions of consent used by lawyers with the [boolean] data types used by programmers?

"Your privacy is important to us"

bool optedIn = False  //sensible default

Actually we do in part - myself and Ora did develop quite a nice unification framework to link the ontologies together, link with the idea of information, link it with the notions of database table, CSV structures, classes etc; and even link it with how systems such as HADOOP process data.

So this gets me to a few places:

1. There is work on this being made - various groups are developing ontologies to express relevant concepts about information and aspects of information
2. Some groups are unifying those and drawing out subtle semantic differences
3. Some groups are applying these to more abstract areas such as the notions of consent and notice and how these may be made more meaningful to machines, and I hope humans too

We're starting to fill in the technical, fundamental details of what privacy is and now I find myself working with how we link these structures with the ideas of data flow modelling, risk management and software lifecycle requirements which requires all of the above.

References

Cena, Dokoohaki, Matskin. (2011) Forging Trust and Privacy with User Modeling Frameworks: An Ontological Analysis. STICS2011 (Draft)

Anya Kim and Jim Luo and Myong Kang (2005) Security Ontology for Annotating Resources. Research Lab, NRL Memorandum Report, pp51.

Kost, Freytag, Kargl, Kung. Privacy Verification using Ontologies

Golnaz Elahi, Eric Yu, Nicola Zannone (2009) A Modeling Ontology for Integrating Vulnerabilities into Security Requirements Conceptual Foundations?

Security and Privacy Ontology

Structuring Privacy Requirements pt 1

One of the toughest problems I'm having to solve, not just for my book on privacy engineering, but in my daily job as well is to formulate a set of privacy requirements to the software engineers and the R&D teams.

Actually it isn't that the privacy requirements themselves are hard, we've plenty at the policy level and extrapolating these down into the more functional and security related requirements at the implementation level (ok, it is difficult but there are harder things in this area).

Placing all these in a structure that ties together the various classifications and aspects of information, data flow modelling, requirements and risk management has been interesting and fiendishly difficult to say the least. Getting this structure into a state that supports all of these and getting the semantics of the kinds of thing it is structuring is critical to understanding how all of this privacy engineering works.

We assume that we understand the classification systems, for example the almost traditional Secret-Confidential-Public style security classifications and the Location, Time etc classifications of information type; as well as the other aspects such as purpose, usage, provenance, identity etc. Each of these has its own set of classification elements, hierarchy and other ontological structure. For example for information type:

Information Type Hierarchy

We also assume we understand data flow modelling with its processes, flows, sources, sinks and logical partitionings. We can also already see the link between elements here (as shown below) and the classification systems above

Example Data Flow with Annotations from Previously Described Ontologies/Classification Systems

Now the structure of our requirements needs to take into consideration the various elements from the classification systems, the aspect of the requirement we want to describe (more on this below) and the required detail of requirement relevant to the stage in the software process. This gives us the structure below:

So if we wish to find the requirements for User's Home Address Policy for Local Storage then we take the point corresponding to those coordinates. If there happens to be nothing there then we can use the classification systems' hierarchies to look for the requirement corresponding to a parent; a "user's home address" is-a "Location":

So if we take the example data flow from earlier then for each of the flows, storages and processes we can construct a set of requirements simply by reading off the corresponding requirements from the structure above.

This leads to an interesting situations where it is possible to construct a set of requirements which are overconstraining. That is simply that we can not build a system that can support everything, for example, one data point might trigger a secret classification and key management, encrypted content etc.

We then need to weaken the requirements such that a system can be constructed according to some economic(!) model. As we weaken or retrench our requirements we are introducing risk into the system,

Aside: Retrenchment - here's a good reference: Banach, Poppleton. Controlling Control Systems: An Application of Evolving Retrenchment. ZB 2002:Formal Specification and Development in Z and BLecture Notes in Computer Science Volume 2272, 2002, pp 42-61.

This gives us our link to risk management and deciding whether each "weakness" we introduce is worth the risk. And as risk can be quantified and we can perform further tasks such as failure mode and effects analysis then we obtain a rigorous method to predict failures and make informed decisions about these. I'll describe more on this in later articles.

Security Classifications

We've introduced information classifiations, provenance, usage and purpose but so far neglected "security" classifications. These are the classic secret, confidential, public classifications so beloved of government organisations, Kafkaesque bureaucracies, James Bond's bosses etc.

Part of the ISO27000 standard for security directly addresses the need for a classification system to mark documents and data sets. How you set up your security classification is left open, though we tend to generally see four categories:

• Secret
• Confidential
• Public
• Unclassified

At least for everything other than Unclassified, the classifications tend to follow a strict ordering, though some very complex systems have a multitude of sub-classes which can be combined together.

For each level we are required to define what handling and storage procedures apply. For example:

Public

• May be distributed freely, for examples by placing on public websites, social media etc. Documents and data-sets can be stored unencrypted.

Confidential

• Only for distribution within the company. May not be stored on non-company machines or places on any removable media (memory sticks, CD etc). Documents and data-sets can be stored unencrypted unless they contain PII.

Secret

• Only for distribution by a specific denoted set of persons. May not be stored on non-company machines or places on any removable media (memory sticks, CD etc). Documents and data-sets must  be stored encrypted and disposed of according the DoD standards.

Data that is marked unclassified should be treated as property of the author or authors of that document and not distributed. This would make unclassified a level higher than secret in our above classification.

A good maxim here is: Unclassified is the TOP level of security.

Sounds strange? Until document or data-set is formally classified how should it be handled?

Note in the above that we refer to the information classification of any data within a data set to further refine the encryption requirements for classified information. No classification system as described earlier exists alone, though ultimately they all end up being grounded to something in the security classification system. For example we can construct rules such as:

• Location & Time => Confidential
• User Provenance => Confidential
• Operating System Provenance => Public

and applied to our earlier example:

we find that this channel and the handling of the data by the receiving component should conform to our confidential class requirements. A question here is that does a picture, location and time constitute PII?  Rules to the rescue again:

• User Provenance & ID => PII
• http or https => ID, Time

So we can infer that we need to protect the channel at least, either by using secure transport (https) or by encrypting the contents.

The observant might notice that ensuring protection of data as we have defined above for some social media services is not possible. This then provides a further constraint and a point to make an informed business decision. In this case anything that ends up at the target of this channel is Public by default, this means that we have to ensure that the source of this information, the user, understands that even though their data is being treated as confidential throughout our part of the system, the end-point does not conform to this enhanced protection. Then it becomes a choice on the user's part of whether they trust the target.

In the previous article about information contamination, we have an excellent example here. We need to consider the social media service as a "sterile" area while our data channel contains "dirty" or "contaminated" information. Someone needs to make the decision that this transfer can take place and in what form - invariably this is the source of the information, that is, the user of the application.

Does this mean that we could then reduce the protection levels on our side? Probably not, at least from the point of view that we wish to retain the user's trust by ensuring that we do our best to protect their data and task the responsible position of informing the user of what happens to their data once it is outside of our control.

Data Aspects and Rules

In the previous post we introduced how to annotate data flows in order to understand better what data was being transported and how. In this post I will introduce further classifications expressed as aspects.

We already have transport and information class as a start; the further classifications we will introduce are:

• Purpose
• Usage
• Provenance

Purpose is relatively straightforward, and consists of two classes: Primary and Secondary. These are defined in this previous posting.

Usage is remarkably hard to define and the categories tend to be quite context specific, though patterns do emerge. The base set of categories I tend to use are:

• system provisioning - the data is being used to facilitate the running and management of the system providing the service, eg: logging, system administration etc.
• service provisioning - the data is being used to facilitate the service itself; this means the data is necessary for the basic functionality of that service, or primary data.
• advertising - the data is being used for advertising (tageted or otherwise), by the service provider or third party
• marketing - the data is being used for direct marketing back to the source of the data
• profiling - the data is being used to construct a profile of the user/consumer/customer. It might be useful in some cases to denote a subtype of this - CRM - to explicitly differentiate between "marketing"  and "internal business" profiling.

Some of the above tend to occur often together, for example, data for service provisioning is often also used for advertising and/or marketing too.

Provenance denotes the source of the information and is typically readable from the data-flow model itself. There does exist a proposed standard for provenance as defined by the W3C Provenance Working Group. It is however useful to denote for completeness purposes whether data has been collected from the consumer, generated through analytics over a set of data, from a library source etc.

We could enhance our earlier model thus:

As you can see, this starts to be quite cumbersome and the granularity is quite large. Though from the above we can already start to see some privacy issues arise.

The above granularity however is perfectly fine for a first model but to continue we do need to refine the model somewhat to better explain what is really happening. We can construct rules of the form:

• "Info Class" for "Purpose" purpose used for "Usage"

for example taken from the above model:

• Picture for Primary purpose used for Service Provisioning
• Location for Primary purpose used for Service Provisioning
• Time for Primary purpose used for Service Provisioning
• Device Address for Secondary purpose used for System Provisioning
• Location for Primary purpose used for Advertising
• Location for Primary purpose used for Profiling
• ...

and so on until we have exhausted all the combination we have, wish or require in our system. Note that some data comes from knowledge of our transport mechanism, in this case a device address (probably IP) from the use of http/s.

These rules now give us a fine grained understanding of what data is being used for what. In the above case, the flow to a social media provider, we might wish to query whether there are issues arising from the supply of location, especially as we might surmise that it is being used for profiling and advertising for example.

For each rule identified we are required to ask whether the source of that data in that particular data flow agrees to and understands where the flow goes, what data is transported and for what purposes; and then finally whether this is "correct" in terms of what we are ultimately promising to the consumer and according to law.

In later articles we will explore this analysis more formally and start also investigating security requirements, country requirements and higher level policy requirements such as safe harbour, PCI, SOX etc.

Information Privacy: Art or Science?

I was handed a powerpoint deck today containing notes for a training course on privacy. One thing that struck me was the statement on one of the slides, in fact it was the only statement on that slide:

PRIVACY IS AN ART

This troubles me greatly and the interpretation of this probably goes a long way into explaining some things about the way information privacy is perceived and implemented.

What do we mean by art, and does this mean that privacy is not a science?

Hypothesis 1: Privacy is an art

If you've ever read great code it is artistic in nature. You can appreciate the amount of understanding and knowledge that has gone into writing that code. Not just at the act of writing, or the layout and indentation, but in the design of the algorithms, the separation of concerns, the holistic bigger picture of the architecture. Great code requires less debugging, performs well, stays in scope, and if it ever does require modification, it is easy to do. Great programmers are scientists - they understand the value to the code, they avoid technical debt, they understand the theory (maybe only implicitly) and the science and discipline behind their work and in that respect they are the true artists of their trade.

For example, Microsoft spent a lot of effort in improving the quality of its code with efforts such as those the still excellent book Code Complete by Steve McConnell. This book taught programmers great techniques to improve the quality of their code. McConnell obviously knew what works and what didn't from a highly technical perspective based on a sound, scientific understanding of how code works, how code is written, how design is made and so on.

I don't think information privacy is an art in the above sense.

Hypothesis 2: Privacy is an "art".

In the sense that you're doing privacy well in much the same was as a visitor to an art gallery knows "great art". Everyone has their own interpretation and religious wars spring forth over whether something is art or not.

Indeed here is the problem, and in this respect I do agree that privacy is art. Art can be anything from the formal underpinnings of ballet to the drunken swagger of a Friday night reveler - who is to say that the latter is not art? Compare ballet with forms of modern and contemporary dance: ballet is almost universally considered "art" while some forms of contemporary dance is not - see our drunken reveler at the local disco...this is dance, but is it art?

Indeed sometimes the way we practice privacy is very much like the drunken reveler but telling everyone at the same time that "this is art!"

What elevates ballet, or the great coder, to become art is that they both have formal, scientific underpinnings. Indeed I believe that great software engineering and ballet have many similarities and here we can also see the difference between a professional dancer and a drunken reveler on the dance floor: one has formal training in the principles and science of movement, one does not.

Indeed if we look at the sister to privacy: security, we can be very sure that we do not want to practice security of our information systems in an unstructured, informal, unscientific manner. We want purveyors of the art - artists - of security to look after our systems: those that know and intuitively feel what security is.

There are many efforts to better underpin information privacy, rarely do these come through in the software engineering process in any meaningful manner unless explicitly required or audited for. Even then we are far from a formal, methodical process by which privacy becomes an inherent property of the systems we are building. When we achieve this as a matter of the daily course of our work then, and only then, privacy will become an art practiced by artists.

Teaching Privacy

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.

I've run courses on data modelling, formal methods, systems design, semantics and now privacy - the latter however always seems to be "a taster or privacy" or "brief introduction to privacy" and there rarely is the chance to get into specifics about what information is.

This of course has some serious implications and one of the best I can find is when we talk about anonymisation. I've seen horrors such as statements "if you hash this identifier, then it is anonymous" or "if we randomise this data then we can't track" or lately, "if we set this flag to '1' then no-one will track you anymore". In the first case I refer people back to the AOL Data Leak and the dangers of fingerprinting, semantic analysis and simple cross-referencing.

I made a study a while back based on the leak of 16,000 names from various Finnish education organisations (plus maybe other places). It was very interesting to see that even with the released list that contained dates of birth and last names how many were already unique, and even in the cases where there existed common Finnish names how easy it was to trace these back to a unique person. Actually going to the next step and verifying this with that person would I guess have been somewhat illegal or if not, unethical to say the least. Social engineering would have been very easy in many of these cases I'm sure.

So given cases like these and the current dearth of educational material I though it would be nice to try to put together a more comprehensive and deeper set of material. Some universities are already doing this and there also exist industrial qualifications such as those by the IAPP, however at this stage all ideas are welcome.

Now I want to specifically address a technical audience: software engineers, computer scientists - the people who end up building these systems because that's where I feel much breaks down - for many reasons but I won't appoint blame here - that's not really constructive in the current context.

First of all I want to break things down into 3 logical segments, actually there are 4 but I'll discuss that one later:

• Legal
• Consumer Advocacy
• Technical

 and address each area individually.

Legal is relatively straightforward in that an understanding of principles of privacy, how various jurisdictions view data, information, anonymisation, cross-referencing, children and minors, cross-border data transfer, retention and data collection and a discussion of certain practices, eg: EU, US, China, India etc. This discussion doesn't have to be heavy but an understanding of what the law states and how it interprets things is critical. Also from here we should get an understanding of how the law affects the engineering side of things: common terminology as a good example.

Consumer advocacy is really the overview material in my opinion - what are the principles of privacy, for example Cavoukian's Privacy by Design as an example (even if I'm not happy with the implementation of these), how to consumers view privacy, what is the reality (say vs do) and also various case studies such as how consumers view Google, Apple, Nokia, Facebook, various Governments, technologies such as NFC, mobile devices, 'Smart Televisions', direct marketing and advertising, store cards etc. Out of this comes an understanding of how privacy is viewed and even an appreciation of why we don't get privacy: anti-privacy if you like.

The technical aspect takes in many technologies, rather than describe, I'll list them (and this will be non-exhaustive and in no particular order)

• Basic Security - Web, Encryption, Hashing, Hacking (XSS etc), authentication (OpenID, OAuth etc), differences/commonalities between privacy and security, mapping privacy problems into security problems as a solution
• Databases - technologies, design, schema development (eg: relational theory), "schema-less" databases, cross-referencing, semantic isolation
• Semantics - ontologies, classifications, aspect, Semantic Web
• Data-flow
• Distributed Systems - networking and infrastructure
• API design - browsers, apps, web-interfaces, REST
• Data Collection - primary vs secondary vs infrastructure, logging
• Policy - policy languages, logic, rules, data filtering
• Anonymisation - data cleansing
• Identifiers - tracking, "Do Not Track"
• User-Interface
• Metrics for privacy - entropy
• Information Types and Classification - location, personally identifiable information, identifiers, PCI, health/medical data

as you can see the list is extensive and an understanding of each of these areas is critical to building systems that honour and preserve privacy in its various forms (as described in the consumer advocacy and legal sections). The main point here is to provide software engineers and computer scientists with the tools to implement privacy in a meaningful manner.

Now that we have outlined the three areas we can look at the fourth which binds these together and which I tentatively call "Theory of Privacy".

Obviously something binds these areas together and there does exist a huge body of work on the nature of information and its classifications. I particularly like the approach by Barwise and Seligman in the 1997 book Information Flow: The Logic of Distributed Systems*. I believe we can quite easily get into all sorts of interesting ontology, semantics and even semiotic discussions. Shannon's Information Theory and notions of entropy (eg: Volkstein's book: Entropy and Information) are fundamental to many things. I think this really is an area that needs to be opened up and addressed seriously and anything that binds together and provides a common language to unify consumer advocacy, the law and software engineering is critical.

Finally, no outline of a course would be complete with some preliminary requirements and a book list. For the former an understanding of computer systems and basic computer security is a must (there is no privacy without security), a grounding in software engineering techniques and a dose of computer science similarly. For the books, my first draft list would include:

• Barwise, Seligman. Information Flow
• O'Hara, Shadbolt. The Spy in the Coffee Machine: The End of Privacy as We Know It
• Solove. Understanding Privacy
• Nissenbaum. Privacy in Content: Technology, Policy, and the Integrity of Social Life
• Solove: The Future of Reputation: Gossip, Rumour, and Privacy on the Internet

*somebody should make a movie of this.

Relative complexity

I'm told that software engineers don't understand taxonomies and ontologies, which confuses me a little - or actually a hell of a lot because I'm not sure what this statement actually means?

Are we saying that our software engineers are on one hand stupid but on the other hand build complex class hierarchies and relationships then navigate through the various mechanisms for building instances of those?

I currently have to construct an ontology/taxonomy for data/information with some real bizarre simplicity requirements which will ultimately reduce something inherently simple down to something unusable and without any real worth. Primarily because I am told that software engineers won't understand anything complex.

This troubles me.

Must go, off to another debate about syntax, or specifically the naming of things; or probably the colour of the picture in Powerpoint - wrong shade of pastel blue again....Wadler strikes again...

Modelling

I've been recently involved in some work involving modelling of information systems (or software systems if you prefer). What has been quite interesting is the amount of effort it takes to move beyond the idea of "let's make a model" to actually doing modelling.

Without going into certain specifics, we were tasked to build a "classification hierarchy" of something - or more specifically, could I build a database (with the implication that the database might be in Microsoft Excel or something similarly unsuitable for the task).

Ontologies are complex beasts to build, especially when one must take into consideration its semantics and expressability (see: [1]). Combined with the fact that you then have relationships, attributes, aspects and a host of other details to take into account, finally topped with mapping (architecting) this to something implementable such as a relationship database structure.

What I have noticed, implementation difficulties aside, is that there seems to be a trend for those providing the requirements to over simplification, typically, dropping of aspects; overcomplication, ie, the concentration on certain specific minutae of details, and a general misunderstanding, or is it an incomprehension of the underlying concepts that need to be modelled.

Indeed it might even be so that the act of modelling reveals too many details about the underlying, and still somewhat undiscovered underlying theory that are just too hard and too complex to initially understand.

As an example, I give the concept of "Personally Identifiable Information" or PII from the area of privacy. What constitutes PII?  Obviously, it is names, identifiers etc? Obviously...? Now what if I stated that we don't need any of that, but maybe just two abstracted locations to uniquely identify people, eg: home and work addresses to the nearest 100m (or even greater). Two items of data that might not qualify to be PII under normal conditions conspire together to be PII.  PII is considered one of the central concepts in privacy and yet remains stubbornly elusive to precise definition.

My next point regarding modelling is the lack of analysis that is made. Let's start with a few definitions: If I draw something, I'll call it a picture. If I give some semantics (maybe formally) then we can call it a diagram. If I describe some system in terms of those diagrams I'm actually going through the process of modelling, but still I don't have a model until I can use those diagrams to actually say something about the thing or system I have described. If we have procedures and techniques for analysing the information contained within those diagrams then I have a model. Until then we're just drawing pictures...

Diagrams + Analysis = Model

Aside: A diagram could also be textual as well as pictorial, or a heterogeneous combination of both.

So, given the ontologies that I (or we) have been developing, do we have methods of analysis associated with those, and if now, why are we actually going through this procedure? Now, one could argue that the act of trying to formally specify an ontology provides some valuable insights into the underlying theory but the final outcomes still needs to be used and provide value in its application.

I'm giving a course on conceptual modelling next week, should be interesting to place the participants actually in the situation where they need to think more about the concepts, the underlying semantics and theory rather than the modelling language itself [2] or some bizarre implementation. Always a revealing course to run...

References:
[1] The superb, Description Logic Complexity Navigator
[2] Alex Bell (2004). Death by UML Fever. ACM Queue. Volume 2 Issue 1, March 2004

Conferences

Always good to start a year off with a few conferences to be actively involved in:

• 7th International Conference on the Theory and Applications of Diagrams 2012

• VL/HCC 2012 : IEEE Symposium on Visual Languages and Human-Centric Computing

•  2012 International Workshop on Visual Languages and Computing 

• The Sixth International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies UBICOMM 2012

And for each a short summary of their content:


Diagrams 2012:

Diagrams is the only conference series that provides a united forum for all areas that are concerned with the study of diagrams, including architecture, art, artificial intelligence, cartography, cognitive science, computer science, education, graphic design, history of science, human-computer interaction, linguistics, logic, mathematics, philosophy, psychology, and software modelling. The conference attracts a large number of researchers from virtually all these related fields, positioning Diagrams as a major international event in the area.

VL/HCC 2012:

From the beginning of the computer age, people have sought easier ways to learn, express, and understand computational ideas. Whether this meant moving from punch cards to textual languages, or command lines to graphical UIs, the quest to make computation easier to express, manipulate, and understand by a broader group of people is an ongoing challenge.

VLC 2012:

Visual languages mediate human and computer interaction. For some visual languages this mediation is straightforward; using a mouse to access a drop-down menu is well-known to computer users. For others, this mediation can be enriched via sketch and gesture recognition. This is made possible by advances in commodity hardware. More formal visual languages allow experts to accurately specify complex systems, such as software architecture or chemical molecules. A visual language can also encompass complex human-computer interaction such as navigating a set of semantically linked videos. Indeed, precision of semantics underlies visual languages and computation. 

UbiCOMM 2012:

The rapid advances in ubiquitous technologies make fruition of more than 35 years of research in distributed computing systems, and more than two decades of mobile computing. The ubiquity vision is becoming a reality. Hardware and software components evolved to deliver functionality under failure-prone environments with limited resources. The advent of web services and the progress on wearable devices, ambient components, user-generated content, mobile communications, and new business models generated new applications and services. The conference makes a bridge between issues with software and hardware challenges through mobile communications.