CrIM'16 Keynote on Safety Critical Ideas in Privacy

Here are the slides and a longer presentation as a paper will be available soon:

Using Safety-Critical Concepts in Privacy Engineering from Ian Oliver

Privacy Metrics

Along with a colleage - Dr. Yoan Miche - we presented a paper outlining ideas regarding using mutual information as a metric for establishing some form of  'legal compliance' for data sets. The work is far from complete and the mathematics is getting horrendous!

The paper entitled "On the Development of A Metric for Quality of Information Content over Anonymised Data-Sets" was presented at the excellent Quatic 2016 conference held in Lisbon, Sept 6-9, 2016.

We were also extremely fortunate in that a presented in our session didn't turn up and we were graciously given the full hour not just to present the paper but give a much fuller background and details of future work and the state of our current results.

Here are the slides:

On The Development of A Metric for Quality of Information Content over Anonymised Data Sets from Ian Oliver

Abstract:

We propose a framework for measuring the impact of data anonymisation and obfuscation in information theoretic and data mining terms. Privacy functions often hamper machine learning but obscuring the classification functions. We propose to
use Mutual Information over non-Euclidean spaces as a means of measuring the distortion induced by privacy function and following the same principle, we also propose to use Machine Learning techniques in order to quantify the impact of said obfuscation in terms of further data mining goals.

Citation:

Ian Oliver and Yoan Miche (2016) On the Development of A Metric for Quality of
Information Content over Anonymised Data-Sets. Quatic 2016, Lisbon, Portugal, Sept 6-9, 2016.

Requirements Engineering and Privacy

A lot of travelling this month to conferences and speaking about privacy engineering (as usual). I just spent a week in Beijing at RE'16 (Requirements Engineering 2016) where I both presented a paper on privacy requirements and participated in a panel session on digitalisation and telecommunications - more on that later.

Anyway, here are the slides from the privacy paper:

Experiences in the Development and Usage of a Privacy Requirements Framework from Ian Oliver

And here is the abstract:

"Any reasonable implementation of privacy requirements can not be made through legal compliance alone. The belief that a software system can be developed without privacy being an integral concept, or that a privacy policy is sufficient as requirements or compliance check is at best dangerous for the users, customers and business involved. While requirements frameworks exist, the specialisation of these into the privacy domain have not been made in such a manner that they unify both the legal and engineering domains. In order to achieve this one must develop ontological structures to aid communication between these domains, provide a commonly acceptable semantics and a framework by which requirements expressed at different levels of abstractness can be linked together and support refinement. An effect of this is to almost completely remove the terms ‘personal data’ and ‘PII’ from common usage and force a deeper understanding of the data and information being processed. Once such a structure is in place - even if just partially or sparsely populated - provides a formal framework by which not only requirements can be obtained, their application (or not) be justified and a proper risk analysis made. This has further advantages in that privacy requirements and their potential implementations can be explored through the software development process and support ideas such as agile methods and ‘DevOps’ rather than being an ‘add-on’ exercise - a privacy impact assessment - poorly executed at inappropriate times."

