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

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

How much data?!?!

I took part as one of the speakers in a presentation about analytics today; explaining how data is collected through instrumentation of applications, web pages etc, to an audience who are not familiar with the intricacies of data collection and analytics.

We had a brief discussion about identifiers and what identifiers actually are which was enlightening and hopefully will have prevented a few errors later on. This bears explaining briefly: an identifier is rarely a single field, but should be considered any one of the subsets of the whole record. There are caveats there of course, some fields can't be used as part of some compound identifier, but the point here was to emphasis that you need to examine the whole record not just individual fields in isolation.

The bulk of the talk however introduced from where data comes from. For example if we instrument an application such that a particular action is collected, then we're not just collecting an instance of that action but also whatever contextual data provided by the instrumentation and the data from the traffic or transport layer. This came as a surprise that there is so much information available via the transport/traffic layers:

Said meta-data includes location, device/application/session identifiers, browser and environment details and so on, and so on...

Furthermore data can be cross-referenced with other data after collection. A canonical example is geolocation over IP addresses to provide information about location. Consider the case where a user switches off the location services on his or her mobile device; location can still be inferred later in the analytics process to a surprisingly high-level of accuracy.

If data is collected over time, then even though we are not collecting specific latitude-longitude coordinates we are collecting data about movements of a single, unique human being; even though no `explicit' location collection seems to be being made. If you find that somewhat disturbing, consider what happens every time you pay with a credit card or use a store card.

Then of course there's the whole anonymisation process where once again we have to take into consideration not just what an identifier is, but the semantics of the data, the granularity etc. Only then can we obtain an anonymous data set. Such a data set can be shared publicly...or maybe not as we saw in a previous posting.  

Even when one starts tokenising and suppressing fields, the k-anonymity remains remarkably low, typically with more than 70% of the records remaining unique within that dataset. Arguments about the usefulness of k-anonymity notwithstanding - on the other hand it is one of the few privacy metrics we have,

So, the lesson here is rather simple, you're collected a massive amount more than you really think.

The next surprise was how tricky or "interesting" this becomes when developing a privacy policy that contains all the necessary details about data collection, meta-data collection, traffic data collection; and then the uses to which that data is put, whether it is primary or secondary collection and so on.

Modelling Data Flow and Information Channels

Before we delve further into policies and more analysis of our models, I want to first take a small detour and look at the data channels in our models. We earlier explained that we could refine the various classifications on our channels down to fine grained rules, this is one kind of refinement. We can also refine the channel structure itself to make the various "conversations" between components clear.

Firstly, what is a channel? There's the mathematical explanation taken from [1]:

An information channel consists of an indexed family C = { f_i : A_i <-> C} i\in I of infomorphisms with a common codomain C, called the core of the channel.

Phew! Or a more everyday description that an information channel is the conversation between two elements such as persons, system components, applications, servers etc.

We also note that conversations tend to be directed in the direction that the information flows. We generally don't model the ack/nack type protocol communications.

Starting with our model from earlier:

We should and can refine this to explicitly distinguish the particular conversations that occur between the application and the back end.

While the two components communicate all this information, maybe even over the same implementation, we might wish to explicitly distinguish between the primary and secondary information flows. The reason could be due to differing consent mechanisms, or differing processing on the receiving end etc.

In the above we are explicitly denoting two different conversations. These conversations are logically separate and from the information usage point of view.

As we decompose our channels into the constituent, logically separate conversations we are also making decisions about how the system should keep apart the data transported over those conversations. Whether this translates into physical separation or however the logical differentiation is made is an architectural issue modelled and decided elsewhere.

As we shall see later when we decompose the processing elements in our data flow model we can track the flows and where those flows meet, diverge, cross-reference and infer points of possible contamination.


References:

[1] Barwise and Seligman. (1997) Information Flow. Cambridge University Press.

Anatomy of an Application's Dataflows

To evaluate privacy in the context of an application we must understand how the information flows between the user, the application, the external services the application uses and any underlying infrastructure or operating system services.

We can construct a simple pattern* to describe this:

Obviously the User is the primary actor in all of this, so that becomes the starting point for the collection of data, which then flows via the application itself in and out of the operating system and towards whatever back-end services, either provided for the application specifically or via some 3rd party, the application requires.

Note that in the above we define a trust boundary (red, dashed line) around the application - this denotes the area inside of which the user has control over their data and confidence that the data remains "safe".

Each data-flow can be, or must be, controllable by the user through some consent mechanism: this might be presentation of a consent text with opt-in/out or a simple "accept this or don't continue installing the application"-type consent.

We then consider the six data-flows and their protection mechanisms:

Data Flow "U"  (User -> Application)

• This ultimately is the user's decision over what information to provide the application, and even whether the user installs or even runs the application in the first place. If anything then ensuring that the information collected here is relevant and necessary to the application's experience. 
• Understanding the totality of data collected including that from additional sources and internal cross-referencing is critical to understanding this data-flow in its fullest context.

Data Flow "P" (Application -> Back-end Services)

• This is the primary flow of data - that is the data which the application requires to function. 
• The data here will likely be an extension of the data supplied by the user; for example, if the user uploads a picture, then the application may extend this with location data, timestamps etc.
• The control here is typically embedded in the consent that the user agrees to when using the application for the first time. These consents however are often extended over other data flows too which makes it harder for the user to properly control this data flow
• For some applications this data flow has to exist for applications to function.

Data Flow "S" (Application -> Back-end Services)

• This is the secondary flow of data, that is data about the application's operations.
• The control over this flow is typically embedded in the first time usage consent as data flow "P", but the option to opt-in/out has to be given specifically for this data collection, along with the usage of this data.
• The implementation of this control may be application specific or centralised/federated over the underlying platform.
• The data collected over here is not just from the application itself but may also include some data collected for primary means as well as any extended data collected from the infrastructure.

Data Flow  "3" (Application -> 3rd Parties)

• Primarily we mean additional support functions, eg: federated login, library services such as maps and so on.
• This data flow need to be specifically analysed in the context in which it is being used but would generally fall under the same consents and constraints as data flow "P".

Data Flows "O_in" and "O_out" (Application <-> O/S, Infrastructure)

• The underlying platform, frameworks and/or operating system provide may services such as obtaining a mobile device's current location or other probe status, services such as local storage etc.
• Usage of these services needs to be informed to the user and controlled in both directions, especially when contextual data from the application is supplied over data flow "O_in", eg: storage of data that might become generally available to other applications on the device
• Collection of data over "O_out" may not be possible to control, but minimisation is always required due to the possibilities that data collected over "O_out" is forwarded in some forward over the data flows "P", "S" and "3".
• Usually the underlying libraries and functionality of the platform are provided in the application's description before installation, eg: this application uses location services; though rarely is it ever explained why.

Any data-flow which crosses the trust boundary (red, dashed line) must be controllable from the user's perspective so that the user has a choice of what data leaves their control. Depending upon the platform and type of application this boundary may be wholly or partially inside the actually application process itself - care must be taken to ensure that this boundary is as wide as possible to ensure that the user does have trust in how that application handles their data.

The implementation of the control points on each of the data flows as has been noted, may be application specific or centralised across all applications. How the control is presented is primarily a user-interface manner and what controls and the granularity of those controls a user-experience manner.

The general pattern here is for each data-flow that crossed the trust boundary, a control point must be provided in some form. At no point should the user ever have to actually run the application or be in a state where information has to be sent over those data-flows without the control point being explicitly set.

So this constitutes the pattern for application interaction and data-flow; specific cases may have more or less specific data-flows as necessary.

Additional Material:

* There's a very good collection of patterns here at Privacy Patterns, though I've rarely seen patterns targeted towards the software engineer and in the GOF style, which is something we really do need in privacy! Certainly the patterns described at Privacy Patterns can be applied internally to the data-flow pattern given here - then we start approaching what we really do need in privacy engineering!

Big Metadata

One of the issues I see with auditing systems for privacy compliance is actually understanding what data they are holding. Often it is the case that the project teams themselves don't understand their databases and log files sufficiently. Worse is that misinterpretation of the NoSQL and BigData approaches have left us in a situation where schemata can be forgotten - or at least defined implicitly at run-time. The dogma is that relational databases have failed and all this "non-agile", predefined, waterfall, defined schemata stuff is a major part of this.

Losing all this information about types and semantics is a huge problem because no longer can be fully sure of the consistency and integrity of the data and the relationships of that data to other objects and structures.

We are also then losing the opportunity to add additional information in the form of aspects to the data, for example, security classifications, broad usage classifications, and so on. This leads to embedding much of the information about the data statically into the algorithms that operation over that data; which in turn hides the meaning of the data away from the data itself.

I think this article entitled "Big Data success needs Big Metadata" by Simon James Gratton of CapGemini sums it quite quite well: forgetting about the meaning of data will seriously compromise our ability to understand, use and integrate the data in the first place!

To achieve this, good old fashioned data classification and cataloguing is required. Ironically this is exactly the stuff that database developers used to do before the onset of the trend to making everything schema-free.

Together with suitably defined aspects and ontologies that describe information (meta-information?) in much the same way as the OMG's MOF with additional structure and semantics we already have much, if not all, of the required infrastructure.

Then the process side of things needs to ensure that development of systems, services, analytics and applications integrates with this - in that whatever data they store (locally or in the cloud) gets recorded (and updated!). That's probably the hardest part!

See also:

• Metadata helps make data discoverable and accessible. Irfan Khan. IT World.  August 02, 2012 
• Metadata, Big Data, and the Financial Sector  Angela Guess on April 26, 2012. SemanticWeb.Com
• The MetaData Universe. Mervin Mooi. Web Business Intelligence. Feb 8, 2013

Tutorial: Tracking

Tracking and anonymisation are two critical aspects of information privacy and often quite misunderstood. We established what is meant by Personally Identifiable Information (PII) earlier but now I wish to progress a little further and discuss identifiers, tracking and anonymisation of data sets.

• A data set is a collection of records containing information. 
• A record is usually made of up of a number of individually named fields, though it could be a more complex structure such as a graph or tree for example. 
• Each field contains some data from something as simple as a binary value, to a name, a number, a time-stamp, a picture or a video etc.
• These fields are usually typed, for example: string, boolean, integer, VARCHAR, blob, media, something from the dc: namespace etc. However a field containing, say, a string could be further interpreted as a telephone number or a name. Some typing systems make distinctions such as a field storing a string to be interpreted as a telephone number explicit, others this is left to the interpretation by the reader.
• Some fields in the data set's records are used to identify either aspects of that record, to correlate records together or to link to some external data. These fields we term identifiers.

Tracking is the ability to correlate information; often made in conjunction with some criteria such as a temporal, device or user identity dimension. The correlation is made according to one or more fields which act as identifiers, for example, user ID fields or IP addresses. The point is that we have a consistent identifier (or key) over the sets of data that we wish to relate or consider together. For example, given the following data set collected from some music service:

Key	UserID	Artist
1	Alice	Queen
2	Alice	Queen
3	Bob	Rush
4	Bob	Rush
5	Eve	Spice Girls
6	Alice	Queen
7	Bob	Genesis
8	Eve	Metallica

From this log we might want to track user behaviour to understand what music a particular user of our system likes listening to: we can see that Alice likes Queen, Bob is a fan of progressive rock and Eve has varied taste in music. This is possible because we have a consistent identifier (UserID field)  that any two instances of an entry refer to the same entity - the user. Furthermore the Key field allows us to make a distinction between two instances containing the same information which enables us to count individual entries: Alice played three songs, Bob three and Eve two. Additionally the Key field in this example may also have a temporal dimension such that we can infer the order in which songs were played.

The only required property of the identifier is that it be consistent over the records we wish to track. So if we change the above identifiers to their SHA-256 representations ("Alice" becomes 3bc51062973c458d5a6f2d8d64a023246354ad7e064b1e4e009ec8a0699a3043 ) we do not compromise our ability to track the behaviour of a user over that data set:

Key	UserID (SHA-256 hashed)	Artist
1	3bc5106...0699a3043	Queen
2	3bc5106...0699a3043	Queen
6	3bc5106...0699a3043	Queen

We can still make the same anlayses: 3bc...3043 likes Queen and played songs from that band three times. We have however obfuscated the user identifier, assuming that the user identifier had any meaning in the first place.

This latter point is important to note as it depends upon how we interpret the identifier. For example: 3bc5106...99a3043 has no "meaning" other than it being something we use to track over. The string "Alice" may have a meaning..."Alice" as 5 ASCII or Unicode characters are just as meaningful as our hashed value above. However "Alice" itself according to the typing information and usage in the data set is the identifier of the user in some system. Furthermore according to some interpretations "Alice" is a female name and this particular interpretation of this identifier's meaning might have additional impact.

In the above case we stated nothing about whether the strings "Alice", "Bob" and "Eve" actually were people's names nor whether these were linkable to real and unique people.We never really stated the semantics of the UserID field quite deliberately.

An example we can use to demonstrate this is that of the common practice of email-as-identifier. You can use your email address instead of (or as a) user name in  Facebook, G+ and other services. The following string can be interpreted in a number of (potentially) simultaneous ways:

zarquon.123@somesite.zyx

• a string of 25 ASCII characters
• an email address of a person/company/entity
• a user ID for some service
• a unique identifier linkable to a real person

and so on...

From a tracking point of view, "zarquon.123@somesite.zyx" has just as much meaning as "Alice" or "3bc5106...0699a3043" etc.

We however are now moving into the interpretation of the contents of a field and the semantics beyond that of an identifier which itself is independent of the actual form of the identifier itself. This leads us to the notion of linkability which we shall discuss later.

Tracking as we have hinted can be made more sophisticated through the addition of other identifiers such as IP addresses, device identifiers etc but this just makes the partitioning of the data set more complex and expand the possible internal cross-correlations but doesn't change the basic principle of tracking.

Some identifiers are more useful than others and much of this depends upon how linkable an identifier is to a person or device. For example, device identifiers such as IMEI are particularly useful, email addresses link to persons, IP addresses link to sometimes single computer or devices, sometimes multiple and can also be mapped to locations through the process of geolocation.

So that very briefly introduces what tracking is: simply the ability to correlate and collate sets of data together. The next step is to perform specific analyses over that data and to map those results back to the business and customer.

Nouvelle cuisine meets big data?

After the post Christmas/holidays eating binge and the inevitable New Year's resolution of dieting, it seems like this article that appears in the Visual Business Intelligence blog by Stephen Few is more than a little apt.

An analogy is made between the fast food and slow food movements (hence the 'apt' earlier) and he article presents the argument that taking a much more measured, "slower" approach to data collection is the way forward.

As the slow food movement emphasizes the preparation, cooking, eating and enjoyment of food (as opposed to the idea of fast food), slow data emphasizes the same when collecting, storing, processing and analysing data. Given the rush to collect as much data as possible with often scant regard to the content, identification and value I can see the appeal of this. Regarding this latter point, an article in The Register: Craptastic analysis turns 2.8 zettabytes of Big Data into 2.8 ZB of FAIL - dramatically explains this.

Taking a moment to really think about what we are gathering, why we are gathering and what we intend to do with the data, other than the attempt construct the perfect advertisement, then we will see that we actually need very little data. This is almost an antithesis to the 'capture and collect everything everywhere just in case we might need it later' approach.

And then with that carefully chosen, semantically well-defined data we are able to process and analyse and enjoy the results of our analysis. The enjoyment of data here being that what is understood from the data and that this understand be more relevant and useful to our business and to our customers.

Taking a slow approach to digesting our data has a number of other side-effects, a few being that the amount of data we store is less, the amount of analytical infrastructure will be less and the value to the consumer (and the business) will be significantly greater as we will not have to sift through billions of uninteresting and irrelevant data-points. The effects upon areas such as privacy should be self-explanatory...indeed isn't this the true goal of the privacy advocates?

A slow data approach might just solve many of the issues we see with data: semantics, isolation, privacy, data storage, analytics, just to mention a few.

Indeed as the slow food movement has as its objectives to enjoy food, so slow data might just be the way through which we appreciate the information, knowledge and wisdom in our big data.

Are we in effect embodying the ideals of nouvelle cuisine as applied to data? A rejection of excessive complication, reducing the processing to preserve the natural information content, the freshest and best possible ingredients, smaller data sets, modern processing techniques, innovation and invention as being drivens because of the data collection (and not because they might happen if we collect data) - the analogies between slow food, nouvelle cuisine and slow data are abundant.

Food for thought...almost literally.

Understanding PII

The most important question in data management related to privacy is when a given set of data contains personally identifiable information (PII). While PII is fairly well defined (maybe not a strict formal defintion), often the question of what constitutes PII and how to handle it remains. In this article I intend to describe some notions on the linkability and tracability of identifiers and their presence in a data set.

It is worth mentioning that the definition of PII is currently being addressed by the EU Article 29 Working Party which will eventually bring additional clarification at a legal level beyond that existing the the current privacy directives. Ultimately however, the implementation of privacy is in the hands of software and system architects, designers and programmers.

I'll start with a (personal) definition: data is personally identifiable if, given any record of data, are there fields that contain data that can be linked with a unique person, or, a sufficiently small group with a common, unique attribute or characteristic.

We are required then to look at a number of issues:

• what identifiers or identifying data is present
• how linkable the data is to a unique person
• how traceable a unique person is through the data set

Much is based upon the presence of identifiers in a data set and the linkability of those identifiers. For example, the presence of user account identifiers, social security numbers are very obviously in a one-to-one correspondence with a unique person and thus are trivially linkable to a unique user. Identifiers such as IMEI or IP addresses do not have this one-to-one correspondence. There are some caveats with situations such as  when one user account or a device is shared or used occasionally (with permission perhaps) by more than one person.

The notion of a unique person does not necessarily mean that an actual human being can be identified but rather can be traced, unambiguously through the data. For example, an account identifier (eg: username) identifies a unique person but not a unique human being - this is an important, if subtle distinction.

We can construct a simple model of identifiers and how these identifiers relate to each other and to "real world" concepts - some discussion on this was made in earlier articles. These models of identifiers and their relationships and semantics are critical to correct understanding of privacy and analysis of data. Remarkably this kind of modelling is very rarely made and very rarely understood or appreciated - at least until time comes to cross-reference data and these models are missing (cf: semantic isolation).

Example Semantic Model of Identifier Relationships

Within these models as seen earlier, we can map a "semantic continuum" from identifiers that are highly linkable to unique and even identified persons to those which do not.

Further along this continuum we have identifiers such as various forms of IMEI, telephone number, IP addresses and other device identifiers. Care must be made in that while these identifiers are not highly linkable to a unique person, devices and especially mobile devices are typically used by a single unique person leading to a high degree of inferred linkability.

Device addresses such as IP addresses have come under considerable scrutiny regarding whether they do identify a person. In cases where an IP address of a router has been used to identify is someone has been downloading copyrighted or other illegal material is problematical for the reasons described earlier regarding linkability. In this specific case of IP addresses, network address translation, proxies and obfuscation/hiding mechanisms such as Tor complicate and minimise linkability.

As we progress further along we reach the application and session identifiers. Certainly application identifiers if they link to applications and not individually deployed instances of applications are not PII unless the application has a very limited user base: an example of a sufficiently small,  group with common characteristics. For example, an identifier such as "SlighlyMiffedBirdsV1.0" used across a large number of deployments is very different from "SlighlyMiffedBirdsV1.0_xyz" where xyz is issued uniquely to each download of that application. Another very good example of this kind of personalisation of low linkability identifiers is the user agent string used to identify web browsers.

Session identifiers ostensibly do not link to a person but can reveal a unique person's behaviour. On their own they do not constitute PII. However session identifiers are invariably used in combination with other identifiers which does increase the linkability significantly. Session identifiers are highly traceable in that sessions are often very short with respect to other identifiers - capture enough sessions and one can fingerprint or infer common behaviour of individual persons.

When evaluating PII, Identifiers are often taken in isolation and analysis made there. This is one of the main problems in evaluating PII: Identifiers rarely exist in isolation and a combination of identifiers together reveals a unique identity.

Just dealing with identifiers alone, and even deciding what identifiers are in use provides the core of deciding whether a given data set PII. However identifiers provide the linkability, they do not provide tracability which is given through the temporal components which is often, if not, invariably present in data sets. We will deal with other dimensions of data later where we look deeper into temporal, location and content data. Furthermore we will also look at how data can be transformed into other types of data to improve traceability and linkability.

Explaining Primary and Secondary Data

One of the confusing aspects of privacy is the notion of whether something is primary or secondary data. These terms emerge from the context of data gathering and processing and are roughly defined thus:

• Primary data is the data that is gathered for the purpose of providing a service, or, data about the user gathered directly
• Secondary data is the data that is gathered  from the provision of that service, ie: not by the user of that service, or, data about application gathered directly

Pretty poor definitions admittedly and possibly overly broad given all the contexts in which these terms must be applied. In our case we wish to concentrate more on services (and/or applications) that we might find in some mobile device or internet service.

First we need to look more at the architectural context in which data is being gathered. At the highest level of abstraction applications run within some given infrastructure:

Aside: I'll use the term application exclusively here, though the term service or even application and service can be substituted.

Expanding this out more we can visualise the communication channels between the "client-side" and "server-side" of the application. We can further subdivide the infrastructure more, but let's leave it as an undivided whole.

In the above we see a single data flow between the client and server via the infrastructure (cf: OSI 7-layer model, and also Tanenbaum). It is this data-flow that we must dissect and examine to understand the primary and secondary classifications.

However the situation is complicated as we can additionally collect information via the infrastructure: this data is the behaviour of the infrastructure itself (in the context of the application). For example this data is collected via log files such as those found in /var/log on Unix/Linux systems, or the logs from some application hosting environment, eg: Tomcat etc. This latter case we have indirect data gathering and whether this falls under primary or secondary as defined above is unclear, though it can be though of secondary, if both our previous definitions of primary and secondary can be coerced in a broader "primary" category. (If you're confused, think of the lawyers...)

Let's run through an example: an application which collects your location and friends' names over time. So as you're walking along, when you meet a friend you can type their name into the app* and it records the time and location and stores this the cloud (formerly known as a "centralised" database). Later you can view who you met, where and at what time in all sorts of interesting ways, such as on a map. You can even share this to Facebook, Twitter or one of the many other social networking sites (are there others?).

Aside: Made with the excellent Balsamiq UI mock-up software.

The application stores the following data:

{ userId, friendsName, time, gpscoordinates }

where userId is some identifier that you use to login to the application and later retrieve your data. At some point in time we might have the following data in our database:

joeBloggs, Jane, 2012-09-10, 12:15, 60°10′19″N 24°56′29″E
joeBloggs, Jack, 2012-09-10, 12:18,  60°10′24″N 24°56′32″E
jane123, Funny Joe, 2012-09-10, 12:18, 60°10′20″N 24°56′21″E

This set of data is primary - it is required for the functioning of the application and is all directly provided by the user.

By sending this data we can not avoid using whatever infrastructure is in place. Let's say there's some nice RESTful interface somewhere (hey, you could code this in Opa!) and by accessing that interface the service gathers information about the transaction which might be stored in a log file and look something like this:

192.178.212.143, joeBloggs, post, 2012-09-10, 12:14:34.2342
64.172.211.10, arbunkleJr, post, 2012-09-10, 12:16:35.1234
192.178.212.143, joeBloggs, get, 2012-09-10, 12:16:37.0012
126.14.15.16, janeDoe, post, 2012-09-10, 12:17:22.0506

This data is indirectly gathered and contains information that is relevant to the running of infrastructure.

The two sets of data above are generally covered by the terms and conditions of using that application or service. These T&C's might also include a privacy policy explicitly or have a separate privacy policy additionally to cover disclosure and use of the information. Typical uses would cover authority requests, monitoring for misuse, monitoring of infrastructure etc. The consents might also include use of data for marketing and other purposes for which you will (or should) have an opt-out. The scope of any marketing request can vary but might include possibilities of identification and maybe some forms of anonymisation.

Note, if the service provides a method for you to share via Facebook or Twitter then this is an act you make and the provider of the service is not really responsible for you disclosing your own information publicly.

So that should explain a little about what is directly gathered, primary information and indirectly gathered information. Let's now continue to the meaning of secondary data.

When the application is started, closed or used we can gather information about this. This kind of data is called secondary because it is not directly related to the primary purpose of the application nor of the functioning of the infrastructure. Consent to collect such information needs to be asked for and good privacy practice suggests that this should be disabled by default. Some applications or services might anonymise the data in the opt-out situation (!). Secondary data collection is often presented as an offer to help with improving the quality of application or service. The amount of information gathered varies dramatically but generally application start, stop and abnormal exit (crashes) are gathered as well as major changes in the functionality, eg: moving between pages or different features. In the extreme we might even obtain a click-by-click data stream including x,y-coördinates, device characteristics and even locations from a gps.

Let's say our app gathers the following:

192.178.212.143, joeBloggs, appStart, 2012-09-10, 12:14:22.0001, WP7, Onkia Luna 700, 2Gb RAM, 75%free, 14 processes running, started from main screen, Elisa network 3G, OS version 1.2.3.4, App version 1.1
192.178.212.143, joeBloggs, dataEntryScreen, 2012-09-10, 12:14:25.0001
192.178.212.143, joeBloggs, gotGPSlocation, 2012-09-10, 12:14:26.0001, 50m accuracy, 3G positioning on, 60°10′19″N 24°56′29″E
192.178.212.143, joeBloggs, dataPosted, 2012-09-10, 12:14:33.2342, 3G data transfer, 2498 bytes
192.178.212.143, joeBloggs, mapViewScreen, 2012-09-10, 12:15:33.2342
192.178.212.143, joeBloggs, dataRequestAsList, 2012-09-10, 12:16:23.1001

What we can learn from this is how the application is behaving on the device and how the user is actually using that application. From the above we can find out what the status of the device was, the operating system version, type of device, whether the app started correctly in that configuration, from where the user started the app, which screen the app started up in, the accuracy and method of GPS positioning and so on.

So far there is nothing sinister about this, some data is required for the operation of the application and stored "in the cloud" for convenience, some data is collected by the infrastructure as part of its necessary operations and some data we voluntarily give up to help the poor application writers improve their products. And we (the user) consented to all of this.

From a privacy perspective these are all valid uses of data.

Now the problems start in three cases:

• exporting to 3rd parties
• cross-referencing
• "anonymisation"

 The above data is fantastic for marketing - a trace of your location over time plus some ideas about your social networking (even if we can't directly identify who "Jane" and "Jack" are .... yet!) provides great information for targeted advertising. If you're wondering the above coördinates are for Helsinki Central Railway Station...plenty of shops and services around there that would like your attention and custom.

How the data is exported to the 3rd party and at what level of granularity is critical for trust in the service. Abstracting the GPS coordinates by mapping to city area or broader plus removal of personally identifiable information (in this case we remove the userID...hashing may not be enough!). The amount of data minimisation here is critical, especially if we want to reduce the amount of tracking that 3rd parties can make. In the above example probably just sending the location and retrieving an advertisment back is enough, especially if it is handled server-side so even the client device address is hidden.

Cross-referencing is the really interesting case here. Given the above data-sets can we deduce "Joe's" friends...taking the infrastructure log file entries:

joeBloggs, Jane, 2012-09-10, 12:15, 60°10′19″N 24°56′29″E
jane123, Funny Joe, 2012-09-10, 12:18, 60°10′20″N 24°56′21″E

and cross-referencing these with the secondary data:

192.178.212.143, joeBloggs, dataEntryScreen, 2012-09-10, 12:14:25.0001
192.178.212.143, joeBloggs, gotGPSlocation, 2012-09-10, 12:14:26.0001, 50m accuracy, 3G positioning on, 60°10′19″N 24°56′29″E
192.178.212.143, joeBloggs, dataPosted, 2012-09-10, 12:14:33.2342, 3G data transfer, 2498 bytes

we can deduce that user joeBloggs was in the vicinity of user jane123 at 12h15-12h18. Furthermore looking at the primary data:

joeBloggs, Jane, 2012-09-10, 12:15, 60°10′19″N 24°56′29″E
jane123, Funny Joe, 2012-09-10, 12:18, 60°10′20″N 24°56′21″E

we can see that joeBloggs mentioned a "Jane" and jane123 mentioned a "Funny Joe" at those times. Now we might be very wrong in the next assumption but I think it is reasonably safe to say, even when we only have a string of characters "Jane" as an identifier we can make a very reasoned guess that Jane is jane123. Actually even the 4 (ASCII) characters that just happen to spell "Jane" aren't even required, though it does help the semantic matching.

This kind of matching and cross-referencing is exactly what happened in the AOL Search Data Leak incident. Which neatly takes me to anonymisation where just because some identifier is obscured doesn't mean that the information doesn't exist.

This we often see with hashing of identifiers, for example, our app designer has been reading stuff about privacy by design and has obscured the identifiers in the secondary data using a suitably random salted hash of sufficient length to be unbreakable for the next few universes - and we've salted the IP address too!

00974ca1582cc3fc23164f93a78c647059d4c3bb170592d1385a1f777f18491f,d4c53838904f4405893b9ea134c747a2b2e7a2e9341084387285ba5999ad894f , appStart, 2012-09-10, 12:14:22.0001, WP7, Onkia Luna 700, 2Gb RAM, 75%free, 14 processes running, started from main screen, Elisa network 3G, OS version 1.2.3.4, App version 1.1
00974ca1582cc3fc23164f93a78c647059d4c3bb170592d1385a1f777f18491f, d4c53838904f4405893b9ea134c747a2b2e7a2e9341084387285ba5999ad894f, dataEntryScreen, 2012-09-10, 12:14:25.0001
00974ca1582cc3fc23164f93a78c647059d4c3bb170592d1385a1f777f18491f, d4c53838904f4405893b9ea134c747a2b2e7a2e9341084387285ba5999ad894f, gotGPSlocation, 2012-09-10, 12:14:26.0001, 50m accuracy, 3G positioning on, 60°10′19″N 24°56′29″E
00974ca1582cc3fc23164f93a78c647059d4c3bb170592d1385a1f777f18491f, d4c53838904f4405893b9ea134c747a2b2e7a2e9341084387285ba5999ad894f, dataPosted, 2012-09-10, 12:14:33.2342, 3G data transfer, 2498 bytes
00974ca1582cc3fc23164f93a78c647059d4c3bb170592d1385a1f777f18491f, d4c53838904f4405893b9ea134c747a2b2e7a2e9341084387285ba5999ad894f, mapViewScreen, 2012-09-10, 12:15:33.2342
00974ca1582cc3fc23164f93a78c647059d4c3bb170592d1385a1f777f18491f, d4c53838904f4405893b9ea134c747a2b2e7a2e9341084387285ba5999ad894f, dataRequestAsList, 2012-09-10, 12:16:23.1001

Aside: Here's a handy on-line hash calculator from tools4noobs.

We still have a consistent hash for an IP address and user identifier so we can continue to track albeit without being able to recover who made and from where come the request. Note however the content line of the first entry:

WP7, Onkia Luna 700, 2Gb RAM, 75%free, 14 processes running, started from main screen, Elisa network 3G, OS version 1.2.3.4, App version 1.1

How many Onkia Luna 700 2Gb owners running v1.2.3.4 of WP7 with version 1.1 of our application are there? Take a look at Panopticlick's browser testing to see how unique you are based on web-browser characteristics.

And then there are timestamps...let's go back to cross-referencing against our primary data and infrastructure log files and we can be pretty sure that we can reconstruct who that user is.

We could add in additional randomness by regenerating identifiers (or the hash salt if you like in some cases) for every session, this way we could only track over a particular period of usage.

So in conclusion we have presented what is meant by primary and secondary data, stated the different between directly gathered data and indirectly gathered data and explained some of the issues relating to the usage of this data.

Now there are some additional cases such as certain kinds of reporting, for example, music player usage and DRM cases which don't always fall easily into the above categories unless we define some sub-categories to handle this. Maybe more of that later.


*apps are considered harmful

Information engineers wanted

Continuing on the theme of semantic isolation and data siloing* somewhat, I was listening to the Diane Rhem Show on US talk radio station NPR via Finland's YLE Mondo. Today's programme "New Voter ID Laws and the 2012 Elections" was about the USA's law regarding voter eligability and the problems of keeping track of who is and who isn't allowed to vote in certain elections (2012 presidential election being of particular concern).

One part of the programme concentrated on the difficulty of cross-referencing between voting lists in states, counties and various government bodies such as the driver and vehicle licensing (DMV). One of the major problems is that actually identifying and subsequently cross-refenencing people by ID numbers (plural!), by name (due to misspellings, usually involving punctuation) or by address and location. Making this even more interesting is the temporal aspect that over time people move and records in differing data-sets end up overlapping or being temporally disjoint.

One of the current solutions is to use what was termed "election geeks" - people with highly detailed knowledge of voter lists and how to match records in different formats from different states and agencies together. That is a group of people who are highly skilled in performing the manual task of deisolating the semantics of each data set (of voters) and matching these together.

One of the presenters remarked that while a technological solution was necessary we need more so called election geeks. Putting it another way, we need more highly skilled engineers specialising in information, information theory, semantics and ultimlately semiotics. What a great idea!

*this links to part 1, parts: 2 and 2 and a half.

Semantic Isolation (Pt.2)

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

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

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

• linkability of identifiers
• interoperability of semantics

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

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

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

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

The main problems regarding linkability are:

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

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

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

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

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

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

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

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

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

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

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

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

Dimensional Analysis of Information

I’ve been looking at dimensional analysis as a technique to use for analyzing information flows, specifically for privacy.

After developing various taxonomies for information classification and some of the superstructure behind these (see here). One of the problems we have seen is trying to evaluate information content from ontologies and data schemata and deciding whether in ontology X, the field “name” has the same (or similar) semantics to a similarly named field in ontology Y.

Inspired by the technique of dimensional analysis, one idea is to consider each ontology as you would a system of units of measurement, eg: imperial units versus metric units. What dimensional analysis does is to abstract away from the units of measurement and into a small set of base or fundamental aspects. Typically these are length, mass and time denoted [L][M] and [T].

For example, acceleration has dimensions [L][T]-2  which using a system of measurements might be expressed as: metres per second per second or furlongs per day per aeon (just to mix things up).

When working with information systems and especially in the case of privacy where we need to classify information we can construct a set of “dimensions”. Choice of these is somewhat arbitrary – or at least they should have some aspect of orthogonality (I said this was inspired by dimensional analysis!).

The dimensions I chose were: Personal, Financial, Health, Time, Location, Identity and Content. 

Aside: To save on space an hint to the dimensional analysis inspiration, I'll use the first letter of the dimension name inside square brackets [ and ]...

We can have huge debates (and we did) about whether these are truly orthogonal and what happens when data elements or types are mapped to more than one 'dimension' - I don't think it matters too much at the moment, so let's put some of those difficulties aside.

Actually each of these is a top-level class in a taxonomy of information classification. For example, dimension the [P] breaks down into Demographics ([P_D]) and Contact ([P_C]), other classes follow similarly – as shown in the diagram below:

Information Type Taxonomy

Given a data schema we can map this schema into its dimensions in much the same was as done with physical quantities, for example the schema:

UserID x DeviceID x CellID x Timestamp x Age

Would be mapped to: [I]3[T][P]   meaning 3 units of identifiers, one of time and one of personal information. Actually as I stated earlier we actually have a hierarchy of dimensions so we might break down to: [I_P][I]2[T][P_D]  where [I_P] is a personal identifier and [P_D] is demographics, each being a sub classification of the [I] and [P].

The kinds of analysis that can be made are the quick identification of critical information content issues, such as in the above case we have a mix of identities which allows for potentially very precise identification. We have time involved which might allow profiling or tracking and an element of personal (demographic) information.

Furthermore we even have the chance that one identifier can be mapped to a location: CellIDs can easily be transformed into GPS coordinates and over time fairly easily be triangulated, especially when in an area densely populated by mobile base stations. Actually the above example could be mapped as [I]2[L][P] and indeed for a given data-schema being expressably in more than one dimensional form does raise some interesting concerns.

If we have some functions that process data, say a function that anonymises identities (we can have the discussion what anonymisation means later – please don’t mention hashing functions!) then application of this might result in our original dimensions [I]3[T][P] being mapped via that anonymisation function to [I]2[T][P] – an improvement in terms of moving towards anonymity maybe.

And so on....now whether this is really is dimensional analysis is another thing altogether, I doubt it largely in the current form and certainly I've made no major effort into properties of dimensional analysis such as commensurability or other mathematical properties. I'm also wondering if that other favorite of mine - entropy - can be put in here somewhere, as a coefficient to the dimension possibly? I think that might be taking things too far and is ultimately confusing concepts.

I've had some successes in terms of applying this to data-flow modelling of information flows and a couple of interesting results when we've discussed things such as legal consents, the application of a content to data and processing of that data. For example, take the humble IP address or CellID from the above example....the dimension of these is [I] (actually I have some subclass of Identity which deals with machine addresses), however both can be mapped to [L] fairly easily. Things such as expressing in a consent that we don't identify the source of information could mean mapping such things to other 'types' in other dimensions and actually end up not preserving privacy or even accidentally revealing more semantically interesting content...

Data-Flows and Measurement of Expectation of Privacy

I've been in a workshop all day about privacy with a mixed audience of legal, marketing and technical people; and its quite interesting to see that we starting to have some convergence on that privacy is more about information itself, the flow of information and the usage of that information within the context of those flows rather than the usual discussion about how to prevent collection of data.

There is relatively little wrong - given the correct context - with data collection, and indeed in many cases it is ineviatable, eg: web server or service access logs. The usage of these logs for system monitoring is the typical scenario, which is a necessary function of actually running those infastructures. The main point here is really aimed at secondary data collection or behavioural data collection scenarios.

So that aside for a moment, we've come to the obvious conclusion that security is a necessary base for privacy, which in turn is a necessary base for trust. We've also discussed the notion of rights and what rights a consumer has over their data, or more correctly, their information.

Which all brings me back to that most of the discussions are touching on the need for an understanding of the flow and measure of information. How do we measure, what do we measure, how much information, is there too much information etc?

Putting this in the context of information management, ontologies/taxonomies of information and data-flow we have the beginnings of a rather elegant framework for understanding the flow of information from this perspective. Sounds close to Nissenbaum's hypothesis on privacy and expectations which is very nice - which is something I've written on before and I guess some of the things here is a development of some thoughts there...

For me this means that some ideas I’ve had of information classification, dimensional analysis and measures (metrics even) are starting to coalesce nicely...quite exciting.

In a panel session a discussion was held on the rights and relationships of privacy to the consumer and started to emphasise on the expectation of privacy based in various scenarios: placing data in the cloud, driving on a public highway and in relation to the latter the case with the US government's regarding the placement of GPS trackers on peoples' cars without their knowledge.

We can construct a data-flow model of this:

          

Over each flow we can measure the amount, sensitivity and type of information - I have no idea what this "number" or even the structure of that "number" might look like, though I do believe that it is certainly measureable, ie: we can take two values and compare them.

A person then assigns or has an expectation of privacy in various situations, if the data-flow exceeds that then there is a privacy issue. So, using some “arbitrary” values for the measures, we might have expectations ‘E’ for each flow:

• E(Person->Cloud) is 7
• E(Person->Highway) is 3
• E(Highway->Government) is 2

The higher the number, the greater amount of information a user is willing to tolerate being communicated over that data-flow.

Then at some point in time’t’ the actual measure ‘M’ of information, maybe something like

• M_t1(Person->Cloud) = 5
• M_t1(Person->Highway) = 2
• M_t1(Person->Cloud) = 4

If for some data-flow ‘d’, at a point in time ‘t’, M_t(d)>E(d) then we have a problem regarding the amount of information being transmitter is greater than the expectations of the user.

Aside: yes, I know using integers to denote amount is fairly naïve, but I’m just trying to get a point across more than anything – I think the structure we’d be working with is some horrible multi-dimensional, tensor/spinor monster….

While the current laws tend to focus on the fact that anything ‘in public’ is ‘public’, Solove, Nissenbaum, Acquisti and others have noted that what happens in public is not always necessarily. As shown in the data-flow above, a person's expectation of privacy towards some cloudified service environment, eg: Google, Nokia etc is very different to their expectation of privacy when driving in their car on public roads. Similarly the information flow between public roads and the government, eg: traffic cameras etc has certain expectations of privacy.

When we have information flow over more than one individual flow, for example, what is the user's expectation of privacy when information about their driving on a public road flows to the government? The case with GPS trackers has shown that there are expectation limits that are different from the individual expectations within the individual flows, for example:

• E(Person->Highway->Government) = 1

What this eventually leads to is that as data-flows get longer and involve more participants the expectation of privacy increases, but in reality beyond one or two steps the visibility of the data-flow diminishes to the user, for example, to where does Google or Facebook send or sell their data? Also how. and could this value be calculated from each of the individual flows? I can imagine that we might even see some kind of power law operating over this too…

Many other questions arise, how do we measure information content – at least in terms of the above channels? What is an information channel? To conclude for the moment, it does appear that we can relatively easily define how to how these measures might behave over a data-flow, the question now remains – and this is the really interesting question – is how to actually construct the measure itself.