dap commit: Improve security and privacy considerations.

changeset:   592:abe11905e4dc
tag:         tip
user:        Anssi Kostiainen <anssi.kostiainen@intel.com>
date:        Thu Aug 20 15:50:38 2015 +0300
files:       battery/Overview.html battery/Overview.src.html
description:
Improve security and privacy considerations.


diff -r 16d476e0af31 -r abe11905e4dc battery/Overview.html
--- a/battery/Overview.html	Thu Aug 20 15:21:34 2015 +0300
+++ b/battery/Overview.html	Thu Aug 20 15:50:38 2015 +0300
@@ -676,7 +676,7 @@
   and notes in this specification are non-normative. Everything else in this specification is
   normative.
 </p>
-<p id="respecRFC2119">The key words <em class="rfc2119" title="MUST">MUST</em>, <em class="rfc2119" title="MUST NOT">MUST NOT</em>, and <em class="rfc2119" title="SHOULD">SHOULD</em> are 
+<p id="respecRFC2119">The key words <em class="rfc2119" title="MAY">MAY</em>, <em class="rfc2119" title="MUST">MUST</em>, <em class="rfc2119" title="MUST NOT">MUST NOT</em>, and <em class="rfc2119" title="SHOULD">SHOULD</em> are 
   to be interpreted as described in [<cite><a class="bibref" href="#bib-RFC2119">RFC2119</a></cite>].
 </p>
 
@@ -722,11 +722,26 @@
       <!--OddPage--><h2 id="h-security-and-privacy-considerations" resource="#h-security-and-privacy-considerations"><span property="xhv:role" resource="xhv:heading"><span class="secno">4. </span>Security and privacy considerations</span></h2><p><em>This section is non-normative.</em></p>
       <p>
         The API defined in this specification is used to determine the battery
-        status of the hosting device. The information disclosed has minimal
-        impact on privacy or fingerprinting, and therefore is exposed without
-        permission grants. For example, the user agent can obfuscate the
-        exposed value in a way that authors cannot directly know if a hosting
-        device has no battery, is charging or is exposing fake values.
+        status of the hosting device.
+      </p>
+      <p>
+        The user agent <em class="rfc2119" title="SHOULD">SHOULD</em> not expose high precision readouts of battery
+        status information as that can introduce a new fingerprinting vector.
+      </p>
+      <p>
+        The user agent <em class="rfc2119" title="MAY">MAY</em> ask the user for battery status information access, or
+        alternatively, enforce the user permission requirement in its private
+        browsing modes.
+      </p>
+      <p>
+        The user agent <em class="rfc2119" title="SHOULD">SHOULD</em> inform the user of the API use by scripts in an
+        unobtrusive manner to aid transparency and to allow the user to revoke
+        the API access.
+      </p>
+      <p>
+        The user agent <em class="rfc2119" title="MAY">MAY</em> obfuscate the exposed value in a way that authors
+        cannot directly know if a hosting device has no battery, is charging or
+        is exposing fake values.
       </p>
     </section>
     <section id="the-navigator-interface" typeof="bibo:Chapter" resource="#the-navigator-interface" property="bibo:hasPart">
@@ -1043,7 +1058,8 @@
         specification. Special thanks to all the participants of the Device
         APIs Working Group and others who have sent in substantial feedback
         and comments, and made the Web a better place for everyone by
-        doing so.
+        doing so. Finally, thanks to Lukasz Olejnik, Gunes Acar, Claude
+        Castelluccia, and Claudia Diaz for the privacy analysis of the API.
       </p>
     </section>
   
diff -r 16d476e0af31 -r abe11905e4dc battery/Overview.src.html
--- a/battery/Overview.src.html	Thu Aug 20 15:21:34 2015 +0300
+++ b/battery/Overview.src.html	Thu Aug 20 15:50:38 2015 +0300
@@ -130,11 +130,26 @@
       <h2>Security and privacy considerations</h2>
       <p>
         The API defined in this specification is used to determine the battery
-        status of the hosting device. The information disclosed has minimal
-        impact on privacy or fingerprinting, and therefore is exposed without
-        permission grants. For example, the user agent can obfuscate the
-        exposed value in a way that authors cannot directly know if a hosting
-        device has no battery, is charging or is exposing fake values.
+        status of the hosting device.
+      </p>
+      <p>
+        The user agent SHOULD not expose high precision readouts of battery
+        status information as that can introduce a new fingerprinting vector.
+      </p>
+      <p>
+        The user agent MAY ask the user for battery status information access, or
+        alternatively, enforce the user permission requirement in its private
+        browsing modes.
+      </p>
+      <p>
+        The user agent SHOULD inform the user of the API use by scripts in an
+        unobtrusive manner to aid transparency and to allow the user to revoke
+        the API access.
+      </p>
+      <p>
+        The user agent MAY obfuscate the exposed value in a way that authors
+        cannot directly know if a hosting device has no battery, is charging or
+        is exposing fake values.
       </p>
     </section>
     <section>
@@ -475,7 +490,8 @@
         specification. Special thanks to all the participants of the Device
         APIs Working Group and others who have sent in substantial feedback
         and comments, and made the Web a better place for everyone by
-        doing so.
+        doing so. Finally, thanks to Lukasz Olejnik, Gunes Acar, Claude
+        Castelluccia, and Claudia Diaz for the privacy analysis of the API.
       </p>
     </section>
   </body>

Received on Thursday, 20 August 2015 12:51:30 UTC