Ian Oliver (2016) Experiences in the Development and Usage of a Privacy Requirements Framework. Requirements Engineering 2016 (RE'16), Beijing, China, September 12-17, 2016

2nd IW5GS - Programme

The 2nd International Workshop on 5G Security

IW5GS2016

Xi'an, China

June 19, 2016

http://www.mobimedia.org/2016/show/program-final

IW5GS-01: (June 19, 2016, Sunday, 10: 30 – 12:30, Room B)

Session Chair: Valtteri Niemi (Email: valtteri.niemi@helsinki.fi)

Keynote 1: 5G Security for IoT

Speaker: Dr. Zhiyuan Hu, Nokia Shanghai Bell  (zhiyuan.hu@alcatel-sbell.com.cn)

Keynote 2: 5G Security: Forward Thinking

Speaker: Bo Zhang, Huawei (liufei19@huawei.com)

IW5GS-02: (June 19, 2016, Sunday, 14: 00 – 16:30, Room B)

Session Chair: Siddharth Prakash Rao (Siddharth.rao@aalto.fi); Ian Oliver (ian.oliver@nokia.com)

Paper 1: Protecting IMSI and User Privacy in 5G Networks

Karl Norrman, Elena Dubrova, Mats Näslund

Paper 2: Privacy of the Long-Term Identities in Cellular Networks

Philip Ginzboorg, Valtteri Niemi

Paper 3: Error-Correcting Message Authentication for 5G

Elena Dubrova, Mats Näslund, Göran Selander, Karl Norrman

Paper 4: Privacy in LTE networks

Siddharth Prakash Rao, Bhanu Teja Kotte, Silke Holtmanns

Paper 5: A Survey on Software-Defined Networking Security

Shanshan Bian, Peng Zhang, Zheng Yan

Paper 6: Designing Hybrid Cloud Computing Framework using OpenStack for Supporting Multimedia with Security and Privacy

Isaac Cushman, Lei Chen, Danda B. Rawat, and Nhien-An Le-Khac

Agile is dead

This is an excellent post, though some might consider it a rant, about how Agile wasn't really nor became what Agile should it should have...

Agile is Dead

"Are you an IT consultant or contractor? Agile Software Development work is dead. If you practice that, you are a doorstop. If you manage that way, you are a boat-anchor. The wave has ended, it is over, and if you went for the head-fake and bought certifications, you wasted some money. Soon recruiters will be putting your resume in the circular storage container. I have been warning you for some time, and the day is here. Hah, you should have listened. Move along."

But here's the best quote:

The moral of this part of the story is that if you produce some compact politicised ideology (manifesto) consisting of principles and rules there will be unintended consequences.  Success creates a religion or cult, and defeat is being ignored.  No such doctrine is perfect.  Thinking you will change the world with a manifesto is naive, and if you succeed you may not have improved the world.

To me, given the problems that Privacy by Design has caused with privacy officers believing in some mythical "compliance" without any consideration of the software engineering or cultural aspects of developing information systems, this sums it up quite nicely!

Short abstract on privacy processes

Any reasonable implementation of privacy requirements can not be made through legal compliance alone. The belief that a software system can be developed without privacy being an integral engineering  concept and that a privacy policy is sufficient as requirements or compliance check is at best dangerous for the users, customers and business involved.

While requirements frameworks exist, the specialisation of these into the privacy domain have not been made in such a manner that they unify both the legal and engineering domains. In order to achieve this one must develop terminological or ontological structures to aid communication between these domains, provide a commonly acceptable semantics and a framework by which requirements expressed at different levels of abstractness can be linked together to provide refinement of these in some form. One interesting effect of this is to almost completely remove the terms ‘personal data’ and ‘PII’ from common usage and to force a deeper understanding of the data and information being processed.

Once such a structure is in place and even just partially or sparsely populated this provides a formal framework by which not only requirements can be obtained, their application (or not) be justified and a proper risk analysis made. This has further advantages in that privacy requirements and their potential implementations can be explored through the software development process supporting ideas such as agile methods and ‘DevOps’ rather than being an ‘add-on’ exercise - a privacy impact assessment - inappropriately executed at inappropriate times.

A long time ago...

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!

BToolkit

First post of the year and a little look back in time.  I used the formal methods tools BToolkit from BCore extensively during my PhD studies back in the late 90s. BToolkit at the time had very nice animation capabilities that I was utilising in order to formalise parts of the UML and OCL languages.

Later on I got to work with AtelierB and Rodin (B#) for hardware-software co-design and mapping UML into B and then Bluespec - and then into SystemVerilog for hardware synthesis.

While formal methods and hardware were extremely fun, I got called away to work on something called the "Semantic Device" and moved heavily into some weird stuff called "The Semantic Web" - that's another story of course...

Anyway, BToolkit's source code is available on github and it compiles without problem under Ubuntu 15.04.

Here's a screenshot of a little piece of formal methods history:

BToolkit running under Ubuntu 15 on VirtualBox

More Data Breach Excuses

This particular case reported on the BBC has a nice excuse...

Adele tickets: Fans claim personal data has been breachedBy Mark SavageMusic reporterFans buying tickets for Adele's tour have told the BBC they were shown the address and credit card details of customers other than themselves.
But several fans said they saw other people's shopping baskets, including payment details, upon check out.
Ticketing company Songkick said due to the "extreme load" on the site some customers could see others' account details. It apologised for any "alarm".
"At no time was anyone able to access another person's password, nor their payment or credit card details (which are not retained by Songkick)," it said.

So let's go through this and start with the last paragraph which states that no-one was able to access another person's password nor their payment or credit card details, yet, in the first paragraph it states that people were able to see payment details. 

I assume it means that the full credit card number, expiry date and CVC number were not available, however whoever makes these statements really needs to check with the engineers and really understand what they are being told.

The one I particularly like is that these errors happened due to "extreme load". Which suggests that the underlying system - UI, middleware, database etc were not implemented with concurrency in mind. 

I could imaging that the system probably wasn't load tested and/or that probably someone didn't use BASIC TRANSACTIONS which are present in, well, all databases - it has been part of the SQL standard for years and years. 

Worse is that someone probably tried to reinvent transactions or semaphores in an inherently distributed system and failed. Probably the system only worked up until now because various race conditions had never materialised - not even in testing - assuming that the tests had been properly created.

I can also imagine that the developers were rushed and probably forced to use some new technology that they didn't understand and that some manager somewhere had probably read an article about NoSQL and demanded that everything become a bizarre mix of Java, Clojure, Python, Ruby, XML, JSON, MongoDB and whatever web framework is currently in vogue.

Of course, at the end of the day it will be the engineers' fault ... which fails to address the issue of how such a system got signed off in the first place, let along from where came the requirements.

Furthermore I can imagine that testing was skipped or done badly because of a manager's false idea of what agile is...

So what we have here is a simple system that fails because of a misunderstanding of technology, non-functional requirements and most likely mis-management. I'd be willing to wager on that if we as engineers actually performed proper post-mortems or accident analyses on system failures instead of being forced to patch them up.

Ironically if they'd written in it COBOL it would all have worked fine... :-)

ABCDE....DevOps and Privacy, pt 2

Earlier I introduced the idea that DevOps, particularly in the area of privacy could take lessons from trauma medicine, particularly in taking on board ideas from ATLS.

This led to some further ideas about the relationships or analogies between disciplines - something we've already discussed before in the context of surgery, aviation and checklists.

As software engineering is being brought closer and closer to the metaphorical coal-face - we've moved away from requirements up-front to agile and now to "DevOps" where engineering and operations become the same thing we are starting to see the need to move to much more structured and disciplined teams of engineers. If this isn't happening then there are some serious cultural and management problems.

As this shift happens we have to develop techniques to deal with this - as already mentioned checklists and ATLS provide the necessary kind of structures.

By why ATLS in particular? Well, we can draw an analogy between DevOps and trauma medicine in that DevOps operates with extremely short time-scales and in an environment where fixes and patches need to be very quick and leave the system in a stable state where a longer-term patch can be made later.

DevOps is the ER of the software engineering world.

DevOps and the ABC(DE[FG]) of Privacy

Or maybe this should be called the ATLS of privacy perhaps?  ATLS, or Advanced Trauma Life Support is a training programme for dealing with medical trauma incidents and is typically used by first responders such as paramedics to an incident.

Now as we move to a DevOps oriented model - think of a highly integrated Agile with a "right now" delivery timescale - then the way we will have to react to compliance, privacy impact assessments, privacy engineering etc is going to be on the same kind of time-scale. Certainly if we are late or delayed with the PIA then the product is going to be shipped - with some interesting security and privacy consequences certainly!

So, I conjecture it makes sense that we bring our PIA/compliance activities not just to the engineering level but also to the speed of development and operations.

This means that the PIA is going to have to be extremely focused and very strictly run. Effectively we need the DevOps privacy version of the medical ABC.

The question then becomes what is the equivalent to the medical ABC?

As I've stated before, privacy can [must] learn a lot of things from medicine (and aviation) - such as checklists - in that they both work in very agile, unstructured and reactive environments. Privacy in a DevOps situation can not rely upon traditional compliance or work at the usual, relative glacial speed associated with such work.

References

Ian Oliver (2015). Privacy as a Safety Critical Concept. 1st International Workshop on Privacy Engineering. California. (Keynote Talk)

Ian Oliver (2014). Privacy Engineering: A Data Flow and Ontological Approach. CreateSpace. 978-1497569713 (see: http://www.amazon.co.uk/dp/1497569710  )

Second International Workshop on Privacy Engineering (IWPE'16)

Second International Workshop on Privacy Engineering (IWPE'16)
Co-located with 37th IEEE Symposium on Security and Privacy

26 May 2016 - The Fairmont, San Jose, CA

************************************************************

IMPORTANT DATES

Deadline for abstract submission: 18 January 2016
Deadline for paper submission: 8 February 2016
Notification of acceptance: 22 February 2016
Accepted paper camera-ready: 3 March 2016 

************************************************************
 
We are pleased to invite you to participate in the Second International Workshop on Privacy Engineering (IWPE'16).

Privacy engineering research has never been a more timely endeavor. Ongoing news reports regarding global surveillance programs, massive personal data breaches in corporate databases, and notorious examples of personal tragedies due to privacy violations have intensified societal demands for privacy-friendly systems. In response, current legislative and standardization processes worldwide are seeking to strengthen individuals’ privacy by introducing legal and organizational frameworks that personal data collectors and processors must follow. As a result, engineers are increasingly expected to build and maintain systems that preserve privacy and comply with data protection standards in different ICT domains (such as health, energy, transportation, social computing, law enforcement, and public services) and on different infrastructures and architectures (such as cloud, grid, or mobile computing).

Although there is a consensus on the benefits of an engineering approach to privacy, few concrete proposals exist for models, methodologies, techniques and tools to support engineers and organizations in this endeavor. Work that focuses on helping organizations and software developers to identify and adopt appropriate privacy engineering methods, techniques and tools in their daily practices is also missing. Furthermore, it is difficult to systematically evaluate whether the systems developed using privacy engineering methodologies comply with legal frameworks, provide necessary technical assurances, and fulfill users’ privacy requirements.

Clearly, more research is needed in developing methods that can help translate legal and normative concepts, as well as user expectations, into systems requirements. There is also a growing need for techniques and tools to support organizations and engineers in developing and maintaining (socio-)technical systems that meet these requirements. In an effort to close the gaps in research, the topics of IWPE'16 include all aspects of privacy engineering, ranging from its theoretical foundations, engineering approaches and support infrastructures to its practical application in projects of different scales.

Specifically, we are seeking the following kinds of papers:

1.  technical solution papers that illustrate a novel formalism, method or other research finding with preliminary evaluation;
2.  experience and practice papers that describe a case study, challenge or lessons learned in a specific domain;
3.  early evaluations of tools and techniques that support engineering tasks in privacy requirements, design, implementation, testing, etc.;
4.  interdisciplinary studies or critical reviews of existing privacy engineering concepts, methods and frameworks; 
5.  vision papers that take a clear position informed by evidence based on a thorough literature review.

IWPE’16 welcomes papers that focus on novel solutions based on recent developments in privacy engineering. Topics of interest include, but are not limited to:

• Integrating law and policy compliance into the development process
• Privacy impact assessment during software development
• Privacy risk management models
• Privacy breach recovery methods
• Technical standards, heuristics and best practices for privacy engineering
• Privacy engineering in technical standards
• Privacy requirements elicitation and analysis methods
• User privacy and data protection requirements
• Management of privacy requirements with other system requirements
• Privacy requirements implementation
• Privacy engineering strategies and design patterns
• Privacy-preserving architectures
• Privacy engineering and databases
• Privacy engineering in the context of interaction design and usability
• Privacy testing and evaluation methods
• Validation and verification of privacy requirements
• Engineering of Privacy Enhancing Technologies (PETs)
• Integration of PETs into systems
• Models and approaches for the verification of privacy properties
• Tools and formal languages supporting privacy engineering
• Teaching and training privacy engineering
• Adaptations of privacy engineering into specific software development processes
• Pilots and real-world applications
• Evaluation of privacy engineering methods, technologies and tools
• Privacy engineering and accountability
• Organizational, legal, political and economic aspects of privacy engineering

This topic list is not meant to be exhaustive, as IWPE'16 is interested in all aspects of privacy engineering. However, to screen out off-topic papers early in the review process, we request authors to submit an abstract prior to their paper submission. Abstracts of papers without a clear application to privacy engineering will be considered outside the scope of this workshop and may be rejected.

************************************************************

PAPER FORMAT & SUBMISSION GUIDELINES

We solicit unpublished short position papers (up to 4 pages) and long papers reporting technical, research or industry experience (up to 8 pages) on all dimensions of the privacy engineering domain. Each paper, written in English, must follow IEEE Proceedings format. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will attend the workshop to present the paper.

Abstracts and papers must be submitted via EasyChair

All IWPE'16 Papers will be published in IEEE eXplore, which is indexed by EI Engineering Index, ISI Conference Proceedings Citation Index (CPCI-S), Scopus, etc.

Privacy Engineering Tutorial at TrustCom 2015

Privacy Engineering Tutorial
Held in Conjunction with TrustCom 2015 Helsinki, Finland
 
Friday 21, August 2015

NB: Go Here for the TrustCom 2015 Registration Details.

10h05-11h50 – Session I
 
The Privacy Engineer’s Manifesto
Jonathan Fox, Michelle Dennedy, Intel/McAfee

“The Privacy Engineer's Manifesto: Getting from Policy to Code to QA to Value is the first book of its kind, offering industry-proven solutions that go beyond mere theory and adding lucid perspectives on the challenges and opportunities raised with the emerging "personal" information economy”

In this session you will learn the guiding principles of privacy engineering; how legal, management, business and process interact, and gain the foundational knowledge for implementation of a privacy engineering programme.

13h10-14h55 – Session II
 
Invited Talk: Software Engineering Aspects of Privacy
Antti Vähä-Sipiliä, F-Secure

Software security initiatives are becoming more common. We'll cover how privacy engineering can be supported by real-life security practices, and how a modern software development organisation can integrate privacy engineering in both requirements and delivery activities

In this session you will obtain a deep insight into how privacy engineering practices have been applied in a real-world scenario.

15h15-17h00 – Session III
 
Privacy Engineering
Ian Oliver, Nokia

To construct information systems from small mobile 'apps' to huge, heterogeneous, cloudified systems requires merging together skills from software engineering, legal, security and many other disciplines - including some outside of these fields! Only through properly modelling the system under development can we fully appreciate the complexity of where personal data and information flows; and more importantly, effectively communicate this.

In this session aspects of modeling systems and terminology/ontologies for privacy are presented. This will enable you to better understand, communication and reason about the privacy (and security) aspects of your systems. This session also presents how models of a system, requirements and risk analysis fit together. The session concludes with an overview of analysis techniques such as FMEA, RCA and process integration and auditing will also be presented.

Supporting Material
 
The tutorials draw upon the material presented in the following books:

• Ian Oliver (2014). Privacy Engineering: A Dataflow and Ontological Approach. CreateSpace Independent Publishing. 978-1497569713, www.privacyengineeringbook.net
• Michelle Dennedy, Jonathan Fox, Thomas Finneran (2014). The Privacy Engineer's Manifesto: Getting from Policy to Code to QA to Value. APress. 978-1430263555

International Workshop on 5G Security - Programme

The 1st IEEE International Workshop on 5G Security held in conjunction with IEEE TrustCom-15

There is a fast on-going change in the technical architectures and topologies of the Internet: in the near future 5G and next generation 4G/LTE network architectures will be based on or migrated to Software Defined Networking (SDN) and Network Functions Virtualization (NFV). These create new virtual network elements each affecting the logic of the network operation, traffic management and introducing new and novel security challenges. Aspects such as security of orchestration, management functionality as well as surveillance and privacy are brought to the fore. At the same time they introduce new ways of dealing with attack prevention, management and recovery.

The one-day workshop will consist of papers, presentations and demonstrations on the subject of advanced network security. While primarily related to 5G networks, experiences from 4G/LTE, 3G and earlier, including case studies on practicalities of known attacks and novel attack vectors will be considered for acceptance. An invited keynote speech will be given setting out the overall area of security in network development and operations.

IW5GS Programme
TrustCom 2015 Helsinki, Finland
Friday 21, August 2015

10h05-11h50 – Session I

• Ian Oliver, Silke Holtmanns, Workshop Opening
• Günther Horn and Peter Schneider, Towards 5G Security
• Siddharth Prakash Rao, Silke Holtmanns, Ian Oliver and Tuomas Aura. Unblocking stolen mobile devices using SS7-MAP vulnerabilities
• Vikramajeet Khatri and Joerg Abendroth, Mobile Guard Demo - Network Based Malware Detection

13h10-14h55 – Session II

• Ian Oliver, Aspects of 5G Security
• Nicolae Paladi and Christian Gehrmann. Towards Secure SDN-based Multi-tenant Virtualized Networks
• Elena Dubrova, Mats Näslund and Göran Selander. CRC-Based Message Authentication for 5G Mobile Technology
• Prajwol Kumar Nakarmi, Oscar Ohlsson and Michael Liljenstam. An Air Interface Signaling Protection Function for Mobile Networks: GSM Experiments and Beyond

15h15-17h00 – Session III

• Bengt Shalin, keynote talk
• Mingjun Wang and Zheng Yan. Security in D2D Communications: A Review
• Karl Norrman, Mats Näslund, Bengt Sahlin and Jari Arkko. A USIM compatible 5G AKA protocol with perfect forward secrecy
• Silke Holtmanns,Ian Oliver, Workshop Closing

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

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:

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:

1. Tufte gives ample room for side notes - great for references and additional comments, marginalia etc
   
   
2. 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.
   
   
3. 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
   
   
4. Tables: I used the full width unless the table was particularly simple.  So  table*  for most.
   
   
5. 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.
   
   
6. Margins... I actually hacked tufts-common.def (see below)
   
   
7. Tables again: see below for the Latex formatting not to use vertical lines - works well.
   
   
8. 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!)
   
   
9. 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.