A Philosophy of Riding

Been thinking about this for a while, but:

• A good horse rider has only four problems: hands, legs, body and mind
• A excellent horse rider tries to address the above
• A bad rider believes they have less than four problems
• A horse only has one problem: the rider

Information wants to be free...?

I both like and dislike the quote "information wants to be free", mainly because it opens up a very nice philosophical discussion on what 'free' means but also because - and this is part I hate - it is some damned meaningless without any grounding in any form of semantics; and we've seen this before!

For the first part, this statement treats information in an anthropomorphic manner. Is it really information itself that has the need to be free? Let's assume that it does, though in a very fairy tale like way, it seems to me.

So let's then look at the word 'free', which I assume does not mean 'free' as in 'without cost' in the sense that someone has to pay for it. Though this is a curious idea in that information is somehow prostituting itself and despite all attempts someone (the information's pimp perhaps?) insists on controlling things. I guess this is the idea that information is going through some pre-1960's sexual revolution...

Rather I think the word 'free' refers to 'freedom' albeit in a Western sense of the word. Think of the use of the concept freedom as used in the US Declaration of Independence.

"We hold these truths to be self-evident, that all information is created equal, that it is endowed by its Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness"

...or should that be Existence, Communication and Semantics perhaps....?

Let's stick with the word 'freedom' and its naive or common-sense meaning. What does it mean to be free? We can turn further to the the UN Declaration of Human Rights and the EU Charter of Fundamental Rights for further clarification, though here I'm sure we go into more of a legal-political debate more than anything. Evidently freedom means either the right to do or be something or the right to be protected from something.

So the question is, if information want to be free:

• What does information want the freedom to do/be?
• What does information want the freedom from?

Under the first question, the freedom to be 'free' as in 'without cost' certainly falls. What about the freedom to be private, or the freedom not to be abused - as in excessive privacy violations? Do we further need a notion of agency - does information have an owner or provenance?

Without answering those - I don't think I can give a definitive answer anyway - here's another thought. Given that matter = energy, isn't the use of the term information quite literally another way of saying 'humans' (or 'men' as in the Declaration of Independence). In which case the question 'information wants to be free' is just an expression of man's desire to define what freedom is - ostensibly in terms of freedom to do/be and freedom from.

And here comes the practical part, which freedoms to do/be or from do we allow or deny in order to be "free"?

Thinking about Grothendieck

On n-Category Cafe is a post by John Baez linking to a short article on the late, great mathematician (and human being by all accounts) Alexander Grothendieck written by Barry Mazur.

I want to quote from that paper because I think the statement here is fundamental to everything we do, particularly in engineering and mathematics, be it category theory, trying to model the information flows in a system to better understand privacy or even linking privacy engineering with the legal aspects (emphasis mine):

The mathematical talks I had with him—as I remember them now—were largely, perhaps only, about viewpoint, never about specifics (with the exception of a conversation about differential structures on conjugate complexifications of an algebraic variety over a number field). Grothendieck’s message was clear throughout: that everything important will follow easily, will flow, from the right vantage. It was principally ‘the right vantage,’ a way of seeing mathematics, that he sought, and perhaps only on a lesser level, its by-products. 

Twitter Discussion on Privacy and Engineering

Related with the upcoming DSummit conference in Malmö in May I've been involved in a fascinating discussion on Twitter with some of the big privacy people there.

The main point being raised is the need for a proper dialog between engineers and lawyers. I think we've seen this before, but still it is not being properly addressed and until it is privacy will remain a compliance activity rooted in a tick-box mentality with dreadful repercussions.

One only needs to take a look at the potential penalties in the EU's GDPR ... a potential fine of 4% of global turnover for a privacy violation!

The crux of this is that if you want to construct systems with privacy as an aspect, it has to be a first class aspect of that system's design. That means privacy is under the collective responsibility of lawyers, engineers and management and not the sole preserve of any of these groups.

Belief in high-level privacy impact assessments and "compliance", and placing trust in a legalese privacy policy is woefully insufficient, not to mention from a business perspective one step short of insanity.

Unfortunately going beyond this is considered by some - and I've seen too many examples of this - to be difficult and unnecessary and that legal compliance - whatever that means - is enough...

As we move to a "BigData" future, the knowledge of basic data handling, quality and governance at both engineering and legal levels is critical - not just for privacy but for basic business reasons, including consumer trust and quality of product.

