[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Revised PbD Specification (pbd-se-v1.0-wd03)
|
PBD-SE TC Members, On behalf of the TC Co-chairs, please find attached a revised draft PBD Specification document (v3) incorporating comments received from members to date. All
revisions are shown in the attached document, but a “clean” version will be posted to the TC website repository. See below for details of changes and other issues for TC consideration and input. (yellow
highlighted text = suggested changes were adopted in the document) Who will hold the editing pen now? John/Gershon, can you incorporate your template into the draft Specification? Thx, Fred From:
Frank.Dawson@nokia.com [mailto:Frank.Dawson@nokia.com]
Hei Fred. Here are some comments to improve the text. Editorial: -
Clause 1.1, paragraph 1, sentence 1, replace “software design” with “software development”. This makes the sentence more
encompassing than just the design phase of software development. -
Clause 1.2, paragraph 1, last sentence, replace “PbD” with “Privacy by Design (PbD)”. Spell-out first occurrence of an acronym
or abbreviation. -
Clause 1.5, paragraph 1 and 2, are duplicate text. Remove one of them. -
Clause 1.5, “Personally identifiable information” should read “Personally Identifiable Information” and include the abbreviation
“PII”. -
Clause 1.5, “Personal Data” is used throughout the specification and should be added to the term definitions. -
Clause 2, paragraph 1, “(PbD)” should be removed, as it should have been specified in the first occurrence of the abbreviation
in clause 1.2. -
Clause 2, paragraph 2, sentence 1, “assurances” should be “assurance”. -
Clause 2, “Principle #1”, change “Principle #1” to “this principle” to be consistent with usage in other Principle descriptive
text. COMMENT: I DON’T UNDERSTAND THIS SUGGESTION – USAGE IN OTHER PRINCIPLE DESCRIPTIVE TEXT IS ALWAYS “Principle #x” -
Clause 2, “Principle #1”, change “should be demonstrably shared” to “is to be demonstrably shared” so as to avoid using the
conformance term SHOULD. -
Clause 2, “Principle #2”, sentence 1, “personally-identifiable information” should align with the term definition and be
replaced with “Personally Identifiable Information” or “PII”. -
Clause 2, “Principle #2”, last sentence, “(see below)” is not a concrete reference and should be removed. -
Throughout the document the usage of conformance terms “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
are to be in capitalized text. The use of these terms are to be avoided if the semantics is other than to indicate conformance requirements of the specification. COMMENT: Ok thanks got it! -
Throughout the document the use of “prima facie” and “inter alia” add an unnecessary legal or policy connotation to the specification.
These occurrences can be replaced with “explicit evidence” and “among other things” without loss of semantics but adding to the readability of the specification. -
Clause 2, “Principle #5”, The underlining of “Guidance for this Principle is NOT directly provided in this standard.” needs
to be removed. Overall basis for the standard is the Principles underlying PbD. -
Clause 2, “Principle #6”, The underlining of “Guidance for this Principle is NOT directly provided in this standard,” needs
to be removed. Overall basis for the standard is the Principles underlying PbD. -
Clause 2, “Principle #7”, The underlining of “Guidance for this Principle is NOT directly addressed in this standard,” needs
to be removed. Overall basis for the standard is the Principles underlying PbD. -
Clause 2, “Principle #7”, Change “human-centered, user-centric and user-friendly interfaces” to “user-centric and user-friendly
interfaces and experience”. The terms “human-centric” and “user-centric” seems redundant when used in the same sentence. Technical:
-
Clause 1.5, “Information privacy” term definition does not define information privacy but rather refers to Westin’s definition
of privacy. Suggest adding a sentence, “Information Privacy, then is the discipline of applying privacy principles to digital technology, such as the product of software development.”
-
Clause 1.5, “Personally Identifiable information” term definition should include, in addition to the “identifiability” and
“linkability”, the possible “observability”. Personal information can also become PII when, over time, through observation, the identity or naming/linkage of the personal information to the data subject/natural person can be established. The editor has the
liberty to select suitable additional text. -
Clause 1.6, “Normative References”, it is unclear where “Pfitzmann, A. & Hansen, M. A terminology for talking about privacy
by data minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management” is used as a normative reference in this specification. If it is not normatively used, it needs to be removed.
-
Clause 2, the use of conformance terms in this section should be removed. This section defines principles underlying the
Privacy by Design goals. As principles, they specify the WHY and the WHAT and not the HOW. Conformance requirements of the specification need to be quantitative and measurable, so that Implementation Conformance Specification and Conformance Tests can be defined
to allow implementations to be tested for absolute conformance. The use of conformance terms needs to be restricted to clauses of the specification where the HOW to implement is specified.
-
Clause 2, “Principle #2”, there is an unnecessary and probably invalid usage of the conformance term “shall”. Change “there
shall be a presumption” to “is to be a presumption”. Change “the precautionary principle shall apply” to “the precautionary principle is to apply”. Change “the default settings shall be the most privacy protective” to “the default settings are to be the most
privacy protective”.
-
Clause 2, “Principle #2”, on a technical level, not all conditions or parameters necessarily have “default” states. This is evident
in the W3C Do Not Track preference specification where the “DNT” HTTP header has no default value, but must be explicitly specified as either “DNT:0” or “DNT:1”, as defined in the formal notation of the HTTP header syntax. There are many other situations where
a default cannot be specified. As such, this principle should be translated to the Privacy Engineer as a design principle rather than as a logic requirement.
COMMENT: Not clear how this comment modifies the Specification or what exactly should be done in response. Both the PbD Principle and the Specification document
makes clear that the default mode of privacy protection is NO collection, use or disclosure of PII unless and until a positive case can be made for it. The question of what constitutes a default setting is interesting and important but somewhat besides the
point for TC purposes. It is for the engineer to establish and to document defaults in a manner consistent with the declared purpose(s), operating environment, and other variables and circumstances.
-
Clause 2, “Principle #3”, Change “embedding privacy should be adopted” to “embedding privacy is to be adopted”.
-
Clause 2, “Principle #3”, The text “amenable to external reviews and audits” anticipates that 3rd party, external audits
of a products software development is needed to apply this principle. This is not the actual case. “Privacy embedded into Design”can be achieved without an audit, internal or external. Predicating ability to conduct an external audit on a products development
lifecycle is not a viable condition to have this specification adopted by industry. Remove the text “, which are amenable to external reviews and audits”. -
Clause 2, “Principle #4”, Change “objectives must be clearly documented” to “objectives are to be clearly documented”. -
Clause 2, “Principle #4”, last sentence, The text “For the purposes of this standard, the documentation of key decision-making
processes at all phases of the software development lifecycle constitutes prima facie evidence of adherence to this principle.” is overtly prescriptive on an organization building software products. Many decisions in the software development process are so
minute that they are not documented. In face, this requirement does not achieve and is not the best method to determine if the principle has been met. The principle states that functionality or features offered to a use are not to be diminished because they
seek to have privacy control or safeguards implemented. The best method to measure this is a functional comparison of the features offered by a product when privacy is “turned on” and when it is “turned-off”. This could be achieved in a conformance testing
environment by suggesting that the Implementation Conformance Statement indicated which features are diminished or not available when privacy controls or safeguards are in place. For example, on a website with W3C DNT support, maybe contextuality of the search
results will be lost if DNT:1 is turned-on. This is a good example of where privacy enablement will not result in equal function. COMMENT: Not clear how this comment modifies the DRAFT Specification or what exactly should be done in response. The TC Work Plan is to focus on guidance on
and adherence to a single principle – Privacy as the Default (Setting) – so there is little emphasis on complying with the other principles except insofar as adherence to
Privacy as the Default supports the other principles. Put another way, documenting key decision-making processes at all phases of the software development lifecycle is a necessary but not sufficient condition for compliance with Principle #4. -
Clause 2, “Principle #5”, The text “There should be no gaps in either protection or accountability.” seems to be missing
text to complete the sentence. It should be removed, as no semantics are lost without it. COMMENT: The sentence as it stands makes sense to me. Not sure what is missing or what to add to “complete” it. -
Clause 2, “Principle #5”, Change “standards must assure” to “standards are to ensure”. The security standard “ensure” the
confidentiality, integrity and availability of the system. -
Clause 2, “Principle #5”, Change “Robust software security engineering methods, standards, and techniques already exist that
can be applied in support of this Privacy by Design Principle. (e.g., CERT SQUARE, ISO 15408)” to “Assessment standards such as CERT SQUARE, ISO 15408 are examples of existing methods and standards can be applied to demonstrate true evidence of this Principle. -
Clause 2, “Principle #6”, Replace “Guidance for this Principle is NOT directly provided in this standard, in part, because
documentation for end-users is specifically out of scope, as are mechanisms for external peer review and redress. However, adopters of this standard may nonetheless choose to make available detailed documentation to relevant stakeholders, including regulatory
authorities, business partners, customers and other end-users, documentation to external parties in support of this Principle.” with the text “True evidence of support of this Principle can be ensured by verifying and documenting at each stage in the product
development lifecycle that each Personal Information collected and processed is directly related to a primary purpose, by validating its need by a function or feature of the product, system or service.” -
Clause 2, “Principle #7”, I have always read into this Principle the inclusion of user settings to turn-on or turn-off privacy
enabling controls or safeguards. For example, turn-off geographical information EXIF tagging of JPEG photos from the camera settings. The use of user settings for controlling privacy safeguards or controls needs to be listed as true evidence of supporting
this Principle. -
Clause 2.1, “Privacy as the Default”, This clause has overlapping with Clause 2, “Principle #1”. If the purpose of restating
“Privacy by Default” in this section is to take the Principle into concrete context of software development then maybe the content of this clause should be a H1 level new section. For example, “3 Applying PbD Principles to Software Engineering”. Then this
clause would not start with the text “This principle:” but instead would indicate that the section defines best practices for applying PbD Principles to Software Engineering by definition of software design principles that need to be applied.
-
Text content for the proposed clause “3 Applying PbD Principles to Software Engineering” would include H2 subsections on:
o
Establishing a Product Team – Training and awareness on privacy fundamentals, identifying the team’s privacy and security
“Champion” that liases with the established Privacy Officer within the organization, establishing the product’s privacy vision to set a goal for the privacy impact threshold for the product, identifying which privacy framework and principles will be adopted
by the product team.
o
Defining the Product – Define the key user stories that scope the products features. These user stories will also be helpful
in creating data flow diagrams to be used in privacy threat analysis. These user stories also scope the primary and secondary purposes for any collection and processing of PII by the product.
o
Selection of Privacy Requirements – Based on the scoping of the product (EG, defined use cases), establish a list of product
privacy requirements and communicate across the product team. These requirements establish the default conditions for privacy within the product.
o
Data Governance/Stewardship – Begin defining the catalog of all the personal information created or referenced by the product
based on defined use cases. Once defined, classify the personal information in terms of accepted classification schemes (data category, use, format, storage, transfer recipients, sensitivity, security controls, etc).
o
Purpose Specificity and the other sections you have already outlined. Hope these comments help. Frank/ |
Attachment:
pbd-se-v1 0-wd03a.doc
Description: pbd-se-v1 0-wd03a.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]