When computers were real, and I mean the ZX Spectrum, the BBC Model B, the VIC-20 and all manner of 8-bit machines that booting straight into a BASIC interpreter (with a nod of the hat to the Jupiter ACE of course!), there was a little publishing company called Usborne who produced the most amazing books on computing. Now many of those books from the 1980s have been released free via their website.
One book in particular will always stand out for me:
On pages 24 and 25 is a listing for a game called Space Mines - a very simple simulation game based on selling ore for food and mines. That particular game got typed in, played with, modified, reimplemented and I guess in no small way started my love of simulation games which more than likely led to me writing a language for implementing simulations ( BSc degree final year project ) and later trying to simulate the behaviour of systems from their formally specified models ( PhD thesis ).
So to Usborne, the writers, editors and everyone involved in those books, especially the person or persons who wrote "Space Mines" my deepest, heartfelt thanks!
Showing posts with label Books. Show all posts
Showing posts with label Books. Show all posts
Tuesday, 9 February 2016
Friday, 17 July 2015
Privacy Engineering Book, 1 Year since publication
On the 18th of July, 2014 I published my first book: Privacy Engineering, a dataflow and ontological approach.
So, happy birthday to my book and the story of its writing can be found on this blog (here!). :-)
Since then I've been privileged to have invited talks at the IAPP's DP Intensive, IWPE 2015, various university lectures, an EIT SIG on Privacy, a semi-regular column on the IAPP's Privacy Tech blog and many other unexpected places - all to talk about the ideas in this book. Next up is a tutorial session at TrustCom 2015 in Helsinki in August with the authors of my "rival" book, The Privacy Engineer's Manifesto: Michelle Dennedy and Jonathan Fox of McAfee/Intel.
And it does feel good to call oneself "an author" ...gives one an air of gravitas...maybe I should start drinking absinthe and discuss philosophy while smoking a pipe?
So what's next? Well, a second book concentrating more on the modelling analysis should appear later this year - tentatively in December. Here's a preview of the cover:
Privacy Engineering is available on Amazon UK, Amazon US (as well as where ever else Amazon has sites), Barnes and Noble, CDON (Finland) and CreateSpace itself
Privacy Engineering: A Data Flow and Ontological Approach by Ian Oliver, 18 July 2014 (CreateSpace Independent Publishing). ISBN-13: 978-1497569713 ISBN-10: 1497569710 264 Pages, B/W on White Paper
So, happy birthday to my book and the story of its writing can be found on this blog (here!). :-)
Since then I've been privileged to have invited talks at the IAPP's DP Intensive, IWPE 2015, various university lectures, an EIT SIG on Privacy, a semi-regular column on the IAPP's Privacy Tech blog and many other unexpected places - all to talk about the ideas in this book. Next up is a tutorial session at TrustCom 2015 in Helsinki in August with the authors of my "rival" book, The Privacy Engineer's Manifesto: Michelle Dennedy and Jonathan Fox of McAfee/Intel.
And it does feel good to call oneself "an author" ...gives one an air of gravitas...maybe I should start drinking absinthe and discuss philosophy while smoking a pipe?
So what's next? Well, a second book concentrating more on the modelling analysis should appear later this year - tentatively in December. Here's a preview of the cover:
Privacy Engineering is available on Amazon UK, Amazon US (as well as where ever else Amazon has sites), Barnes and Noble, CDON (Finland) and CreateSpace itself
* * *
Privacy Engineering: A Data Flow and Ontological Approach by Ian Oliver, 18 July 2014 (CreateSpace Independent Publishing). ISBN-13: 978-1497569713 ISBN-10: 1497569710 264 Pages, B/W on White Paper
Wednesday, 8 July 2015
Tufte-LaTeX
Edward Tufte is well known for his work on textual and graphic presentations. His books, starting with The Visual Display of Quantitative Information are written with a very specific style, particularly in the way the pages are organised. Tufte uses wide margins which enforce the writing of side nodes.
For users of LaTeX there is a very good package called tufte-latex for emulating this style. I used this for the writing of the Privacy Engineering book [1], as an example page below shows:
There is a Google group for the discussion of the tufte-latex package, but I'll reproduce here my experiences of using this package so maybe a wider audience gets to know about this and how they might too use this excellent LaTeX package.
Originally written 20 July 2014, tufte-latex Google Group
References
[1] Ian Oliver. Privacy Engineering: a data flow and ontological approach. CreateSpace Independent Publishing.
For users of LaTeX there is a very good package called tufte-latex for emulating this style. I used this for the writing of the Privacy Engineering book [1], as an example page below shows:
![]() |
| Extract from book: Privacy Engineering - showing the Tufte style of page layout |
There is a Google group for the discussion of the tufte-latex package, but I'll reproduce here my experiences of using this package so maybe a wider audience gets to know about this and how they might too use this excellent LaTeX package.
Originally written 20 July 2014, tufte-latex Google Group
Just a few experiences on self-publishing and the Tufte-LaTeX style - I noticed a few questions and after going through this process successfully (yay!) I'll offer some thoughts here.
Firstly, I looked at a number of self-publishers, Lulu, CreateSpace etc. Of these CreateSpace gives the best options from book styles (colour, B/W, sizes), ISBN options, marketing etc. YMMV of course.
In the end I chose a 7x9 inch format for an academic text book, B/W printing on white paper. CreateSpace assigned the ISBN and deal with the purchasing and printing, plus the sales channels which are fairly extensive. The main problem is that you don't get an editor nor deadlines :-) So spelling checking is going to be your responsibility. You also don't get an advance from the publisher either, so no Ferrari while you complete your masterpiece....
My set up is as follows:
- Sublime and vi editors
- Bibtex
- Pdflatex
- Microsoft Visio Professional
running on Windows, MacOSX, Linux as necessary. Whether you like Visio or not, it is the best diagramming tool. You might also need Gimp for cropping pictures.
Actually, running LaTeX with the Tufte style is no more difficult than anything else in LaTeX but there are a few considerations:
- Tufte gives ample room for side notes - great for references and additional comments, marginalia etc
- You can no longer say things like "as demonstrated in [34]" because the reference number appears as a superscript. This changes the style of sentence in that you must explain what you're talking about instead of relying on the reader referring to the reference.
- Diagrams: be very careful with figure* and figure. Most of the time figure is fine and try to keep the diagram within the margins of the main body of text. Sometimes it is necessary to use the full width, but sparingly IMHO
- Tables: I used the full width unless the table was particularly simple. So table* for most.
- Labels: Didn't use as \ref{label name} doesn't give the section number. I suppose you could reference back to page, but (see #2) you can change your style of writing to make everything stand-alone. Actually I did refer back to figures and tables as necessary.
- Margins... I actually hacked tufts-common.def (see below)
- Tables again: see below for the Latex formatting not to use vertical lines - works well.
- Diagrams again: 300dpi minimum. I actually used 600dpi PNG files for inclusion in the text. If you export from PowerPoint this is going to be a big problem, but there are instructions to force PPT to export at 300dpi by adding things to the registry (fun!)
- Justified text for the body and sans serif sidenotes looks great!
I should have used \geometry but this was my method. I added between the A4paper and B5paper sections to tufte-common.def:
%%%%%%%%%%%%%%%%% IAN 7.44 by 9.69 inches
\newboolean{@tufte@ianpaper}
\DeclareOptionX[tufte] {ianpaper}{\setboolean{@tufte@ ianpaper}{true}}
Then later in the file (Search for a4paper and put it after there):
%%%%%%%%%%%%%%%%%%%%IANPAPER DEFINITION
%%%% 7.44in x 9.69in == 18.898cm x 24.613 cm
%Another modification for 300 page manuscript on CreateSpace
\ifthenelse{\boolean{@tufte@ ianpaper}}
{\geometry{paperwidth=7.44in, paperheight=9.69in,left=0. 75in,top=20mm,bottom=20mm, headsep=2\baselineskip, textwidth=3.86in,marginparsep= 0.28in,marginparwidth=1.8in, textheight=190\baselineskip, headheight=\baselineskip}}
{}
You'll need to play with the margins to get CreateSpace's previewer to stop reporting errors regarding the sizes and gutter etc. But you HAVE to do this anyway to get the book published regardless of whether you using Word, LaTeX etc. Now you can use the above as a document style, ie:
\documentclass[10pt,ianpaper, sfsidenotes,twoside,justified] {tufte-book}
When working with margins the showframe package is very, very helpful:
\usepackage{showframe}
Tables:
You need to work with the p{size} options quite a bit to get these perfect...lots of LaTeX recompiling sorry. For example, the following extract gives an idea:
\begin{table*}
\small
\begin{tabular}{ p{2.2cm} p{2.2cm} p{4.2cm} p{1.5cm} p{2.9cm} }
\hline
& \textbf{Adult} & \textbf{Child} & \textbf{System} & \textbf{External} \\ \hline\hline
Collection & Allowed, with consent & As per COPPA, but generally not allowed & Allowed & As per agreements \\ \hline
\end{tabular}
\caption[][0.5cm]{Example Policy Level Provenance Classification Requirements}
\end{table*}
I found that a double line after the title and single horizontal lines elsewhere looks good IMHO
Citations, Sidenotes, Captions and Marginalia:
This is going to be the biggest headache!!!
Don't fiddle with the layout of these until you've reached your final, final draft. I noticed that various PDF views won't show text outside the margins so things seem to disappear only to reappear in CreateSpace's previewer which tells you about these things. Once the text is finalised then work with moving these elements up and down to make the fit within the vertical margins of the page. Much trial and error. Note that captions take 3 parameters, sidenotes just 2 ... this caught me a few times!
Also, sometimes text in \url{} or unsplittable text exceeds the horizontal margins...YMMV and you'll have to find a work around. Again for these aspects the showframe package is very helpful.
TOC, Indexes:
ToC depth should be 1 otherwise the ToC becomes too long, even though I used subsections, these don't appear in the ToC. The list of tables and figures doesn't follow the ToC style, but given the length of the latter in my case I'm pretty happy about this! This could be moved to the back matter if you want, depending upon what you're writing of course.
makeindex for some reason did not work - I could not get indexes to work at all... :-( No idea why but in the end writing was more important than typesetting and indexes at that stage.
Font size:
I used \small with all the tables but didn't see a huge difference in font size. \tiny works, but that way too small. Otherwise things like \Huge etc work fine. Don't forget \normalsize after you've changed the font size temporarily :-)
So, overall Tufte-LaTeX is fairly easy to use with CreateSpace...thanks to all who gave help and worked on this style: it really does look fantastic in print! If you want to see the book you can go here: www.privacyengineeringbook.net and navigate to Amazon - I think there might be a preview available. However the conversion to Kindle is always a little problematical from what I've heard but then again not a lot you can do about that. Kindle doesn't like tables and sometimes the sidenotes get mixed in the text.
My preamble looks something like this:
Note I have two documentclass lines so I can swap between A4 for printing on rather obstinate HP laser printer and the 7x9 for the real version. Showframe is commented out here. A few other things I found on these groups such as the paragraph indentations etc. I changed the parskip here.
TOC depth I set to 1 otherwise the ToC becomes too long.
\documentclass[10pt,ianpaper, sfsidenotes,twoside,justified] {tufte-book}
%\documentclass[10pt,a4paper, sfsidenotes,twoside]{tufte- book}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{microtype}
%\usepackage{showframe}
\DeclareGraphicsExtensions{. pdf,.png,.jpg,.PNG}
%package to get copyright symbol
\usepackage{textcomp}
\makeatletter
% Paragraph indentation and separation for normal text
\renewcommand{\@tufte@reset@ par}{%
\setlength{\ RaggedRightParindent}{1.0pc}%
\setlength{\ JustifyingParindent}{1.0pc}%
\setlength{\parindent}{0pt}%
\setlength{\parskip}{14pt}%
}
\@tufte@reset@par
% Paragraph indentation and separation for marginal text
\renewcommand{\@tufte@margin@ par}{%
\setlength{\ RaggedRightParindent}{0.5pc}%
\setlength{\ JustifyingParindent}{0.5pc}%
\setlength{\parindent}{0pt}%
\setlength{\parskip}{6pt}%
}
\makeatother
\setcounter{tocdepth}{1}
\renewcommand{\ baselinestretch}{0.925}
%----------------------------- ------------------------------ -----------------------------
% BOOK META-INFORMATION
%----------------------------- ------------------------------ -----------------------------
\title{Privacy Engineering} % Title of the book
\author[I. Oliver]{Ian Oliver} % Author
%----------------------------- ------------------------------ -----------------------------
\begin{document}
%----------------------------- ------------------------------ -----------------------------
\frontmatter
\input{./FrontMatter/title}
\input{./FrontMatter/ copyright}
\input{./FrontMatter/ dedication}
\tableofcontents \thispagestyle{empty}
\listoffigures \thispagestyle{empty}
\listoftables \thispagestyle{empty}
%----------------------------- ------------------------------ -----------------------------
\mainmatter
\input{./introduction/ introduction}
\input{./CaseStudy/casestudy}
\input{./ privacyEngineeringProcess/ privacyengineeringprocess}
\input{./DataFlowModelling/ dataflowmodelling}
%lots of skipped chapters!!
\backmatter
\bibliography{privacyrefs}
\bibliographystyle{plainnat}
\input{./BackMatter/bio}
\end{document}
* * *
References
[1] Ian Oliver. Privacy Engineering: a data flow and ontological approach. CreateSpace Independent Publishing.
Tuesday, 28 April 2015
Modelling Privacy
Here's a teaser from the next book on privacy. ETA late 2015, December - just in time for Christmas - if I work really hard!
It will compliment the existing book Privacy Engineering and build upon more of the data flow modelling, use of taxonomies and techniques for analysing models such as those from safety critical engineering, eg: FMEA, RCA etc.
In the meantime, Privacy Engineering is available from Amazon.com, Amazon.co.uk, CreateSpace as well as Barnes and Noble and even book stores such as CDON.fi here in Finland.
It will compliment the existing book Privacy Engineering and build upon more of the data flow modelling, use of taxonomies and techniques for analysing models such as those from safety critical engineering, eg: FMEA, RCA etc.
In the meantime, Privacy Engineering is available from Amazon.com, Amazon.co.uk, CreateSpace as well as Barnes and Noble and even book stores such as CDON.fi here in Finland.
Wednesday, 30 July 2014
The Story of the Privacy Engineering Book
It was never going to be the next Harry Potter novel in neither content nor sales; thought I am open to offers from major film studios on buying the rights to my book in which case it isn't about data flow modelling and ontologies but the story of how Alice and Bob tried to keep their relationship private from Eve, Dave, Frank and the rest of the security character gang.
When writing a book, people often think that you must be an expert or genius to start. In fact this is quite the opposite, by writing a book you actually release that you are not an expert or genius in that area but become one (maybe) through making your thoughts and ideas explicit through the medium of print. Actually I think at the end you realise that being an expert is quite something else altogether.
The adage of "if you want to understand something then you should teach it" is what applies here. Following in the footsteps of Richard Feynman isn't too bad an idea regarding teaching.
The point of starting a technical book like Privacy Engineering was more to the conceptualise and concretise my thoughts and ideas on how I'd like systems to be modelled, analysed and understood from the privacy perspective.
In many ways writing the book was very much like writing my PhD thesis involving research just to understand the area, a thesis or hypothesis of how things work followed by the book keeping work of writing it down and documenting the sources of ideas and wisdom though copious references. Interestingly it took about the same amount of time from start to finish, approximately four years. I probably could have made it much quicker if it wasn't for the day job actually trying to analyse real systems but without that experience it would have been a dry, theoretical text without practical underpinning.
What surprised me, and maybe this comes from the training one received making a PhD, is that how "easy" it was to carve a niche in which I could be an expert (I'll come to what I mean by expert in a minute). It isn't that everything in the book is new but rather that the overall structure and application is "new". The Illustrated guide to a PhD really explains it best
What was particularly exciting was bringing together the ideas from the following areas
There were closer at hand experts too other than those famous names appearing on the covers of books and papers. My colleagues at Nokia and Here explicitly and implicitly influenced my ideas. One thing was painfully obvious was the lack of common terminology, not just inside privacy but when working between domains such as software engineer and law. Construction of a lingua franca was our main priority and much of this was influenced with the ontological work made earlier in NRC's Semantic Web Infrastructure project M3 and work with a certain Ora Lassila of RDF and Semantic Web fame.
Even more interestingly was that our ontologies turned out to be "implementable" in the sense that we could construct reasoning systems and tie these with our analytics systems running HADOOP etc, to perform "in-line analysis" of what was really passing through these systems. Furthermore we had started to workout how to calculate privacy policies - those legal texts that appear on the start-up of applications and you have to click on OK or Accept to continue. We never quite got around to integrating this with established policy languages, but the main thing was we now knew how all this fitted together.
For a long time however, and this drove much of the terminological work above, was my worry - shared by others - that privacy was just a bunch of people talking in different languages albeit with the same, or similar words. Worse was that everyone felt that their terminology was right and it was so obvious that everyone understood what they meant regardless of legal, engineering or other background. I wrote an article back in January 2013 entitled "On The Naivety of Privacy" that expressed my feeling on this and stated that we really didn't have a formal foundation to privacy. The replies to that article were surprising in that many people wrote to me, mainly privately, that they felt the same way. I had supporters, albeit a silent group that seemed to fear some kind of privacy orthodoxy. Either way, the path I needed to take in order to understand my role was clear(er).
So, as a summary so far, the only way to be an expert is to surround yourself with experts in lots of different areas. But, they have to be willing participants and willing to share their knowledge. At this point an overall structure was coming into focus and the initial plans on how to engineer privacy were coalescing nicely. Documenting this was an interesting struggle and a number of presentations were made on exploring ideas in this area to get feedback and understand what people really needed, or thought they needed. It turned out that some of the areas I was looking at formed great analogies:
The trouble with ideas such as these is that you can get side tracked easily, though such side tracking is essential to the though process. Being challenged on simple questions such as why the terminology was structured so, what that particular hierarchy of concepts, why that particular naming etc and being presented with links to other areas however is critical to obtaining some kind of focus to the work you are embarking upon.
It was April 2012 that I travelled to Tallin, Estonia to talk about obscure topics like category theory, topology and homotopy type theory with a colleague from the University of Brighton. On the ferry crossing from Helsinki to Tallin, accompanied with copious amounts of coffee (I'm with Alfred Renyi - misattributed to Paul Erdos - on this one!) I wrote the first full draft of all of the ontologies or taxonomies and their structuring that we needed. After this and a further meeting with Brighton's VMG group later that year the thesis was however set.
It is critical to state that during this time I wasn't working in some theoretical vacuum. The ideas, concepts, terms, modelling etc were being applied, albeit somewhat silently - subterfuge was the game. Formal methods were outlawed, agile was the true way...said by those who understand neither. It appeared that everything worked in both the software engineering and legal domains; with the caveat that it wasn't introduced as a whole but rather as bits of tooling and technique to be used appropriately when necessary.
At this point the book started in earnest, though the actual writing didn't start until late 2013 and the initial few chapters were collected together from earlier technical reports and presentations. Much, if not all, of the writing in those initial texts were rewritten many, many times. Ernest Hemmingway was telling the truth when we said, "The first draft of anything is shit."
When writing a book, people often think that you must be an expert or genius to start. In fact this is quite the opposite, by writing a book you actually release that you are not an expert or genius in that area but become one (maybe) through making your thoughts and ideas explicit through the medium of print. Actually I think at the end you realise that being an expert is quite something else altogether.
The adage of "if you want to understand something then you should teach it" is what applies here. Following in the footsteps of Richard Feynman isn't too bad an idea regarding teaching.
The point of starting a technical book like Privacy Engineering was more to the conceptualise and concretise my thoughts and ideas on how I'd like systems to be modelled, analysed and understood from the privacy perspective.
In many ways writing the book was very much like writing my PhD thesis involving research just to understand the area, a thesis or hypothesis of how things work followed by the book keeping work of writing it down and documenting the sources of ideas and wisdom though copious references. Interestingly it took about the same amount of time from start to finish, approximately four years. I probably could have made it much quicker if it wasn't for the day job actually trying to analyse real systems but without that experience it would have been a dry, theoretical text without practical underpinning.
What surprised me, and maybe this comes from the training one received making a PhD, is that how "easy" it was to carve a niche in which I could be an expert (I'll come to what I mean by expert in a minute). It isn't that everything in the book is new but rather that the overall structure and application is "new". The Illustrated guide to a PhD really explains it best
![]() |
| Your Contribution to Knowledge (from The Illustrated Guide to a PhD) |
- Software Engineering - modelling, analysis, coding, data-flow modelling, requirements analysis
- Ontologies, Taxonomies, Semantics
- Law (Privacy)
- Law (Philosophical)
- The Philosophy of Privacy
- Safety Critical Systems Design
- Aviation, Surgery, Anaesthesia, Chemical Plant Design
- etc
Maybe some of those areas surprise you? For example, what the $%^* has surgery got to do with privacy engineering? Many years ago we used to have a formal procedure for approving software project through various phases - concept, architecture, design, release. My job was to analyse and give approval for privacy from a software engineering perspective. Up until that point there were no software engineers in privacy, and an question of "do you have a privacy policy?" didn't really tell us anything. So procedures were put in place in the form of a set of questions - a checklist of things that must be done to move to the next stage. I got the idea from aviation!
It worked to a point, except that it was too rigid and didn't really fit into the more "agile" ways of working (agile, ad hoc, hacked...). After this is became a quest to find something that did fit, that did work in an environment where only when dissecting a piece of software you actually saw what was inside.
It was one of those serendipitous moments while reading some books on aircraft safety that I finally read Atul Gawande's book The Checklist Manifesto which lead me to Peter Pronovost's work and how CULTURE was the driver behind the workings of a safety oriented process. From this point onwards it was obvious (to me at least - with caveats) how we should approach privacy in software engineering: as a safety critical aspect!
Many, many experts have already discovered this - in aviation, surgery, anaesthesia, chemical plant design and so on. So, obviously I can't be an expert because *I* didn't know about this! Anyway, you can read about some this here:
There were closer at hand experts too other than those famous names appearing on the covers of books and papers. My colleagues at Nokia and Here explicitly and implicitly influenced my ideas. One thing was painfully obvious was the lack of common terminology, not just inside privacy but when working between domains such as software engineer and law. Construction of a lingua franca was our main priority and much of this was influenced with the ontological work made earlier in NRC's Semantic Web Infrastructure project M3 and work with a certain Ora Lassila of RDF and Semantic Web fame.
Even more interestingly was that our ontologies turned out to be "implementable" in the sense that we could construct reasoning systems and tie these with our analytics systems running HADOOP etc, to perform "in-line analysis" of what was really passing through these systems. Furthermore we had started to workout how to calculate privacy policies - those legal texts that appear on the start-up of applications and you have to click on OK or Accept to continue. We never quite got around to integrating this with established policy languages, but the main thing was we now knew how all this fitted together.
For a long time however, and this drove much of the terminological work above, was my worry - shared by others - that privacy was just a bunch of people talking in different languages albeit with the same, or similar words. Worse was that everyone felt that their terminology was right and it was so obvious that everyone understood what they meant regardless of legal, engineering or other background. I wrote an article back in January 2013 entitled "On The Naivety of Privacy" that expressed my feeling on this and stated that we really didn't have a formal foundation to privacy. The replies to that article were surprising in that many people wrote to me, mainly privately, that they felt the same way. I had supporters, albeit a silent group that seemed to fear some kind of privacy orthodoxy. Either way, the path I needed to take in order to understand my role was clear(er).
So, as a summary so far, the only way to be an expert is to surround yourself with experts in lots of different areas. But, they have to be willing participants and willing to share their knowledge. At this point an overall structure was coming into focus and the initial plans on how to engineer privacy were coalescing nicely. Documenting this was an interesting struggle and a number of presentations were made on exploring ideas in this area to get feedback and understand what people really needed, or thought they needed. It turned out that some of the areas I was looking at formed great analogies:
The trouble with ideas such as these is that you can get side tracked easily, though such side tracking is essential to the though process. Being challenged on simple questions such as why the terminology was structured so, what that particular hierarchy of concepts, why that particular naming etc and being presented with links to other areas however is critical to obtaining some kind of focus to the work you are embarking upon.
It was April 2012 that I travelled to Tallin, Estonia to talk about obscure topics like category theory, topology and homotopy type theory with a colleague from the University of Brighton. On the ferry crossing from Helsinki to Tallin, accompanied with copious amounts of coffee (I'm with Alfred Renyi - misattributed to Paul Erdos - on this one!) I wrote the first full draft of all of the ontologies or taxonomies and their structuring that we needed. After this and a further meeting with Brighton's VMG group later that year the thesis was however set.
It is critical to state that during this time I wasn't working in some theoretical vacuum. The ideas, concepts, terms, modelling etc were being applied, albeit somewhat silently - subterfuge was the game. Formal methods were outlawed, agile was the true way...said by those who understand neither. It appeared that everything worked in both the software engineering and legal domains; with the caveat that it wasn't introduced as a whole but rather as bits of tooling and technique to be used appropriately when necessary.
At this point the book started in earnest, though the actual writing didn't start until late 2013 and the initial few chapters were collected together from earlier technical reports and presentations. Much, if not all, of the writing in those initial texts were rewritten many, many times. Ernest Hemmingway was telling the truth when we said, "The first draft of anything is shit."
Apart from the practical battles:
- I chose the Tufte-LaTeX style in the end because it looked nice and they way it dealt with references and notes forced a certain way of writing.
- Sublime and vi as text editors
- Microsoft Visio as the drawing tool - I really wish they'd release a Linux, Mac and/or Cloud version.
- Version Control .... erm, a certain cloudified, file store...
things generally went well. Initial drafts complete with unique spelling and grammatical errors were well received by those who reviewed them. I even ran a short series of lectures with colleagues to go through the chapters. I joked that these lectures were very much in the style of Andrew Wiles' secret lectures to a trusted colleague explaining the proof of Fermat's Last Theorem.
By February 2014 the overall structure and plan was in place, albeit a little nebulous and fluid in places - the structure of sections and chapters was changing but not the content. Then I started on the requirements chapter and there it stopped. Nothing seemed to work, the formal structure of requirements was wrong, I couldn't get the mapping between the terminologies, data flows and requirements to work at all. And there I got stuck for two months. I knew what the requirements need to look like but nothing fitted together...nada, zilch...."f***" was the word of the day, week, month. With the possibility of missing my self inflicted deadline of May was it even worth continuing? Luckily I persevered.
In another moment similar to that of Wiles, there came the nightmare of another book on the same subject with the same title being published. "F***" times 2. I bought this damned book entitled The Privacy Engineers Manifesto and started to read it, hoping and praying that they didn't cover the same material. This is actually where it got interesting, PEM didn't cover my material but rather provided a hook between the ubiquitous Privacy-by-Design principles and software engineering. It actually laid out a path that linked the two. This wasn't a rival but rather a symbiotic, co-conspirator in the development of the discipline of privacy engineering. With some hope I pushed the deadline forward to June and attempted to restart the work.
It was actually back to pen and paper for drawing figures for a while as Microsoft just purchased Nokia's device's division and IT upgraded laptops, which meant a "many week" wait while Microsoft Visio was upgraded. During a latte fuelled moment there came the revelation on how these damned requirements and risk classifications would all link together:
![]() |
| 3 Dimensions of Requirements |
Simple eh? Well, not perfect but it did provide a high-level structure in which things did fit and did work. Hunting through academic papers on the subject gave some kind of impetus to the work and writing started afresh and at great pace. May and June were spent in-between work and family finalising the draft. The deadline slipped again - oh the joys of self-publishing and having no editor nor real deadline.
July was the sprint finish mainly rewriting paragraphs, spell checking and actually removing a chapter of examples and patterns as the text now contained these - due to in no small part to the secret lecture series which turned the book from academic text into something more practical. In mid-July it was finished with only the proofing to go and on the 17th of July it finally went on sale.
Somewhat of an anticlimactic moment it seemed, but that was it. Whether the book is perfect or not and whether ideas have changed or become refined in the meantime was now irrelevant, it was now public and another contribution to knowledge existed. After this was many days of thinking of "what the hell do I do now?"
A colleague once explained that writing a book is like pregnancy: there are three trimesters followed by, well, the trimesters are: excitement, boredom and panic - the latter as in, it has to come out. What follows after all this gore, mess and pain is the desire to write a new book.
So, am I an expert in this now? Well, yes in the sense that there aren't too many privacy engineers around but this belittles the term expert and gives it the wrong meaning. I now think that an expert is someone who understands what they don't know. There are huge areas that I want to know more about: human factors (cf: James Reason's Swiss Cheese Model) in privacy, formal underpinnings of privacy - yes, I love to write on a category theory foundation of this. There are experts around in requirements management, risk management etc that I'd love to talk to in bringing these areas into a much closer relationship with the structures we see in privacy. Information system security is another - it is something just assumed in privacy - whereas in software engineering it is an integral part.
The making of knowledge explicit is hard - unbelievably so. In fact, I am of the opinion that if you think you are an expert then you should go through the process of explaining and formalising your ideas in whatever your chosen area is; in other words, write a book about it. As presented earlier in the Illustrative Guide to a PhD, you spend all of your effort in adding that tiny amount to the sum of human knowledge but are rewarded with the ability to look back and see all of human knowledge and how it all fits together as a huge, holistic system. For a while you get your bit of this all to yourself, but this is closely followed by the desire to add another bit, and another, and another and so on. Knowledge is an addictive drug.
So that's the story. The book doesn't have wizards and car crashes, or a galactic princess who needs rescuing; the royalties will probably earn me a beer or two, but that really wasn't the point. Despite this sadomasochistic process what I have is an explicit, embodiment of my knowledge that can be shared - a conglomeration or summation of others' knowledge that I found a small niche to add to. I guess somewhere someone will find a flaw in my reasoning about privacy engineering and with luck suggest a solution and thereby adding a further contribution to our overall knowledge and development of this domain.
Actually I hope so.
ps: the second book...due 2015...deadlines permitting
Saturday, 19 July 2014
A Privacy Engineer's Bookshelf
There's a huge amount of material about privacy, software engineering etc already existing. So what should every privacy engineer have at minimum on his or her bookshelf? Here are my suggestions (I might be biased in some cases) which I think everyone working privacy should know about.
Of course this does not preclude other material nor a thorough search through the privacy literature, conferences and academic publications.
To be a privacy engineer really does mean engineering and specifically system and software engineering skills.
- Privacy Engineering: A Data Flow and Ontological Approach, Oliver
- The Privacy Engineer's Manifesto, Dennedy, Fox, Finneran
- Understanding Privacy, Solove
- Privacy in Context, Nissenbaum
- Applied Cryptograpy, Schneier
Of course this does not preclude other material nor a thorough search through the privacy literature, conferences and academic publications.
To be a privacy engineer really does mean engineering and specifically system and software engineering skills.
Friday, 6 June 2014
Privacy Engineering - The Book ... real soon now, I promise
Final push to complete the draft. Many many thanks to all that have provided numerous comments...We're probably looking at late July after the editorial process and the production of the first proof copy.
Ian Oliver (2014) Privacy Engineering - A Dataflow and Ontological Approach. ISBN 978-1497569713
Official Website: www.privacyengineeringbook.net
Facebook: facebook.com/privacyengineering
Ian Oliver (2014) Privacy Engineering - A Dataflow and Ontological Approach. ISBN 978-1497569713
Official Website: www.privacyengineeringbook.net
Facebook: facebook.com/privacyengineering
Wednesday, 5 February 2014
Writing...
Despite writing supposedly being cathartic...ha!...writing anything, from an academic paper to a forthcoming book is not a linear stream of word but a moulding of multiple, parallel, concurrent streams of conciousness into something appearing a whole.
I thought of the analogy with moulding a piece of clay into a work of art...and it works until you realise that piece of clay is probably a piece of s*** that you're holding. At which point you throw it away, wash your hands and feel disgusted and what you've done...
...and then feel more disgusted as to the time you've wasted and the work you've put in and what you've thrown away...warts and all...
It is at that point that you realise that somewhere in that piece of p** was a nugget of gold. So it's on with the rubber gloves to fish out that "clay", find the piece of gold (which may have just been a flash of sunlight if the first place), clean it off and continue with the moulding of your writing until you've achieved something that you're happy to abandon in public view. Just hoping that you've managed to wash off all the smell...
Hemmingway got it right:
The first draft of anything is shit.
I thought of the analogy with moulding a piece of clay into a work of art...and it works until you realise that piece of clay is probably a piece of s*** that you're holding. At which point you throw it away, wash your hands and feel disgusted and what you've done...
...and then feel more disgusted as to the time you've wasted and the work you've put in and what you've thrown away...warts and all...
It is at that point that you realise that somewhere in that piece of p** was a nugget of gold. So it's on with the rubber gloves to fish out that "clay", find the piece of gold (which may have just been a flash of sunlight if the first place), clean it off and continue with the moulding of your writing until you've achieved something that you're happy to abandon in public view. Just hoping that you've managed to wash off all the smell...
Hemmingway got it right:
The first draft of anything is shit.
...anyway I'm off to read Pirsig and walk the dog...maybe simultaneously....
Friday, 24 January 2014
Privacy Engineering - The Book
Shameless plug, but here's the working cover for my book on privacy engineering aimed at the software engineer whose job it is to construct information systems.
The book will concentrate on the tools and techniques for data flow modelling, information classification and reasoning about information systems from the privacy perspective.Also we will provide details of how to construct a privacy programme, auditing and investigation techniques as well as practical tools such as checklists and a discussion of the pros and cons of various privacy enhancing and enabling technologies.
The book will concentrate on the tools and techniques for data flow modelling, information classification and reasoning about information systems from the privacy perspective.Also we will provide details of how to construct a privacy programme, auditing and investigation techniques as well as practical tools such as checklists and a discussion of the pros and cons of various privacy enhancing and enabling technologies.
Friday, 18 November 2011
Wierd Tales
The Guardian has two interesting stories today, one fiction's unsolved mysteries and the other on "wierd" stories. This latter one has its own website complete with various tales...wierd.
Monday, 10 January 2011
Coelho Gives Away His Books - Newsweek
Very good article at Newsweek on how to deal with piracy...
Coelho Gives Away His Books - Newsweek
Confirming the fact that theless restrictions on usage, the more people will willingly pay instead of pirating it.
Same applies to software, hardware, whatever. If you make it difficult for the legitimate user/owner/reader/listener to use then they will use the priated version. Music and Film companies take note.
Coelho Gives Away His Books - Newsweek
Confirming the fact that theless restrictions on usage, the more people will willingly pay instead of pirating it.
Same applies to software, hardware, whatever. If you make it difficult for the legitimate user/owner/reader/listener to use then they will use the priated version. Music and Film companies take note.
Tuesday, 27 October 2009
Fy ymchwil am lyfrau i blant yn y Gymraeg
Dyma'r siôp da yng Nghaernarfon yn gwerthu llyfrau i blant ar y We. Ond, dydy'r tudalen chwilio ddim yn iawn o gwbwl, mae'n rhy anodd i ffeindio ac ymchwilio'r llyfrau, piti!
Hefyd ydy Dref Wen yng Nghaerdydd ...
Roeddwn i'n gobeithio ffeindio "The Cat in the Hat" (neu Y Gath yn yr Hêt) yn Gymraeg, dim lwc...
Hefyd ydy Dref Wen yng Nghaerdydd ...
Roeddwn i'n gobeithio ffeindio "The Cat in the Hat" (neu Y Gath yn yr Hêt) yn Gymraeg, dim lwc...
Subscribe to:
Posts (Atom)