How to do this is not difficult, but it does require thinking and small, but extremely beneficial cultural change...

Agreed. Need to translate high level privacy principles & PbD, into specific engineering reqs @mdennedy @i_j_oliver https://t.co/a4hgcUhGnJ

— Privacy Matters (@PrivacyMatters) December 20, 2015

and here's a recommendation to get those principles into use:

@daraghobrien I found @i_j_oliver's and @mdennedy's books on privacy engineering of enormous value @ll1t

— Privacy Matters (@PrivacyMatters) December 21, 2015

You can start here:Privacy Engineering and A Privacy Engineer's Manifesto

Airmiles and Customer Service

I think we're all used to utterly rubbish customer service from airlines, especially if you have to fly in economy class. No food, no drink, Byzantine terms and conditions, cancellations and subsequent rebookings that cost money (!!!), cramped seating and paying for Wifi on board without refunds if it doesn't work. Oh and good luck if you want to speak to a human, either on the phone or at the airport

Some airlines still have a concept of customer service - SAS and Lufthansa as well as low cost challenger Norwegian at least treat passengers (sorry customers) with some degree of dignity.

I stopped flying Finnair years ago and switched my allegiance to Lufthansa and Norwegian, primary on price. When Norwegian want 600eur to fly a family to Gatwick from Helsinki while Finnair wanted over 2500eur (on a BA flight too!) with effectively the same ticketing terms and conditions. For long haul Lufthansa is my preferred airline - they serve wine and beer with the meal (all included in the price) and have the most professional and hard working cabin crew I've so far come across.

While none of the above are perfect - they could do a HUGE amount more to make the economy experience better - more on that another time.

But what really gets me is that if times are economically tough for airlines, how little they do to actually understand their customer. I mean I used to fly Finnair religiously - their customer service was excellent, food and drink on board, clean aircraft and you could change flights without being punished. Let's be honest here, Finnair were excellent, really, really excellent! I used to change whole itineraries to fly Finnair....

If you want customers then shouldn't you understand why customers aren't flying with you. Isn't this the whole point of customer loyalty programmes?

Below is my Finnair Plus statement - it's been that way for years and not once have I ever been asked why...

So privacy, security and other aspects aside, if you have a customer loyalty card of any sort and change your behaviour, eg: by stopping using that company's services and they never query why, then you were probably never getting any service anyway...

I used to have quite a tally of Finnair points, they all expired or were changed to some newer, more customer friendly scheme, for the benefits of the customer. I was never informed why or when, nor did anyone ever contact me about the change. For a customer loyalty programme you've got to admit that's pretty dire.

Forbes has quite a bit to say about this...

So, if you happen to work in the customer service dept of an airline and wish to discuss the above and how you can win me back as a customer, and a loyal one at that, let me know...

Warning: Coffee Might Kill You

