[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: pbd spec
|
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: pbd-se@lists.oasis-open.org [mailto:pbd-se@lists.oasis-open.org]
On Behalf Of Fred Carter 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:dawn.jutla@gmail.com]
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 <Fred.Carter@ipc.on.ca> 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]