Privacy, Data Collection and Surveillance

The privacy debate about the collection of data by the NSA continues with many asking questions about the moral and ethical issues surrounding this. The phrase "the death of privacy" is abound.

This is true I'm afraid, we lost our privacy, but not when the NSA starting collecting data but when we starting communicating using technologies that were readily and easily available - that probably dates back to the birth of written communication.

Data collection concerns me certainly, but here I want to focus on one of the maxims of privacy: "if you don'tuse it, don't collect it" and the fact that privacy is much more about the usage of data, not its collection (viz. the above maxim).

One can argue that merely using Google, Facebook and all the rest of the social media services one has already lost one's privacy, but interaction with these services is voluntary - no-one forced you to post those party pictures to the entire World and dog (complete with EXIF and location information). 

We admittedly do have a problem with other more hidden aspects of data collection and processing, for example with infrastructure and derived data.

In the above respects we have not lost privacy but moved the bounds of what personally and socially we call privacy – obviously people are not placing emphasis on the moral and ethical issues but rather on the economic benefit of using such data consuming services. In writing this blog I am losing my privacy, but with the economic gain of brand building and knowledge sharing.

Using this data consumers and users can be profiled and classified; typically for the serving of the perfect advertisement. However this is not unlike what an "old style shopkeeper" did through personally knowing his customers. The major difference is that today this is done automatically and impersonally by computer. We lost the link with that corner shop keeper who knew us and our families personally. Ever try contacting the customer service departments of practically any company these days?

This also touches on the point that users start or have started to feel that they are not in control of their data.

Most advertising and profiling companies are using classification structures that are fairly coarse grained but then further refined those with additional [coarse] grained data such as location and social network. This for the most part is nothing more than could be understood by reflecting on one's own life, place of abode and neighbourhood. For the most part this is just reasserting what is already derivable from a person’s postcode.

Much of the data collected by the NSA in the current revelations is somewhat innocuous; primarily this seems to be just telephone record meta-data like the kind you see on an itemized bill. But such innocuous data can easily be cross-referenced and fingerprinted.

The trouble here is that government authorities can have a more insidious effect upon a person's life than a supermarket or credit card provider can. Indeed there are safe guards and protections through the rule of law - though as we have seen these can be constructed so that under some circumstances the law can allow whatever is necessary to get a/the job done.

Before however we dismiss the above, consider two points:

1. automatic guilt, or, guilty until proven innocent
2. scope creep

The first derives from the fact that all your actions may be used against you in the future. If you think you have nothing to hide then consider all the crimes you committed today? Did you drive over the speed limit, run a red light, have you ever stolen something/anything etc?

The second derives from the first that once you have this information then it could be used for purposes well beyond its original intent. Worse are the twin possibilities of false positives and false negatives. Consider councils in the UK using CCTV cameras originally intended to catch terrorists and prevent crime (in general) for catching dog owners not cleaning up after their dogs.

From the above the moral and ethical arguments are easily fashioned, the economic arguments are much more difficult and vary depending upon the context and our view of what society should be:

• Is personal freedom, privacy and liberty greater than that of society's?
• Is mass surveillance better than letting one "terrorist" commit an act of atrocity?

These questions however go right to the heart of the definitions of freedom, liberty, privacy, security, society and our own control over our own data. I don't think any of us even remotely comprehend the repercussions and difficulties of even trying to address, let alone answer such questions. 

But until we start having this debate in an impartial, focused and formal manner with the terms and definitions clearly stated, judging and/or condemning any form of data collection and any form of processing and usage of data is not going to be possible in any meaningful, lasting manner.

In another way we're back to a question posted by a group of mathematicians regarding the esoteric nature of things as we move away from the fundamental building blocks, and losing sight of what those building blocks [of society and humanity] actually mean.

Whether the NSA and everyone else's collection of data is right or wrong I can't answer, but the debate about what privacy actually is and our relationship personally and as a society with the concepts of privacy, security and trust is going to be an extremely interesting debate with wide repercussions.

Privacy, Continuity and Performance...

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

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

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

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

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

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

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

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

Data Collection

