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.

Classifying Information and Data Flows

In the previous articles on data flow patterns and basic analysis of a data flow model we introduced a number of classifications and annotations to our model. Here we will explain two of these briefly:

1. Data Flow Annotations
2. Information Classification

Let's examine this particular data flow from our earlier example:

The first thing to notice is the data-flow annotation in angled brackets (mimicking the UML's stereotype notation) denoting the protocol or implementation used. It is fairly easy to come up with a comprehensive list of these, for example as a useful minimum set might be:

• internal - meaning some API call over a system bus of some kind
• http - using the HTTP protocol, eg: a REST call or similar 
• https - using the HTTPS protocol
• email - using email

and if necessary these can be combined to denote multiple protocols or possible future design decisions. Here I've written http/s as a shorthand.

Knowing this sets the bounds on the security of the connection, what logging might be taking place at the receiving end and also what kinds of data might be provided by the infrastructure, eg: IP addresses.

* * *

The second classification system we use is to denote what kinds of information are being carried over each data-flow. Again a simple classification structure can be constructed, for example, a minimal set might be:

• Personal - information such as  home addresses, names, email, demographic data
• Identifier - user identifiers, device identifiers, app IDs, session identifiers, IP or MAC addresses
• Time - time points
• Location - location information of any granularity, typically lat, long as supplied by GPS
• Content - 'opaque' data such as text, pictures etc

Other classes such as Financial and Health might also be relevant in some systems.

Each of the above should be subclassed as necessary to represent specific kinds of data, for example, we have used the class Picture. The Personal and Identifier categories are quite rich in this respect.

Using high-level categories such as these affords us simplicity and avoids arguments about certain kinds of edge cases as might be seen with some kinds of identifiers. For example, using a hashed or so-called 'anonymous' identifier is still something within the Identifier class, just as much as an IMEI or IP address is. 

Note that we do no explicitly define what PII (personally identifiable information) is, but leave this as something to be inferred from the combination of information being carried both over and by the data flow in question.

* * *

Now that we have the information content and transport mechanisms made we can reason against constraints, risks and threats on our system, such as whether an unencrypted transport such as HTTP is suitable for carrying, in this case, location, time and the picture content; or would a secure connection be better? Then there is also the question of whether encrypting the contents and using HTTP?

We might have the specific requirements:

• Data-flows containing Location must be over secured connection
• Secured connections use either encrypted content or a secure protocol such as HTTPS of SFTP.

and translate these into requirements on our above system such as

• The flow to any social media system must be over HTTPS

Some requirements and constraints might be very general, for example

• Information of the Identifier class must be sent over secured connection

While the actual identifier itself might be a short-lived, randomly generated number with very little 'identifiability' (to a unique person), the above constraint might be too strong. Each retrenchment such as this can then be specifically evaluated for the additional introduced risk.

* * *

We have shown here is that by simple annotation of the data flow model according to a number of categories we can reason about what information the system is sending, to whom and how. This is the bare minimum for a reasonable privacy evaluation of any system.

Indeed even with the two above categories we can already construct a reasonably sophisticated and rigorous mapping and reasoning against our requirements and general system constraints. We can even as we briefly touched upon start some deeper analysis of specific risks introduced through retrenchments to these rules.

* * * 

The order in which things are classified is not necessarily important - we leave that to the development processes already in place. Having a model provides us with unambiguous information about the decisions made over various parts of the system - applying the inferences from these is the critical lesson to be taken into consideration.

We have other classifications still to discuss, such as security classifications (secret, confidential, public etc), provenance, usage, purpose, authentication mechanisms - these will be presented in forthcoming articles in more detail.

Constructing these classification systems might appear to be hard word; certainly it takes some effort to implement and ensure that they are active employed, but security standards such as ISO27000 do require this.

Analysing Data Flow Models

In the previous post we introduced a pattern for the data-flows in and out of an application such as those found on your mobile phone or tablet. In this posting I want to expand on this pattern and explore various annotations to help us reason about how our application treats the information flowing through it.

Let's first introduce an example application, a photo sharing application. This app allows you to select a photo on your device and upload it to a social media account. Here's what it looks like to the user on a mobile device with rounded corners (as opposed to square corners which none of them seem to have):

It looks innocent enough but as we know there are many threats to user privacy even in the most innocent looking of places. So let's model what is really happening behind the scenes. We understand so far a number of things: the user supplies content and credentials for the services, these are stored locally for convenience, the app adds meta-data to the picture before uploading and sends information about the app's behaviour to the inventor of the app. We might then construct the following model:

On each of the dataflows we have noted the kind of information transported over those channels and the mechanism of communication. We also note our presumed trust boundary.

What this shows clearly is where data is flowing and by what means. We have for now skipped over the specific or precise meanings of some things hoping that the terms we have used are self-explanatory.

But, now we have formally written we can focus the discussion on specific aspects of the application, for example:

• What mechanisms are being used to store the user ID and password in the "operating system"? Is this storage secure and sandboxed? I.e. how do we increase the area of trust boundary?
• Are the communication mechanisms from the app to the social media and inventor appropriate?
• What infrastructure information is implicitly included over these channels, for example, IP addresses, user agent strings [1] etc?
• Does the app have authorisation to the various channels?
• What is the granularity of the Location data over the various channels?
• What information and channels are considered primary and which secondary?
• Is the information flowing to the inventor appropriate and what is the content?
• What about the EXIF data embedded in the picture?

Generating a formal list of questions from the above is relatively easy and this is exactly how we proceed.

The next questions which follow are related to how we can reduce the amount of information without compromising the application functionality and business model? For example:

• can we reduce the granularity of the Location sent to the social media systems to, say, city level or country level?
• can we automatically remove EXIF data?
• do we allow the app to work if the operating system's location service is switched off or the user decides not to use this?

And so on...Finally  we get down to the consent related questions

• What does the user see upon first-time usage of the app? What do they have to agree to?
• Do we tell the user what underlying services such as GPS we're using as part of the application
• Secondary data collection opt-out
• For what reason is the data being collected over both primary and secondary channels

And so on again.

What we have done is set the scene, or, circumscribed what we need to investigate and decide upon. Indeed at some level we even have the means to measure the information content of the application and even the extent the consents by implication; and if we can measure then we have a formal mechanism to decide whether one design is "better" than another in terms of privacy.

In the following articles I'll discuss more about the classification mechanisms (information, security, usage, purpose, provenance) and other annotations along with the detailed implications of these.

Notes

[1] User agent strings are very interesting...just ask Panopticlick.

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.

Semantic Isolation (Pt. 2½)

This is part 2.5, I'm reserving part 3 for the deeper semantic work and I needed to write some  notes after spending a week working on unifying a set of data-sets for our analytics teams -  extremely interesting and surprisingly challenging (in a good way!). This also has links with privacy and understanding what can and can not be linked and the semantics of those linkages is critical to enabling consumer privacy and compliance.

The unification of identifiers was presented in part 2 (link to part1 here too) as a way of  establishing links between two disparate data sets and breaking the data siloing that occurs information systems.

We start with the premise established earlier: The structure of the identifiers is considered a compound key to the records in that data set and understanding this structure is key to breaking the data siloing (see Apps Considered Harmful).


To give semantics (ostensibly a denotational semantics) to those identifiers we map these into "real world" structures which represent exactly to what those identifier should refer to. One of the discoveries here has been that it has been assumed that, for example, a person identifier always refers to a real- world person, or that a device identifier (eg: IMEI, IMSI) refers to an actual device and that there is a one-to-one correspondance between devices and people.

Note: this isn't necessarily a good model of the real-world, the question is that does this model suffice for the context and purpose to which it is being applied.

However common identifiers such as user IDs, IMEI, IMSI do not refer to persons and devices directly but often through artifacts such as SIM cards and a person's persona. Adding to this complexity is that the users and owners of devices change over time, and that we now have mobile devices which support multiple SIM cards. At any point in time we might construct a model of the real-world artifacts thus:

Typically analyics over these data sets - which is the driver for unification to enable  information consistency and quality over cross-referencing of multiple data sets - takes a  particular period in time, say 1 day to 3 months, so that we can dispense with dealing with  certain changes. The longer the analytical period the lower the data quality and there's an  interesting set of research that can be made there on measuring the quality loss.

So the main findings so far are:

• It is given that each user identifier (user ID, email address) used for uniquely identifying  users is assumed to be a separate person.
• It is generally assumed that equipment identifiers and addresses (IMEI, IMSI, IP address)  identify unique pieces of equipment
• The relationship between a device and a person/user is 1-to-1

We have no notion of persona, in fact I've never seen any system with a good notion of  persona. Given two identifiers such as email address as used as username, then two email  addresses used by the same person are assumed to represent two persons. The typical use for  this is to allow a user to differentiate between two uses such as one for social purposes and  one for business purposes. The complicates of linking arises because of the strongly  directional nature of the person to persona relationship - in the discrete terms of UML and ER  modelling, this is a simple directional relationship of the form:

Aside: the notion of persona is best explained by Jung as 'a kind of mask, designed on the one  hand to make a definite impression upon others, and on the other to conceal the true nature of  the individual' which is found in Two Essays on Analytical Psychology. Probably we take a much  more crude view on persona but the principle is the same. There are other views of this such as those explained here: True self and false self.

Just to complicate the above we probably can not assume that a set of personas always refer to  the same person.

The situation with device identifiers and devices is remarkably similar and this is really being highlighted by the emergence of factors such as multiple-SIM, multiple device ownership and misguided collection of identifiers resulting in complicated and error-prone cross-referencing between the plurality of these from data sets of varying quality and information content.

Aside: we haven't dealt with information hiding through encryption and hashing yet and here we either rely upon knowing decryption keys, pattern or semantic matching or weak hashes and trivial salting.

For the moment we have the conclusion that the mapping between identifiers in data sets often do not match expectations of what it is assumed they actually identify and that assumed relationships between real-world artifacts are made implicitly without respect for the actual usage and meaning of those artifacts.

Just to finish (this might become part 2.75) that the data transformation processes:  filtering, abstraction etc over a data-set or extracted portion thereof often implicitly  refines the relationships in the identifier structures themselves and also at the semantics or  real-world level.

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.

Semantic Isolation (Pt.1)

Working with Ora Lassila we have been discussing and working on the definition of the term "data silo" in order to clarify our ideas of semantic isolation when applied to databases, data assets and the interoperability and integration of the information contained within.

The term "silo" when applied to databases, data and information is interesting in that it occurs in a number of statements, such as, "my app data is siloed" or "we need to break the data silos" and so on.

The meaning of the term however is mixed in its usage and thus its usage is inconsistent and misleading in many cases; quite simply it is used to cover a large number of overlapping scenarios.

Understanding the scope and meaning of this term in its various contexts is central to understanding the interoperability problem in a practical sense. In a workshop today I have heard the term used in a large number of ways and also applied to the notion of interoperability: The term "silo" has been used to mean (at least!)

• The data is siloed because it exists in its own database infrastructure
• The data is siloed because it is on accessible via some access control
• The data is siloed because it is in its own representation format
• The data is siloed because it is not understandable/translatable (semantics)

We can present these are some kind of "lock-in" or "siloing continuum", where those usages on the left are more related to physical aspects and those on the right to more semantic in the information sense:

We obviously can create a more granular continuum (indeed that's what a continuum should allow) but the point here is to at least to present some kind of ordering over the differing uses of the term. The ordering runs from physical deployment and implementation through to abstract semantics.

Now it seems that when people talk about "breaking the [data] silos" they are actually referring to enabling interoperability of the data between differing services; and often this is addressed at the physical database or access control level. Occasionally the discussion gets mixed and syntax and representation of data is addressed.

Interoperability of information starts at the semantic level and works in reverse (right to left) through the above continuum; physical, logical, access control and syntax should not prevent sharing and common understanding of data. For example, if one tackles interoperability of information by standarising on syntax or representation (eg: JSON vs XML) then the resultant will be two sets of data that can't be merged because they don't have the same meaning; similarly at the other end of the continuum centralising databases (physically or logically) doesn't result in interoperability - maybe easier system management but never interoperability of information.

Interestingly I had an extremely interesting discussion about financial systems and that interoperability between these is extremely high even at the application (local usage) level and this is simply because the underlying semantics of any financial system is unified. The notions of profit, loss, debit, credit and translations between the meanings of things such as dollars, yen, euros, pounds and the mathematics of financial values is formally defined and unambiguously understood; even if the mechanics if financial and economic systems isn't, but that's a different aspect altogether.

Also an important points here is that the link between financial concepts to real-world concepts and objects is well relatively easily definable. Indeed probably all real-world concepts and objects have their semantics defined in terms of financial transactions and concepts. Thus siloing of data probably can only occur in the financial world at the access control level.

The requirements for breaking the silos is easily understood as the ability to cross-reference two different data-sets and be sure (within certain bounds) that the meaning of the information contained there is is compatible. We want to perform things such as "1 + one equals 2" and be sure that the concept of "one" is the same as "1", the definition of "+" matches the concept of "+" applied to things such as "1","2" etc as well as things such as "one","two" etc. In this case the common semantics of "1" and "one" has been defined...fortunately.

It is vitally important to understand that if we can unify data sets through translations via common semantics then the siloing of data breaks and we get data liberation or what some call data democratisation. Unification of semantics however is faught with difficulties [1] but is the key prerequisite to integration and interoperability and ultimately a more expansive usage of that information.


References:

[1]Ian Oliver, Ora Lassila (2011). Integration "In The Large". Position paper accepted at the W3C Workshop on Data and Services Integration, October 20-21 2011, Bedford, MA, USA

Apps considered harmful

OK, first of all this is joint work with my great colleague Ora Lassila. I've just come off the phone with him discussing our World Domination Plan(TM), or how to unleash the power of the Semantic Web and revolutionize computing...anyway, Ora is in Helsinki next month giving a keynote speech at a conference on museums and we were discussing the title based on various thoughts of ours regarding "apps" and previous work of ours on cloud-based, semantic information systems, eg: sTuples [1] [and Sedvice/M3 [2] (also see here).

One of the things we vehemently agreed upon was that "apps must die" for the reason that "apps" are a new way of isolating (both physically and semantically!) data and preventing interactivity; whereas Sedvice/M3 specifically was designed to break down the semantic isolation and ultimately reduce "apps" to be nothing more than domain specific user-interface manifestations of information - and ideally in some cases, become a novel user-interaction mechanism.

After tonight's discussion, I make a quite search on the "apps considered harmful" meme and found an article "Apps Considered Harmful: Part1" at Elderlore's blog. I really like this quote:

"So,what can we do? In part two of this article,I will talk about moving beyond the fragmented experiences of App World into something more interesting,where data and programs are explicitly represented as objects that you are empowered and invited to interconnect. Consider something like GNU Emacs:the separate “applications”in the Emacs Lisp space are delivered as bundles of functions and variables and hooks,not as single-screen apps that cannot interact or share data. You get things done in Emacs by customizing variables and hooking things together;potentially,any function in any Elisp application can call any other function or access any other data in the system,regardless of which package implements the functionality,and most of the coolness of emacs is in being able to coordinate things this way when solving problems,and to save these coordinations as resuable elisp code."

and also

"I want to smash the App World into pieces;that is to break apps into smaller,reusable pieces or “blocks”which can be visually clicked together like MIT Scratch,but on an industrial scale. Apple already banned this type of software from the iPad;perhaps they know something they aren’t telling us?"

So do we! So de we! Even the EU has started talking about data liberation!

Much of the reasoning behind promoting the "Apple style of app" (remember Nokia's Widsets made years earlier - actually they were coming quite close to our ideal?!) is based around locking-in the developer and especially the user. Indeed pretty much every piece of functionality in most "apps" found on all smart phone operating systems is for consumption of data and recording in specific detail the user's behaviour associated with that particular consumption interaction. Ironically all that functionality is present in the generic browser (eg: Opera, Firefox etc) and usually, much more control over your individual privacy too.

Privacy however is a side issue here for the moment and our focus is actually on what an "app" is in the information consumption context above. Indeed as we demonstrated in M3 it is little more than a query over an information space. In the case of M3 and the RDF/OWL graph view of information, a navigation between chunks of information. Indeed this is the basis of Facebook's social graph.

The power here doesn't just come from the ability to easily navigate over information but also the ease in which reasoning is built on top; from the simple subclassing inferences to complex context specific, non-monotonic rules.

Through this reasoning and suitable ontological structures it becomes almost trivial to add functionality into the graph, eg: new messaging types, and apps which are designed to query for super-types of those automatically pick-up on these new objects. This is hard to do in an "app" - which are more like the traditional applications of old: fixed and unexpandable - who thought of Twitter and Facebook contacts when writing contact book apps all those years ago?

The point where we're heading here is that what we think that "apps" should have been are just queries over information with reasoning at the information store level, that is, pushing the logicl that gives semantics, interoperability and expandability down into the lower-levels of the information stack.

One can argue that "apps" in their current manifestations are optimised for the devices they run upon, eg: an app for iOS delivers the content in the form best for that device. However we would go further (and we made an amazing demo with M3 of this back in 2009), where we encoded how the information should be displayed in various manifestations, eg: list, tile etc - there was an ontology for this, and then let the device pick the best rendering for that informtaion based upon its local context. What made this interesting was the reasoning mechanism searched the information itself, the contained or linked chunks of information as well as searching the type hierarchy for display hints.

We did the same with actions too...and we even started on serialising computations and passing these around...true cloud computing...quite away from the humble, locked-in current definition of "app"...

References

[1]Deepali Khushraj, Ora Lassila, Tim Finin. (2004) sTuples : Semantic Tuple Spaces. Access (2004) IEEE, Pages: 268-277

[2] Ian Oliver, Jukka Honkola (2008) Personal Semantic Web Through A Space Based Computing Environment. Middleware for the Semantic Web Second IEEE International Conference on Semantic Computing.

LoD 2012: Layout of Diagrams 2012

LOD 2012

3rd International Workshop on Layout of Diagrams 

Diagrams are an effective means of conveying a wide variety of different sources of information. They play a vital role in communication at many levels, and the quality of diagram layout effects the ease of communication. Creating task-adequate layouts is surprisingly difficult, and the cognitive factors involved are often not very well understood. The automatic generation of diagrams is essential for many tasks such as the presentation of multiple views of large scale data sets. In many domains, tool support is not satisfactory. The workshop aims to bring together different communities that can learn from each other, both within different academic disciplines and between academia and industry.
We solicit original submissions related to diagram layout, in areas including, but not limited to, the following areas:

• Layout algorithms ;
• Layout design styles, guidelines and patterns;
• Automatic diagram generation and transformation techniques;
• Visual language theory (e.g. quality metric development) ;
• Visualisation of constraints, algorithms, and tools;
• Cognitive or empirical research on diagram layout;
• Diagram layout for diagrammatic reasoning, knowledge representation, etc;
• Application areas (e.g. system modelling, ontology visualisation, etc, with an emphasis on layout requirements and benefits).

All diagram types fall within the scope of the workshop series (e.g. graphs, hypergraphs, Euler diagrams, maps, knot diagrams, etc). Of particular interest is research and techniques that may encourage interaction and knowledge transfer between fields. However, for this instalment of the workshop series, we particularly encourage submissions that have a software engineering orientation (e.g. those within UML, IDEF or ARIS), building on the success of two previous workshops at VL/HCC on the Layout of Software Engineering Diagrams (LED).

The proceedings of this workshop will be published in the journal of Electronic Communications of the EASST (TBC). All papers must conform to the ECEASST format. All papers must be submitted electronically in the PDF format via the EasyChair submission system. Each submission will be reviewed by 3 reviewers, as usual.

The intention is that after the workshop the authors of the best papers will be invited to submit a revised and significantly extended version of their article to a special issue of a sutiable journal (e.g. Journal of Visual Languages and Computing or the journal of Software and Systems Modeling).

Important Dates

• Abstract Submission: June 11th, 2012
• Paper Submission: June 18th, 2012
• Notification to Authors: August 8th, 2012
• Camera Ready Submission: August 30th, 2012
• Workshop Dates: Oct 4th, 2012

 

 

Are you logged in?

Tom Anthony's blog has an article on how to detect whether someone is logged in to a given social network, eg: Facebook, Google etc..

You can run it here:  Social Network Login Status Detector Demo

 

A few things stuck me:

• I logged into Facebook earlier today and then closed the browser window - I was still logged in to Facebook
• Similarly for Twitter
• Going to www.google.com or www.google.co.uk showed the Sign In button, however it did appear according to the status detector demo above that I was still logged in. In order to log out I needed to login and then logout.

Given that some sites, particularly Facebook, have been caught tracking user behaviour when that user is not logged in (google search results here), this is quite worrying from the stand point that such tracking could occur even when you think you are not using a service or not logged in.

Before panic sets in, I'm not at this moment overly concerned about privacy (I am but...) but rather basic security and the fact that user could be accidentally revealing their behaviour.

 

I actually think that most of these kinds of accidental incidents and problems are more attributable to stupidity or less controversially, lack of knowledge, ie: Hanlon's Razor:

Never attribute to malice that which is adequately explained by stupidity.

 

or better still a quote by the journalist and UK civil servant Sir Bernard Inggam:

Many journalists have fallen for the conspiracy theory of government. I do assure you that they would produce more accurate work if they adhered to the cock-up theory.

 

I think this better explains what is going on with the current trend for secondary data collection from Apps such as those found on most mobile devices, ie: from the CNet article "Report says be aware of what your Android app does". Part of the problem is the education and knowledge of the programmers and developers in developing security and privacy aware systems and secondly the available features for security and privacy protection both on the devices and as presented to the users of those devices.

 

Now I lay part of the blame on the developers of the user experience and part on the users - mainly due to the fact that people seem not to care about setting their security and privacy settings, though it must be admitted that the user interfaces aren't really intuitive and many of these concepts rely upon the users being rather  knowledgeable about these features. I certainly don't think Privacy by Design principles help either - they are targeted at the wrong people. I'm not saying these principles are wrong or bad or unwanted but rather their targeting is off. On the other hand, this is certainly is not a trivial problem for the user experience developers, so maybe I'm being too harsh here.

One problem regarding privacy is that there still is no good formal underlying theory and practice for the developers, unlike security which is relatively mature and well defined. In fact I perceive the state we're in now is very, very similar to the level of immaturity the we saw when the masses of developers first started to develop networked systems and used network programming techniques (cf: leaky abstractions); and even the very first web based applications in the early '90s.

 

Maybe part of the problem is that in many cases privacy is still being framed in terms of security, that is confidentiality - which is partially correct but to my opinion, security is about protection of the information exchange and privacy is about protection of the content and meaning of that exchange.

It takes, I believe, about 10 years to understand these problems in the wider development community and probably another 10 to develop the theory and techniques such that they become common knowledge to the developers. Sadly at this time, I see too many incidents where despite the emphasis on guidelines, processes etc, the technical guys: the architects, the developers etc are all too forgotten.

Ultimately privacy and security are in the hands of the developers and if we don't address the problems they face through better tools, programming languages, development techniques, analysis techniques etc, then we're going to see issues such as those presented in the beginning occur in the future, malicious or more commonly not.

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

Towards an Ontology of Coffee Drinks

An interesting post appeared on Google+ [1] about the various forms of coffee drinks, eg: cappuccino, latte etc, and this was expressed using a Venn diagram. The semantics of the actual diagramatic notation were loose - as is to be expected - but importantly the meaning of what the diagram was trying to convey was clear. There's quite an interesting discussion about what actually constitutes a cappuccino vs a latte vs espresso etc - all good stuff to put in an ontology of coffee.

As a start and as an exercise in diagrammatic notation [2] of such things here's my concept/Euler diagram of the same:

NB: I'm no expert on the various types of coffee drink so I'm not sure if the actual coffee drink types are strictly correct, I took them from the original article on Google+. If I do drink coffee then an espresso or something "normal", ie: coffee (dark roast) brewed in hot water + milk + sugar ... sorry Robert's Coffee and Starbucks I'm probably not a target customer in that respect....I'm a tea drinker.

So that gets me to a slightly more interesting example - that of a Chai Latte, which to my taste should satify the following specification (using the same notation): (Aside: I think these diagrams are really quite beautiful....)

Now we can argue that I should have included other types of tea and blends etc, maybe different types of milk (fullfat, goat etc), but I think the point is clear.

A few notes on these: while the diagrams have pretty well defined semantics, the statement the diagrams are making about the "real world" may not be so easily definable (see the discussion about coffee drink types as an example). My specification of a chai latte might not be yours, however we now have a formal framework in order to have a sensible and meaningful discussion without invoking the nastier parts of Wadler's Law, ie: we can concentrate on the problem at hand and not discuss whether the shade of green for the relationships is the correct shade of green...

[1] Rohan Aurora, A Simple Venn Diagram to Understand Coffee, 7 Dec 2011
[2] Visual langauges an ontologies...earlier blog posting of mine to be found here: Visual Modelling and Ontologies and a link to the Visual Modelling Group at Brighton who have been working on this.

Visual Modelling and Ontologies

Just some papers with the Visual Modelling Group in Brighton:

Howse, J., Stapleton, G. and Oliver, I. (2010) Visual reasoning about ontologies In: International Semantic Web Conference, November 2010, China.

We explore a diagrammatic logic suitable for specifying ontologies using a case study. Diagrammatic reasoning is used to establish consequences of the ontology.

Oliver, O, Howse, J., Stapleton, G., Nuutlia, E and Torma, S (2009) Visualizing and Specifying Ontologies using Diagrammatic Logics In: Proceedings of the Australasian Ontology Workshop, 1 December 2009, Melbourne, Australia.(Best Paper)

This paper proposes a diagrammatic logic that is suitable for specifying ontologies. We take a case study style approach to presenting the diagrammatic logic, and draw contrast with RDF graphs and description logics. We provide specications of two ontologies and show how to depict instances. Diagrammatic reasoning is used to show that an instance conforms to a specification. We also include examples to show how diagrammatic rules can be used to (a) constrain ontology specifications and (b) define mappings between ontologies. The framework also allows the specification of queries. The positive features of the diagrammatic logic are discussed, supporting a claim that the new logic is intuitive and appropriate for ontology specification. Finally, we discuss the possibilities for developing tools to support the use of the diagrammatic logic, including automated diagram drawing and reasoning procedures.

Howse, J., Schuman, S., Stapleton, G. and Oliver, I. (2009) Diagrammatic Formal Specification of a Configuration Control Platform In: 2009 Refinement Workshop, 3rd November 2009, Eindhoven.

This paper presents a diagrammatic logic framework that is suitable for use in formal specification and for reasoning about and refining formal software models. We take a case study style approach to presenting the framework by developing, in some detail, an abstract model for a transparent configuration control platform. The model is built up by stages, corresponding to separate concerns of configuration control. Each successive level is a refinement of the previous level. We discuss the possibilities for developing tools to support the use of the diagrammatic logic, including automated diagram drawing and reasoning procedures. Our wider goal is to make a formal specification easier for its clients to understand.

S Törmä and E Nuutila are from Aalto University, Finland.

Keywords: Modelling, Modeling, Visual, Diagram, Diagrammatic, Logic, Semantic Web, Ontologies, Reasoning, Ontology, Formal Specification