So, I found out recently that coffee might kill you. Seriously, it is a dangerous substance - almost as dangerous as a 110ml bottle of water is to your safety on an aircraft (but a 1 litre bottle of something alcoholic bought at duty free isn't) - and here's the proof (seen in a Starbucks in San Jose, CA):

Proposition 65 Warning Notice: "Coffee Might Kill You"

I'm not actually sure whether that has stopped anyone from buying coffee (or tea for that matter), ever. I suppose you could switch to that decaf muck, but you're probably going to die of something equally horrible then too.

I guess some lawyers and/or politicians need to cover their asses...

Quote of the Day about Truth

Emile Zola:

 “If you shut up truth and bury it under the ground, it will but grow, and gather to itself such explosive power that the day it bursts through it will blow up everything in its way.”

Spam and Category Theory

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

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

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

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

Hmmmm....

Foundations of Privacy - Another Idea

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

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

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

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

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

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

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

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

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

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

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

And wouldn't that be something!

PbD, The Privacy Engineer's Manifesto and Privacy Engineering

Had quite a bit of time to rereview the relationship between the foundational principles of PbD, the excellent book Privacy Engineer's Manifesto and my Privacy Engineering book. To me this is how it looks and finally I think we're starting to see a proper balance between these.

The seven foundational principles of Privacy by Design are well known throughout the privacy community and together they stand as an ideal focus for the development of privacy over our information systems as the Agile Manifesto did for software development processes.

1.  Proactive not Reactive; Preventative not Remedial
2.  Privacy as the Default Setting
3.  Privacy Embedded into Design
4.  Full Functionality – Positive-Sum, not Zero-Sum
5.  End-to-End Security – Full Lifecycle Protection
6.  Visibility and Transparency – Keep it Open
7.  Respect for User Privacy – Keep it User-Centric

As time has shown misunderstanding and incorrectly applying the prinicples of the Agile Manifesto has lead to severe development problems and technical debt.


One only needs to look at the modern application of the term agile to understand that its original meaning in many cases has been lost; such is the danger facing the principles of Privacy By Design and even now statements such as 'We Follow PbD Princples' are abound without any underpinning or engineering understanding of those principles in either code or process.

To move forward we must precisely understand how these principles can be integrated not just in to policies, but engineering requirements, design requirements, test cases, software development processes, analysis tools, development tools and even the very psyche of software engineering. Efforts such as the Privacy Engineer's Manifesto take the first step in addressing these aspects and the relationship between PbD.

However working from a purely top-down perspective does not solve all problems, but one needs to work simultaneous bottom-up from basic engineering and deeper theoretical perspectives and ensure that both directions of thought complement, balance and produce a consistent whole. We take the bottom-up approach here and do not attempt to define precise processes but rather present ontologies, structures and tools which can be adapted as local development practices require and dictate.

A Particle Physics Approach to Privacy

A while ago I read on the LtU programming language blog a discussion about the future of programming language research - is the going to be any? Haven't we metaphorically illuminated all there is to see about programming languages?  Surely the future discoveries and developments in this area are going to be very small and very deep?

One reply caught my eye:

"When you've searched around the lamp, trying looking underneath it."

And so I feel the same about privacy...we're spending huge amounts of time looking at its effects and very little and looking at what it is.

What are the fundamental structures of privacy and how to these manifest themselves upon the World at large?

Should we take a highly deconstructive approach to privacy? Break it apart into its constituent blocks, its fundamental atomic and sub-atomic structure?

In the same way as the LHC breaks apart subatomic particles to reveal the inner structure of the Universe, should we take a similar approach to privacy?

What are the subatomic particles, the quarks, the bosons, the fermions of privacy? Does it have a metaphorical Higgs-boson and related field which gives privacy its "mass"?

Fail fast, fail often, fail always

Apparently failing fast and failing often will lead to an eventual success, assuming of course that you are able to give the project or whatever it is time to develop and mature to a sufficient degree so that "failure" can be meaningfully assessed.

Failure does not necessarily mean that the project will not be a success, but rather that the technology, knowledge and product doesn't necessarily satisfy the current business goals. This is quite different from something that is a failure.

The mentality that everything should be an immediate success and that the smallest flaw is evidence of failure is killing not just research and innovation but the whole research and development process.

Furthermore the tendency to rapidly kill projects perceived to be failures without understanding what can be learned from those project and applied to bolster the next or parallel projects will eventually kill your business.

Innovation only comes from allowing scientists and engineers time to develop their ideas and not by rapidly killing those ideas before enough learning can be gained from them to benefit the overall business.

Indeed, if you do want to fail fast and fail often, ensure that you are learning from your mistakes and capitalising on the technologies and knowledge gained so that the fail often doesn't become fail always.

Understanding Software Engineering Accidents

The cause of 99.999...% of accidents is easy to ascertain, quite simply it is the pilot's/driver's fault. In the cases of two recent aviation and railway accidents (Asiana 214 and the Galicia's train crash) these were caused by the pilot and driver respectively....?

Finding the causes of an accident don't actually involve finding who is to blame but rather the whole context of what led up to the point where an accident was inevitable. And then even after that exploring what actually occurred during and after the accident.

The reasoning here is that if we concentrate on who to blame then we will miss all the circumstances that allowed that accident to occur in the first place. For example., in the case of the Galician train crash it has been ascertained that the driver was speeding, on the phone and had a history of breaking the rules. However this misses the more subtle questions of why did the train derail, why could the driver break the speed limit, what was the reasoning of the phone call, why did the carriages fail catastrophically after the derailment, did the safety systems work sufficiently, what state was the signalling in, did the driver override systems, was the driver sufficiently trained etc etc etc.

In other words, the whole context of the systems and organisation needs to be taken into account before appointing final blame; and even then very, very rarely is it single point of failure: the Swiss Cheese Model.

If we apply this model to software engineering and specifically accidents such as hacking and data breaches we become very aware of how many holes in our computing Swiss cheese we have.

Take a simple data breach where "hackers" have accessed a database on some server via an SQL injection via some web pages. If we apply our earlier thinking, it is obviously the fault of the 'stupid' system administrators who can't secure a system and the 'stupid' software engineers who can't write good code. Hindsight is great here isn't it?

To answer 'who to blame?' or better still 'why did things go wrong and how can we prevent this in the future?' we need to put ourselves, as other accident investigators do, in the position of those software engineers, system administrators, architects, hackers and managers AT THE POINT IN TIME WHERE THEY ACTED, and NEVER in hindsight.

Why did the trained, intelligent software engineer write code susceptible to SQLi in the first place?

Maybe they were under time pressure, no proper, formal design documentation, coding standards, never trained to spot those kinds of errors? Actually just stating that we have a failure of discipline is already pointing to wholesale failures across our whole organisation rather than just one individual.

Even if in the above case this was malice by the programmer, then why didn't the testing pick this up? Why was the code released without testing or checking? Now we have a failure elsewhere too.

Were there no procedures for this? Was the code signed-off by management with the risk in place? Now the net widens further across the organisation

and so on...

In aviation there is a term to explain most accidents: loss of situational awareness, which when explored invariably ends up with a multitude of 'wrong' choices being made over a longer period of time rather than just at those few critical minutes or hours in the cockpit.

I'm of the opinion that in software engineering that we almost always operate in a mode where we have no or little situational awareness. Our systems are complex, we lack formal models of our systems that clearly and concisely explain how the system works; indeed one of the maxims used by some practitioners of agile methods actively eschews the use of formality and modelling tools. Coupled with tight deadlines, a code-is-king mentality and rapidly and inconsistently changing requirements we have a fantastic recipe for disaster.

Bringing this back to an aviation analogy again, consider Turkish Airlines Flight 1951 which crashed as Schiphol in 2009. It was initially easy to blame the pilots for allowíng the plane to stall on final approach, but the whole accident investigation revealed deficiencies in the training, the approach procedures of Schiphol, a non-fault tolerant autothrottle and radar combination, a massively high workload situation for the pilots and ultimately a fault which manifested itself in precisely the behaviour that the pilots were requiring and expecting on their approach, that is the aircraft was losing speed.

As an exercise, how does the above accident map to what we experience every day in software engineering? Given high workloads, changing requirements, inconsistent planning and deadlines to get something (anything!) out that sort of works and we start getting answers to why intelligent administrators and programmers make mistakes.

Systems Safety - Defining Moments

As I've been concentrating on "safety improvements", or at least techniques for the improvement of system I've tended to concentrate on four areas:

• Aviation
• Industrial
• Medical (specifically surgical)
• Software Engineering (specifically information privacy)

The parallels between theses areas when it comes to what each define as "safety" and the techniques should be obvious. However the question remains what actually triggered each of these respective areas to take a more inherent safety approach and then what will trigger a similar approach with regards to information safety?

 

Above Diagram Key: Y-Axis: relative degree of safety embedded into that discipline, X-Axis, year of time since seminal incident.

Aviation safety's seminal moment was the 1935 crash of a Boeing Model 299 aircraft during a presentation flight. Instead of blaming the pilots, effort was made to understand the causes of the accident and develop techniques to help prevent similar accidents in the future.

For industrial safety the seminal moment was the 1974 Flixborough Disaster in the UK. This resulted in work on the design of industrial plants and the development of the notion of "inherent safety".

Surgical safety has quite a long tradition especially with the development of anaesthetic safety from the 1960s and the introduction of a proper systems approach. However anesthetists seem not to feature prominently as surgeons and doctors so the fame would probably go to Peter Pronovost et.al. for the Central Line checklist. This was probably one of the major contributors to the WHO Surgical Safety Checklist discussed in detail in Atul Gawande's book The Checklist Manifesto which brings together much of the above incidents. 

If you're still in doubt maybe Atul Gawande's article in the New Yorker magazine entitled The Checklist: If something so simple can transform intensive care, what else can it do? (Dec 10, 2007) might help.

Getting back to the crux of this article, what is the incident that will cause the wholesale change in attitudes and techniques to software engineering that instills such a sense of discipline that we can eradicate errors to such a degree that we could compare ourselves favourably with other disciplines?

The increasingly frequent hacking and information leaks? The NSA wiretapping and mass surveillance? Facebook and Google's privacy policies? None of these have had any lasting effect upon the very core of software engineering if any at all. Which either means that we place such low value on the safety of our information or that the economics of software are so badly formulated in society that the catastrophe would have to be so huge that it would have to cause societal change?

Interestingly, in software engineering and computer science we're certainly not short on techniques for improving the quality and reliability of the systems we're developing: formal methods (eg: Alloy, B, Z, VDM etc), proof, simulation, testing, modelling (in general). What we probably lack is the simplicity of a checklist to guide us through the morass of problems we encounter. In this last respect, this is why I think we're more like surgeons that modern day aviators; or, maybe some of us are like the investigators to the 1935 Boeing crash and other aviation heroes learning their trade?

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.

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.

Deconstructing Privacy

Some very constructive comments after my previous posting on the naivety of privacy - thanks to all who participated. So to address this problem that we are often talking cross purposes and without any common frame of reference we need to first take a look at in what terms we're framing privacy [of information systems].

Typically we see that privacy is addressed or framed in seven broad areas:

Each of these areas most certainly overlap but we have the difficulty of switching between these frames. For example, it is often the case that if we have great system security, then privacy is of little concern because we've addressed the problem of data leakage; however we haven't addressed the problem of data content because this is largely irrelevant to security. Similarly if we have great access control we don't have to worry about the data getting into the wrong hands? Or possibly that if we've presented the user with the necessary consents then all is fine?

If we firstly deconstruct each area and examine how each views privacy, then attempt a cross-referencing exercise between these, then we might actually have a basis for constructing, at least a framework for a common terminology and semantics.

On The Naivety of Privacy

Recent events regarding privacy and the internet have left me wondering if we are being somewhat naïve. We are starting to see a slew of new laws, strategies and technologies for protecting our privacy in what is effectively a public space. The end-user however is not, as far as I can tell, really getting the benefit of this - indeed if anyone is it is the emerging privacy-industrial complex [1] as some have written.

It is utterly naïve to believe that laws, strategies, intentions, grand speeches, certifications, automatic filtering, classification iconography and so on make for better end-user privacy. The more we do this the more confused we become, and simultaneously we lose sight of what we're really trying to achieve. Spare a thought for the poor end-users.

There is a great deal that is misunderstood or not known by privacy advocates about how the internet, computers and information systems work - I fear in a lot of cases either some don't want to understand because it takes them outside of their comfort zone, or the semantic gap between the engineers and the legal/advocacy side is too great and that bridging this gap is extraordinarily difficult for both parties.

I worry about our lack of formality and discipline, possibly in equal quantities. We – the privacy community – lack these aspects to really understand and accept the fundamentals of our area and how to apply this to the information systems we are trying to protect. In some cases we are actively fighting against the need to scientifically ground our chosen area.

We must take a moment to think and understand what problem we are really trying to solve. The more philosophical works by Solove and Nissenbaum address the overall concept of privacy. I'm not sure that the implications of these are really understood. Part of the problem is that general theories of information [2] are very abstract and obtuse when compared with the legal views of the above authors, and we've done very little to tie these areas together to produce the necessary scientific formalisation of privacy we need.

As an example, the Privacy by Design (PbD) manifesto is being waived by many to be the commandments of privacy and following these magically solves everything. This only leads to “technical debt” and greater problems in the future. Often we find the engineers, R&D teams and the scientists excluded from, and outside of, this discussion.

I think we're missing the point what privacy really is and certainly we have little idea at this time how to effectively build information systems with inherent privacy [3] as a property of those systems. I have one initial conclusion:

WE HAVE NO UNDERLYING THEORY OF PRIVACY

We have no common definitions, common language, common semantics nor mappings between our individual worlds: legal, advocacy and engineering. Worse, in each of these worlds terminology and semantics are not always so well internally defined.

When an [software] engineer says “data collection”, "log" or "architecture", these do not mean the same to a lawyer or a consumer advocate. Indeed I don't think these terms semantically map even remotely cleanly – if at all - between these groups.

A set of PowerPoint slides with a strategy, a vision, a manifesto, good intentions, project plan or a classifications scheme mean very little and without some form of semantics are wasted, token efforts that only add to the complexity and confusion of a rapidly changing field.

We desperately need to address the problem that we must create a way of communicating amongst ourselves through which all of the internal factions within the privacy community can effectively understand each other's point of view. Only then might we even have a chance of realistically and effectively addressing the moving target of privacy issues facing end- users and businesses that rely so much on the interchange and analysis of information.

The problem with formally (or rigorously) defining anything is that it has the nasty tendency to expose holes and weaknesses in our thinking. Said holes and weaknesses are not entirely appreciated, especially when it challenges an established school of thought or a political or dogmatic balance [4].

The privacy community is constantly developing new laws and legal arguments, new sets of guidelines, manifestos and doom scenarios while the engineers are trying to address these often inconsistent and complex ideas through technical means. From the engineering perspective not only we are internally exposing flaws in database design, information system architecture and user experience but also the mismatch between engineering, legal, the world of the consumer advocate and ultimately a company's information strategy.

An information strategy needs to address everything from how the engineers develop software to how you want your company to be perceived by the consumer. How many information strategies actually address the role that information plays in a modern, global consumer ecosystem where the central concept is the collection and processing of user information? Of those, how many address the engineering and scientific levels of information?

We must take a serious retrenchment [5] step and look back at what we have created. Then we need ruthlessly carve away anything that does not either solve the communication issue within the privacy community or does not immediately serve the end-user. Reemphasizing the latter point, this explicitly means the end-user values, not what we as a privacy community might perceive to be valued by the end-user.

We must fully appreciate the close link between privacy and information, and that privacy is one of the most crosscutting of disciplines. Privacy is going to expose every single flaw in the way we collect, manage, process and use information from the user experience, as well as the application and services eco-system, and even the manner in which we conduct our system and software engineering processes and information governance. The need to get privacy right is critical not just for the existence of privacy as a technical discipline in its own right (alongside security, architecture, etc) but also for the consumer and the business.

The emphasis must be placed on the deep technical knowledge of experts in information systems – these must be the drivers and unifiers between the engineers, the lawyers, the advocates and ultimately the users. Without this deep, holistic, scientific and mathematical foundation we will not be able to sufficiently nor consistency address or govern any issues that arise in the construction of our information systems at any level of abstraction.

If the work we do in privacy does not have a scientific, consistent and formal underpinning [6] that brings together the engineers, lawyers and advocates then privacy is waste of time at best and deeply destructive to the information systems at worst.

Without this we are a disjointed community caring for ourselves and not the business or consumer and privacy becomes just a bureaucratic exercise to fulfill the notions of performing a process and metrics rendered as meaningful as random numbers.

* * *

PostScript:

Via Twitter I came across a talk given by Jean Bezivin entitled "Should we Resurrect Software Engineering?" presented at the Choose Forum in December 2012. Many of the things he presented are analogous to what is happening in privacy. He makes the point a number of times that we have never addressed the missing underlying theory of software engineering and how to really unify the various communities, fields and techniques in this area. Two points I particularly liked was that we concentrated on the solution (MDE) but never thought about the problem; the other point is the use Albert Camus' quote

<< Mal nommer les choses, c'est ajouterau malheur du monde >>

[To misname things is to add misery to the world]

A subtle hint to getting the fundamentals right: terminology and semantics!


Notes

[1] #pii2012: The Emergent Privacy-Industrial Complex

[2] Jerry Seligmann, Jon Barwise (1997) Information Flow. Cambridge University Press.

[3] I like the idea of privacy being an inherent construct in system design in much the same way that inherent safety emerged from chemical/industrial plant design

[4] A blog article discussing “mathematical catastrophes” – two that come to mind are Russel and Frege and also Russel and Gödel. Both related but the latter’s challenge to the mathematical school of thought was dramatic to say the least.

[5] A formal retrenchment step in that we not just start again but actively record what we’re backtracking on. Poppleton et.al. constructed a theory of retrenchment for software design using formal methods; the same principles apply here.

[6] If you’re still in doubt just remember that whatever decisions are made with respect to privacy, there’s a programmer writing formal, mathematical statements encoding this. Lessig’s Code is Law principle.