Anyone who cares about privacy will tell you that data collection is bad...REALLY BAD, yet without data collection none of the services we use and need would work (there's an economic argument there). Indeed most of the issues around data collection seems to be very emotive in nature and usually end up in the "data collection is bad/must be minimsed panic".

First to understand data collection we must understand from where data is collected. First of all we need to understand the relationship between a client and a server via some infrastructure. This is described in an earlier article which talks about primary and secondary data.

Generally the case we mainly worry about in privacy is where the client is a human interacting with an app or browser via some device, eg: a mobile phone.

The end-user (customer or human) will provide some information required to fulfill the functions of the service required, eg: posting a photograph to Flickr with some description and their login details.

So far this seems reasonable - afterall, a user is posting a photograph to their account with a description. The service might then perform an number of other tasks

• Set the current time and date of upload
• Extract EXIF information from the photograph, including (but not limited to):
• date and time of the shot
• location information
• camera information
• free text strings, eg: copyright/ownership information

All of the above comes under the notion of data collection and all of the above is information provided by the user of the service. One can argue that the user didn't know about the EXIF contents of the photograph and surprisingly few people actually realise how much information is embedded into the picture.

Further operations can be performed such as facial recognition and linking this to persons who have been tagged in other photographs etc. For example, this is a service provided by Facebook.

Additionally the service maybe collecting secondary information about the usage of the service, for example, how much time was spent using a particular page, what the UI/UX flow was and so on.

Then there's the information collected from the infrastructure. This includes information provided by the browser or app, typically in the form of browser identification strings, application identifiers, device identifiers, and from the service infrastructure including such information as source IP address, contents of the API call, time and date of interaction, error codes etc.

When we talk about privacy we typically end up focussing on the primary and secondary information sets. The former set to decide whether that information is necessary for the service to function and provide the facilities the user requires and the second set to decide whether this information needs to be explicitly collected or not. Rarely do we even investigate the information collected by the infrastructure which can be used both to recreate primary and secondary data sets. Indeed one of the major targets for any hacker are the infrastructure logs themselves.

When we talk about data collection we must consider the following data sets:

Primary, secondary and infrastructure are described as above with the addition that we split primary into explicit and implicit where the former denotes that information which is explicitly understood by the end-user and implicit including that information that might be hidden, eg: EXIF. Combined together we produce the Total Information Set which when linked together by simple association becomes the Total Deduced Information Set.

Another way of looking at this is in a more Venn diagrammatic manner:

Where the labels are abbreviations of the corresponding labels in the first diagram and colours for emphasis.

It must be noted that some intersections might not properly exist, for example the union of EP and Sec, and others only in certain contexts, for example, whether IP is a proper superset of EP or not.

Now we have explicitly modelled data collection, we can now start tackling questions such as what does minimisation of data collection actually mean and then start looking at what the processing and extraction functions over that data might actually look like.

What is the economic component of privacy to the end-user?

Privacy is framed in terms of ethical, moral and economic arguments. Certainly most research supports that nearly everyone is worried about their on-line privacy, yet rarely if at all we've seen a company actually fail because of their attitude to privacy. Some companies have changed their ways admittedly, but the change has been minimal and after the initial fuss it is very much business as usual. Privacy seems not to be much of an ethical or moral issue to most people but rather an emotional one.

Given the above we don't see much of an economic argument either, at least not from the end-user side of things. The economic argument for using certain social networking services, sharing personal photographs, details etc seems to outweigh the potential disadvantages - which tend to be worries about to where data is being shared or sold, or who might be viewing that material.

Privacy is rarely framed in terms of an economic argument beyond the "data mart" idea but rather in emotional terms: nothing to hide, nothing to fear perhaps? Privacy is lost in the security and liberty arguments too being equated with concealment and freedom. Consider the argument put forward by US congressman Paul Rand [1] on privacy.

Laws are changing to emphasise the economic argument to the companies that provide internet services and there we do see a strong argument for a more robust privacy function. Whether we on the business side of things are addressing privacy in the right manner and in the same economic terms as our end-users is another matter altogether. For companies the economic argument for developing and adhering to an information safety (privacy) is very clear. We have a good economic argument for treating end-users' information with respect...whatever that is.

For the end-user the economic argument is unclear. Why should an end-user choose one service provider over another? What are the terms of this economic argument and have they even been defined at all?

References

[1]  Senator Rand Paul Talks Tech, Civil Liberties, and Keeping the Government Out of Your Email. By Spencer Ackerman 05.30.13 Wired

A Paper.li publication

Paper.li offer an interesting service collecting articles based on keywords (and probably some analytics too), here's mine concentrating on privacy:


Quite useful plus it acts as a collection point for Twitter users.

A basic information privacy programme

Using the material discussed earlier as our starting point we can construct the outline of an information privacy programme (IPP). First however we must place any IPP into juxtaposition with the units it will affect:

Note that any "IPP" can not rule nor dictate over any of the affected parties, it does however provide a point of contact and expertise for those parties when working with information. The enforcement aspects come from a number of other places which we'll discuss in another article.

We structure the IPP into two parts: the programme elements and the knowledge base, both of which we will introduce here.

The Programme Elements are:

• A Reporting System
• An Information Distribution System
• A Privacy Committee
• An Inspection Programme
• Education and Training
• Accident Preparation and Investigation

The Reporting System is a mechanism by which people both inside and outside can bring to attention issues, problems, notification of data breaches and other privacy problems to attention. This mechanism must allow anonymous contributions and can be compared to the aviation related programmes CHIRP and CHIRP-MEMS.

The Information Distribution System is a mechanism by which privacy related topics can be communicated to interested parties outside of the IPP. Typically such information might be of the "interest" variety, eg: notification of new laws or relevant news articles, to the critical such as a notification of an information breach or threat which must be acted upon by any receiving parties.

The Privacy Committee is the one fraught with political difficulties, but a small (5-7 people) group from a cross-section of roles within the company. This is where many programmes fail because of placing management or non-technical staff here. The role of this group is not to manage the programme but to reivew incident/accident reports, review adequacy of corrective actions, hazard reviews, inspection reports, provide recommendations (based on information received via the reportins and information distribution systems) and to self-assess and improve the ways of working of the IPP as a whole. The committee is also the chance to bring onboard the expertise in the external parties from R&D, legal etc.

The Inspection Programme can cover many aspects, but is primarily concerned with auditing and providing mentoring/consultancy to external parties. Auditing usually takes place as part of the deployment cycle of a product for example. This area constitutes most likely the bulk of the work of the IPP.

Education and Training is always critical but often badly done (if at all). Developing relevant training for the external parties is critical to long-term success and accident avoidance.

Finally we get to Accident Preparation and Investigation. Hopefully data breach or similar incidents never happen, however having procedures to deal with these are critical to a good solution to any problem. Likewise, a good investigation procedure which not only traces down the causes but provides solutions is also critical.

This concludes the programme elements and now we move to the Knowledge Base which is where the tools, techniques, metrics and database for storing all of the required knowledge and wisdom for running the above element succesfully. We use the word "tool" in a loose sense - automation in any form might not be available, but things such as checklists or ontological structures/classifications are tools.

As a recommended minimum for databases: a database of relevant laws and implications (at an R&D level of detail), a database of reported risks and a database of investigation findings and so on.

All this is just an overview - specific companies, specific situations require customisation and we still have not discussed in any detail the content of the knowledge base nor programme elements let alone presented particular roles such as that of the privacy officer etc. What however should be clear is that a structuring is necessary and what have presented here summaries some of the best practices from an area that is already well versed with similar issues, that of aviation safety. [1]

References

[1] Wood R. (1997) Aviation Safety Programs. 2nd edn. Jeppesen.

Topology, the periodic table and parasites

hree very interesting websites to amuse you. The first a homage to topology or as the author puts it:

"This is a toy for building complex 3D polyhedral shapes from simple ones by "recipes"

polyHédronisme allows you to construct various polyhedral shapes (only 3 dimensions though!) by composing rules over various bases, for example starting with a plain octahedron

and applying various rules we can get beauties such as this below using the rule "n18n18n9n9n9soxO" in the notation used on the site:

 

The second is the every popular Element of the Week via the The Guardian newspaper. A fun introduction of the basic building blocks of chemistry and each week a new element. This week, the famous and well known element: astatine .

I recommend you check out caesium, rubidium, potassium and sodium for the sheer fun of watching those being dropped into water and reacting violently. Such experiments are now banned from schools for safety reasons, along with many other aspects of science unfortunately...

Failing that there's the Royal Society of Chemistry's Visual Elements Period Table which is great fun.

And finally, for the squeamish of you stop reading now, for the less squeamish its probably best to avoid mealtimes, but this is great:

Parasite of the Day!

Introducing a new beast more or less regularly (if not every day). To understand this site you can read their introduction which helpfully has no pictures to put you off your food.

Privacy learning from aviation safety...

I've written before on my thoughts, or belief, that information should be treated as a dangerous chemical, or a patient undergoing surgery:

privacy is a safety critical concern

Developing ideas such as checklists from aviation, surgery etc, do improve the quality of work and actually implementing those has been a very interesting experience - if anyone wants to learn about this let me know, I'm very happy to talk about it.

Now while we have some parts of the "coalface work" working, ie: the real privacy engineering work with real software engineers, software architects, programmers and code, we can now turn to reassess how we're managing privacy and in turn managing risk and improving the safety of our code, products, business and ultimately our customers from a privacy perspective.

One area that has succeeded very well is aviation - our original starting point for much of this safety discussion. Indeed aviation safety precedes most other safety programmes by decades. I'd like then to quote from the book Aviation Safety Programs (Richard Wood, 2nd edn 1997, Jeppesen):

Safety is not a moral problem or an ethical problem or a pain and suffering problem. It is an economic problem. Safety, by itself, generates a lot of sympathy, but very little action. Only the economics of safety generate action. In the entire history of safety, nothing good happened unless it was either economically beneficial or mandated by government.

Now simply replace "safety" by "privacy":

Privacy is not a moral problem or an ethical problem or a pain and suffering problem. It is an economic problem. Privacy, by itself, generates a lot of sympathy, but very little action. Only the economics of privacy generate action. In the entire history of privacy, nothing good happened unless it was either economically beneficial or mandated by government.

Interesting don't you think?  Ah, yes, we know it is an economic problem and it certainly is being mandated by government. Adopting something like Privacy by Design today will not change the quality of your product or relationship with your customers. You'll get some sympathy but ultimately does anything change? There's an outcry every time Facebook changes it privacy policies but people still post private information there; similarly with Google and the rest. Privacy is talked about in moral and ethical terms: building trust with the customer.

Despite of everything, Facebook hasn't lost 50%, 90% or even 1% of its customer base because of its perceived "anti-privacy" stance, and neither has Google, nor any other company I can think of. Privacy must be framed as an economic argument: if company X abuses their consumer data privacy, then they lose all their customers and business.

We've a lot to learn from a successful safety program and that's something I'm going to write about more in the coming days and weeks. How do we put a privacy programme together such that it really does economically benefit a company and addresses all the cross-cutting issues from the top management through to the programmer actually writing the code that runs the business?

First things first though, when constructing such a programme, we need a group of people to lead the privacy culture within a company and that team needs day-to-day experience close to coalface, they need knowledge of not just the moral and ethical aspects but of real scientific and engineering experience. Starting with that we might just really see where the economics benefits are won and lost.

Foundations of Applied Mathematics

Via the n-Category Cafe blog I noticed a real gem in the workshop on The Foundations of Applied Mathematics. Simplifying systems and trying to understand the foundations of things (information systems, software engineering, privacy) is of great interest to me.

For example, in my current area of information system privacy we have a huge problem in even contemplating what the foundation of the discipline looks like, let alone trying to formalise it (and it probably has a lot to do with entropy, semantics, measurement theory and information flow if you ask me - but before we get there we've a lot of other work to do).

The particular piece of work that interested me was by John Baez who has a history of work trying to unify various areas of mathematics ostensibly through category theory and his presentation entitled The Foundations of Applied Mathematics (slides) presents his work on applying these ideas to applied mathematics. This was also followed up by an interesting discussion on Google+.

The whole presentation and body of work starts to remind me of a few things

• layered architecture
• esoteric  models of understanding (- need a better way of explaining this!)
• visualisation (= diagrams)

Baez presents a model of four (for oversimplicity's sake as he describes in his presentation) layers linking science and engineering with applied mathematics with pure mathematics and finally grounding that in the foundations of mathematics. Immediately coming to mind here are the kinds of layered architecture we see in software engineering with each layer building upon the primitives provided by the immediate lower layer.  This is then followed by the question:

"Can developments in applied mathematics force changes in the foundations of mathematics?"

I'd have to answer 'yes' to this if only to assert the position that if the lower layers have not been correctly formulated or established and can not support the upper layers in their needs then the above is inevitable.

The reasoning for this comes from, at least in my chosen area of software engineering, is that layers [of software] are often constructed without any reference to any other layers, the operations and structures in those layers are not "atomic" or fundamental in nature with respect to that layer and the separation of concerns and layering of architecture is often a matter personal choice. Layers are often polluted with convenience functions and particular architectural choices, see Anti Patterns.

Another way of looking at this is via a famous xkcd cartoon on the relationship between Lisp, Diety and how it was really built:

Maybe it just is that the foundations aren't bad at all, just that we got the layering wrong. Maybe mathematics isn't layered at all...object oriented anyone?

Further in the Google+ discussion started by Baez, a posting by Carsten Führmann quoted Von Neumann:

"As a mathematical discipline travels far from its empirical source, or still more, if it is a second and third generation only indirectly inspired from ideas coming from 'reality', it is beset with very grave dangers...."

The quotation continues but the gist is that the further a discipline goes away from its foundations the more esoteric it becomes. I think in software engineering we see this quite clearly with things like use case modelling and agile methods. Not that there's much wrong with either but their current application is often far from the ideals proposed by their creators.These then get use to develop the architectural layers seen earlier.

In information system privacy we do not have a clear, coherent understanding of the foundations of the discipline and yet we are developing at very high levels of abstraction concepts, laws, ideas without understanding how these are to be architected into the technologies we are building. Contemplate the semantic gap between the European Privacy Directive and the actual C++ (or whatever) code that implements those. I'm not saying that laws, directives etc are wrong, just that even simple ideas such a Do Not Track will expose huge holes in our understanding of the discipline of privacy (and a lot of related subjects too). Actually I think that DNT won't work in its current form because too fee people do not want to address the formalisation of privacy but remain at some esoteric level far removed from what DNT is trying to address and that might have other implications and Von Neumannesque danger signals.

I won't discuss visualisation here, that's for another time, but just to reference the work at the University of Brighton on diagrammatic notation and also to refer to another point in Baez's presentation on the use of diagrams across disciplines (and layers of science) to express concepts to different audiences...presenting Euler diagrams to lawyers, marking people etc is an extremely interesting experience, especially when - as "non-mathematicians" - they start interacting using those notations and at some level we've "accidentally" unified the languages mathematicians and lawyers....

Programming Language Frustration

I've been writing a lot of Opa recently - for those of you who don't know, Opa is a framework for writing web software without the hassle of worrying about database connections, distribution of code between front and back-end systems, asynchronous vs synchronous calls etc. It also cleverly integrates code, HTML and CSS holistically into the language. It is basically a mix of cool functional programming ideas with Javascript and a compiler that generates Javascript to run on Node.js; along with MongoDB (and soon Postgres) integration.

What Opa is brilliant at is abstracting away from all the awkward stuff that web (and thus distributed and network) programming. To make life simpler and programs more robust it is also strongly typed but does support polymorphism, variant (or sum) records etc. It can be a bit of a pain when settling down on your data schemata BUT you should be thinking hard about this stuff anyway. For you agile people go read about technical debt, for the privacy people who also worry about data, go read about the slow data movement.

It has its fair share issues too; some features are missing, eg: monads, but that's curable, but the main problem with Opa, and this is shared amongst many cool things in the software engineering community, and that is documentation.

Opa has a book and basic tutorials, a twitter feed, API documentation and forums (locally and StackExchange), plus you can actually get hold of the guys developing Opa. All very good but the experts on Opa are the people who developed Opa and not the people developing in Opa.

Opa's programming community is very, very small and this seriously holds back the acceptance of use of the language.

In Pirsig's book Zen and the Art of Motorcycle Maintenance, Pirsig talks about the quality of components - specifically how threading the head of a screw can render the greatest motorbike useless. The quality of the whole is dependent upon even the smallest, singular part.

And so it is sometimes with Opa: the lack of a specific example, a relevant explanation for a particular function in a library, how to compose specific kinds of database query etc, can bring a project to a screeching halt with no way forward. Getting past this is critical to any larger scale acceptance and use of the framework/language.

For Opa to succeed it needs better integration between the Opa developers and the developers of Opa. It needs a constant stream of questions, bad code, good code, homemade tutorials etc to develop that external body of knowledge, a set of patterns, case studies from industrial environments, cool solutions to common problems, etc.

I'm constantly amazed at how quickly I can get things done with Opa (apart from CSS which really is the language of evil and frustration) and would recommend it to anyone who needs to develop quick web applications. But to those who do use it, please give something back to the community in expressing what went right and what went wrong, patterns for common problems (eg: OAuth, social network integration, database usage etc)

OK, enough venting of frustration...back to honest coding now...pity that so little time is spent with Opa, most of it seems to be fiddling with the user interface (html and css)...sigh :-)

Links

• Opa Tutorial pt1, pt2, pt3, pt4 (+ intermission)

More Maxims for Privacy

I wrote some maxims for privacy a while back, but still I'm looking for that crystalisation of privacy - the "one slider" or "one sentence" that encompasses the foundations, or the basics of privacy.

For the most part privacy comes down to data collection and subsequent usage of that data - the rest is just additions to that. At least if we're concentrating on privacy and not the wider scheme of information management of which I believe privacy is just a sub-speciality, albeit a rather important one.

So, when dealing with information:

"If you don't have a use for it, 
don't collect it!"

For me this sums it up. It links data collection and usage in a way that clearly states that just collect what you need right now; don't even think about the future uses yet. Interestingly I also think that deliberately restricting the data collection right at the start to what you absolutely know you are going to use immediately forces you (the software/system developer) to better focus on the product at hand - "Slow Data" anyone?

In these agile development days however, it is often argued that we'll develop the usages later and collect everything now. How often does this really happen? And, if you really were agile then you'd construct your system initially to do the minimum it needs to and get that out to the customer for their appraisal. If that goes well (or not), then modify as necessary during later stages in your agile development process.

If you're not agile (which apparently is waterfall, though I'm not sure), then you should have worked out what you need and work from there; which again should be self-limiting on the data collection. Surely in a good, fully worked out design you wouldn't be collecting superfluous things?

So, that's it, the essence of privacy as a single sentence; the rest is just layers pertaining to things such as provenance, data retention, purpose, infrastructure etc - that's what makes good information management a whole discipline in itself, of which privacy is one small, but important part.

Has space exploration become boring?

At the expense of evoking Betteridge's Law of Headlines - obviously space exploration isn't boring - and with Voyager 1 maybe leaving the Solar System, I was wondering what happened to the romance of space exploration.

Does anyone anymore sit up until the early hours of the morning as I did when Giotto encountered Halley, being amazed at Uranus' bizarre collection of moons, fascinated with the existence of nitrogen geysers on Triton, volcanoes on Io; does anyone (other than scientists working at NASA, ESA, JAXA etc) get overly excited these days at pictures from Mercury, Vesta etc?

Does anyone dream of what the Ice Giants explorer might have found at Uranus, or what creatures might live under the icy crust of Europa's ocean?

I remember (pre internet days) desperately waiting for pictures of Neptune, Triton, Miranda, Titan etc to appear in newspapers, books, news broadcasts. Even back in 1992 the joy of connecting to NASA ftp servers to download Voyager and Pioneer pictures of Saturn and it enigmatic, orange cloud enveloped moon Titan on the only Sun workstation with a colour display the university had, over a slow internet link. Watching in fascination as line-by-line the picture was displayed and possibly imagining oneself at JPL watching those raw pictures being received at Earth.

The Register has an article from yesterday on Voyager 1 (yes, still going since its launch in 1977!) which has the paragraph (emphasis mine):

Probably the most-loved survivor of 1970s space optimism, Voyager, has sent back signals indicating that it's left the heliosphere.

Maybe this is it, in the 1970s we were optimistic - there were many missions planned: Pioneers 10 and 11, followed by Voyagers 1 and 2 to complete the Grand Tour of the Solar System; later with the first missions to comets, landers on Venus and Mars.

Maybe science just took center stage for a brief moment only to be replaced with the need for fame and appearing on X-Factor? Maybe a picture of the creme brulee surface of Titan from a small lander piggybacked on a probe that made a multi-billion mile tour via Venus, Earth, the Moon, an asteroid or two, Jupiter and finally to Saturn, just don't complete against today's media offerings?

How can you not be amazed by pictures like this - think about what you're looking at and what it took to get those pictures for a moment!

Wikimedia Commons, see: here

On the other hand a grainy picture of Titan from one of the Voyager probes offered mystery and a challenge to be solved - what is under those clouds? - now we get picture of sand grains on Mars. Have we accidentally removed the mystery? Or, have we lost the big exciting picture to a mass audience? A third possibility is that science is either not understood, or just can't complete with a crass, exploitative talent show...

Space exploration in any form is exciting...just listing some of the current probes:

• Dawn is on its way to Ceres after a successful encounter with Vesta.
• Messenger has completed mapping all of Mercury's surface and turned up just one or two (or freaking lots!) of major mysteries
• Cassini is still going strong around Saturn
• Juno on its way to Jupiter
• Venus Express still examining Earth's "twin"
• Numerous orbiters around Mars and not forgetting two (yes TWO!) working rovers on the surface
• Rosetta is still on its journey to 67P/Churyumov–Gerasimenko.
• China's moon probe made a detour to visit a near-Earth asteroid
• Hayabusa returning samples from an asteroid
• New Horizons still speeds to its all too rapid fly-by of Pluto and its now five moons (incidentally traveling at approx 15km per second or 34000mph)
• etc etc...
• oh, not forgetting Voyager 1 and the rest...

Now tell my what that isn't exciting? Maybe our media needs to reacquire its love affair with exploration and science and stop feeding minds with talentless shows...

Privacy not needed?

I'm told that we have no privacy anymore...none whatsoever...and this is why we don't need to review products, services, applications from a privacy aspect. You can argue the same for security and performance...just add memory and cores OK, or, use a longer encryption key?

But actually this touches on many aspects of what is privacy and I'm of the opinion that what privacy offers is the ability to the consumer or user to actively choose what is collected and for what purposes that data might be put.

Overall, however, this places privacy in a very small subset of information management and this is where we really need to turn our focus. Remember the "good days" when databases would be normalised and we worried about the quality of data? Privacy for all its faults and detractors returns us to a point where we need to think about what data we're collecting, how we're storing it and for what purposes it is being used for - that's good information management.

What has surgery got to do with information privacy?

I'm addicted to books and reading and Amazon knows this - I'm willing to give up quite a lot of my privacy for good book suggestions. I went to Amazon to find a copy of Atul Gawande's The Checklist Manifesto and ended up buying his other two books as well: Better and Complications. I received them two days ago and I've finished Checklist and Better and just starting on Complications - compulsive and utterly fascinating reading about Gawande's insights into his work, surgery and medicine in general.

So why is a computer scientist reading this? Simply because we need more discipline and communication in this field. Surgery has cottoned onto this and is following the safety-critical practices of aviation to improve.

Performing audits, especially those which require a deep look inside a system such as privacy or security is remarkably similar to surgery.

We receive a system for audit, sometimes we get a description and a good idea of what to do, sometimes not. We need to diagnose the system, quite literally probing and performing tests and hoping we don't miss something: an insecurely calculated hash or a hidden transformation of an IP address into a location etc.

We then report back to the system owner with our diagnosis and treatment: hash this, destroy this data, stop collecting x,y and z, add this to the T&C's, add an opt-out, go for a security check etc etc...

We don't always know what we'll find until we open the system up. And like surgery, opening a computer system up is just as painful for the patient as well as the engineer.

Category Theory for Scientists

Had to quickly make a note about this as I think David Spivak in his paper (book!) Category Theory for Scientists has written a wonderful guide to what category theory is and how it can be used outside of its topological home. I've always held that the manner of thinking required by category theory provides an incredible toolkit for conceptualising and working with all sorts of structures and concepts, so I'm very, very happy to see something like this.

The only other major work in a similar vein is the deeply mathematical Baez and Stay's paper Physics, Topology, Logic and Computation: A Rosetta Stone.