[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [pbd-se] Groups - pbd-se-v1 0-wd02.doc comments
Here are some comments to improve the text.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]