Tuesday 15 April 2014

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.

Friday 4 April 2014

Legal Document Humour

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


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

Wednesday 2 April 2014

Privacy Engineering Book Contents

So as the Privacy Engineering book approaches its first major milestone, that of having the contents finalised and much of the chapters in a state for formal reviewing.

Though I must admit there are some quite unique spelling and grammatical errors in there at the moment; not to mention formatting but fortunately LaTeX is every helpful in that respect.



So here's the TOC:


  1. Introduction
  2. Case Study
  3. Data Flow Modelling
  4. Security Classifications
  5. Information Type Classifications
  6. Data Transformation Classifications
  7. Provenance Classifications
  8. Purpose and Usage Classifications
  9. Controller and Processor Classifications
  10. Identity Classifications
  11. External Classifications
    • Personal Information
    • PII
    • Traffic Data
    • Risk Classifications
  12. Requirements Structuring
  13. Policies and Control
  14. Risk and Privacy Impact Assessments
  15. Examples and Patterns
  16. Privacy Enhancing Technologies
  17. Constructing a Privacy Programming
  18. Privacy Auditing

As with all these things the specific ordering might change and some subsections might move but all-in-all things are now stable.

As with all work of this type, just the act of writing down things reveals glaring errors and missing knowledge - or at least many, many things that I have taken for granted. Take requirements engineering for example, just understanding how requirements are derived and structured has been a fairly major undertaking. Most of this is quite obvious but locked away in neurons and other structures [1] for the most part.

In other ways this has been very much like writing a PhD thesis, although without the fun of being a student and with added distractions of daily life, family and work; though the latter is the test-bed for many of these ideas and from where most of them were derived. I must admit finding technical areas where relatively little work has been made in the area of privacy, such as engineering requirements, has been enlightening, especially when one has to rely upon gut instinct and good old-fashioned research skills.

Still the joy of research especially when being led into areas such as organisational risk management, checklists, surgical and anaesthetic safety, aviation, industrial accident prevention, process etc is immensely fun.

Anyway, the deadline I'm working to is mid-May 2014, though to quote Douglas Adams:
“I love deadlines. I love the whooshing noise they make as they go by.”




References:

[1] Hagan, Hameroff & Tuszynski (2002) "Quantum computation in brain microtubules? Decoherence and biological feasibility," Physical Review E, 65, 061901.