Structure of the cookbook

[xot]

Currently the document is structured in terms of application areas.

The core contributions to the cookbook should, in my mind, be descriptions of generic, privacy friendly, solutions to a recurring problem. Some call them privacy design patterns. Some of these problems (and patterns) occur in one application area; others may surface in many. Question is then where to put them in the current structure.

[ghost]

I don't have any problem with that, but wonder then what the alternative structure would look like - if we do not have the current suggestion

* Prerequisites
* Engineering Lifecycle
* Hardware
* Software
    * Webapps and services
    * Mobile Apps
    * Desktop software
    * Components and libraries
    * Operating systems
    * Network infrastructure services
    * Data stores
    * Analytics & BigData
* Resources

Would something like this be better (not neccessarily these topics, but this approach)

• Securing passwords
• Obtaining consent for tracking
• Implementing a retention policy in a database
• Meeting the requirement to provide access to personal data
• Anonymising log files
• When to use cookies
• Hardening a web server
• Building webapps with PbD
• Privacy as a non-functional-requirement
• When to use federated identity
• Good ways to create notifications
• Implementing access controls for privacy
• Classifying data for privacy
• When to call your lawyer !
• Unit testing usage of personal data
• How to manage change with privacy
• What protocols to use for secure messaging
• Reinventing the internet in three easy steps

If so, does this do enough to get the big picture across - the PbD applies throughout the lifecycle - or do we also the need to specifically address the legal, process and organisational aspects or crossover in the engineering lifecycle