PING Comments On Mitigation Strategies

index.src.html

@@ -98,7 +98,7 @@ <h2 id="intro">Introduction</h2>
   *   External audience (developers, designers, etc.) wanting to understand the
       possible security and privacy implications.
 
-<h2 id="threats">How To Use The Questionnaire</h2>
+<h2 id="howtouse">How To Use The Questionnaire</h2>
 
   Thinking about security and privacy risks and mitigations early in a project
   is the best approach as it helps ensure the privacy of your feature at an
@@ -610,6 +610,11 @@ <h2 id="mitigations">
     Mitigation Strategies
   </h2>
 
+  To mitigate the security and privacy risks you’ve identified in your
+  specification as you’ve filled out the questionnaire and consulted with PING,
+  you may want to apply one or more of the mitigations described below to your
+  feature.
+
   <h3 id="secure-contexts">
     Secure Contexts
   </h3>
@@ -639,15 +644,17 @@ <h3 id="drop-feature">
     Drop the feature
   </h3>
 
-    The simplest way to mitigate potential negative security or privacy impacts of a feature,
-    and even discussing the possibility, is to drop the feature.
-    Every feature in a spec should be considered guilty (of harming security and/or privacy) until proven otherwise.
+    The simplest way to mitigate potential negative security or privacy impacts
+    of a feature, and even discussing the possibility, is to drop the feature.
+    Every feature in a spec should be considered guilty (of harming security
+    and/or privacy) until proven otherwise.
 
-    Every specification should seek to be as small as possible, even if only for the reasons of reducing
-    and minimizing security/privacy attack surface(s).
+    Every specification should seek to be as small as possible, even if only
+    for the reasons of reducing and minimizing security/privacy attack surface(s).
 
-    By doing so we can reduce the overall security (and privacy) attack surface of not only a particular feature,
-    but of a module (related set of features), a specification, and the overall web platform.
+    By doing so we can reduce the overall security (and privacy) attack surface
+    of not only a particular feature, but of a module (related set of
+    features), a specification, and the overall web platform.
 
     Examples
 
@@ -658,39 +665,29 @@ <h3 id="sanitize-data">
         Sanitize the data handled in the feature
       </h3>
 
-      It is always a good strategy to consider the kinds of data a new feature is processing. For example, new features allowing the readout of data may want to adopt specific privacy strategies such as minimizing the quality of datas (quantization) or reducing the frequency, in line with standard privacy engineering practices. Examples
-      *   [BATTERY-STATUS-API] <em>“The user agent should not expose high precision readouts”</em>
+      It is always a good strategy to consider the kinds of data a new feature
+      is processing. For example, new features allowing the readout of data may
+      want to adopt specific privacy strategies such as minimizing the quality
+      of datas (quantization) or reducing the frequency, in line with standard
+      privacy engineering practices. Examples
+      *   [BATTERY-STATUS-API] <em>“The user agent should not expose high
+        precision readouts”</em>
       * [SENSORS-API] <em>“Limit maximum sampling frequency”, “Reduce accuracy”</em>
 
 
       <h3 id="user-mediation">
         Making a privacy impact assessment
       </h3>
 
-      Some features are potentially supplying very sensitive data, and it is the end-developer,
-      system owners, or managers responsibility to realize this and act accordingly in the design of his/her
-      system. Some use may warrant conducting as privacy impact assessment, especially when data relating to
-      individuals may be processed. Examples.
-
-      *   [GENERIC-SENSORS] advices to consider performing of a privacy impact assessment
+      Some features are potentially supplying very sensitive data, and it is
+      the end-developer, system owners, or managers responsibility to realize
+      this and act accordingly in the design of his/her system. Some use may
+      warrant conducting as privacy impact assessment, especially when data
+      relating to individuals may be processed. Examples.
 
+      *   [GENERIC-SENSORS] advices to consider performing of a privacy impact
+      assessment
 
-</section>
-
-<section>
-  <h2 id="howtouse">How to Use the questionnaire</h2>
-
-  To ensure good designs, security and privacy should be considered as early as possible.
-  This questionnaire facilitates this and the questions should be considered early in the specification development
-  process, kept in mind as it matures, with the answers being updated along the specification evolution.
-  This questionnaire should not be used as a “check box" excercise before requesting final publication - acting in
-  this manner does not help improve privacy or security on the Web.  Each question needs to be considered and that
-  any privacy or security concerns are described, along with a possible mitigation strategy.
-  It is not a good approach to provide a one-word answer (“yes” / “no”). Rather, it is expected to include an
-  explanatory description. The questions in the questionnaire are more about “why” and “how”, rather than “if”.
-
-  It is expected that a questionnaire must be filled in prior to obtaining a W3C Working Draft status, and prior to requiring a review, along the Privacy by Design principles.
-  The questionnaire and its answers should not be included in the specification itself. It is preferable to keep it in a standard and easily available place, with a link available in the TAG repository.
 
 </section>