Re: pbd spec

Kim:

Terrific feedback. We could easily do what you suggest. We will still need to have a discussion on levels of conformance.

Thanks for taking the time to read through the draft.

Most sincerely,

Dawn

Sent from my iPhoneng 

On Jun 17, 2014, at 5:35 PM, Kim Cameron <> wrote:

Hello all,

 

The draft certainly represents a lot of great work and progress.  Congratulations.  Important and difficult ideas are succinctly expressed and explained in
 a way that will help software engineers.

 

Yet I think important organizational and framing work remains – not a lot of work, but important work. 

 

The most important question is, “How do we make this standard have a real impact?”  A related question, “Who is going to adopt it, and why?”  I worry that,
 as currently written, conformance will appear onerous and it will be difficult for engineering leaders to predict the cost of complying.  This is largely because the prescriptive and informational aspects of the document are conflated.  For example, on a first
 read of Chapter 3 it looks like the entire enterprise must be reorganized (“organizational readiness”) in order to be able to comply
J  My fear is that engineering leaders will see adoption of the current document as a foray into
 a swamp from which they may never return.  Where is the justification for the expense involved, whatever that is?  Unless engineering leaders are in some niche sector where conformance to this particular specification has been mandated, I fear they will revert
 to their old privacy check boxes rather than learn from all the good ideas that are being presented.

 

This sounds gloomy but I don’t mean it to be so.  I think a simple reorganization will fix it: 

 

1)     
start out with a very brief motivation of why PbD like security by design is a normal part of the software development process and a risk reduction
 strategy for software developers given the savings that come from being proactive rather than trying to retrofit, and that this specification streamlines the process of doing such design and achieving such savings.

2)     
Present the specific conformance requirements (literally a few pages) with all the MUSTS and a clear explanation that developers aren’t being blocked
 from developing solutions, just required to analyse and succinctly document how they have dealt with privacy issues .

3)     
Then put the WHOLE rest of the current document - all of the introductory information, process thinking, explanation of techniques and pedagogical
 material – into an “Annex to the Privacy by Design Documentation for Software Engineers Version 1.0” that is clearly identified as being informational and helpful to those implementing the specification.

 

The spec would therefore be only a few pages long – but economy would be a supreme virtue in getting the ideas adopted.  An engineering manager could easily
 read the requirements in the time available (very little usually…) and see the merit in and practicability of following them.  If done right, compliance would seem like something predictable and measurable rather than something that can grow into an uncontrollable
 expense.  

 

I hope you’ll forgive me for coming along when all the hard work has been done and suggesting a reorganization – I think it would help remove an obstacle to
 adoption, and that more software engineers will read the “helpful” annex  - that should stand as THE introduction to the field – than would read a spec eschewed by their managers.

 

Best regards,

 

Kim Cameron

 

From:  [mailto:]
On Behalf Of Fred Carter

Sent: Tuesday, June 17, 2014 4:15 PM

To: 'Dawn Jutla'

Cc: ; Michelle Chibba; David Weinkauf

Subject: [pbd-se] RE: pbd spec 

 

Dawn,

Yes I will follow your lead and prepare Section 2 and 4.1 in similar manner for tomorrow’s TC call.

Thx, Fred

 

From: Dawn Jutla [mailto:]

Sent: Monday, June 16, 2014 8:19 PM

To: Fred Carter

Cc: ; Michelle Chibba; David Weinkauf

Subject: Re: pbd spec v1r1 - Fred's revisions

 

Hi everyone:

 

In order for us to compose a Master document once more that we may vote on for a CSD, this is a heads up that I am incorporating all 7 sets of recent TC edits section by section (except for Section 2). For example in section 1, I have accepted
 most of the TC edits with just a few questions. I am listing a few questions at the end of each section when I have not addressed an edit, and/or reasons for rejecting them which the TC can discuss. I will upload the sections of the document to Kavi by tomorrow
 afternoon. As well as a complete document. 

 

Fred: will you be doing something similar for section 2 and the sub-principles of Table 4.1 with the TC edits or suggestions? Also a quick correction to your two most recent edits of the Revision History table. Kavi's public documents reflect
 that I suggested the creation of the PbD-SE methodology and initial mapping of the PbD principles to initial sub-principles, services, and documentation before March 6. Please can you change the edits that you made to the revision history back to March 6 from
 your recent update error to March 9? Also Kavi reflects Frank's spreadsheet contribution as the 7th and not your recent incorrect update of the revision history to the 9th. 

 

Looking forward to a long discussion on Wednesday.

 

Best,

Dawn.

 

On Mon, Jun 16, 2014 at 4:38 PM, Fred Carter <> wrote:

Attached are some additional suggested edits to section 2 and 4, including:

1.      
Revision to text of introduction and section 1.5 (definition of personal data)

2.      
Minor tweaks to wording of section 2 and 4

3.      
Added new Section 6: Conformance

These suggested edits will be included in the master chart.

Thx, Fred