Improve the privacy section.

w3c · Mar 13, 2024 · b61f70e · b61f70e
1 parent e637808
commit b61f70e
Showing 1 changed file with 47 additions and 32 deletions.
diff --git a/index.html b/index.html
@@ -96,7 +96,7 @@
       }
     </style>
   </head>
-  <body data-cite="FEATURE-POLICY PERMISSIONS CSSOM-VIEW SCREEN-ORIENTATION">
+  <body data-cite="FEATURE-POLICY PERMISSIONS CSSOM-VIEW MEDIAQUERIES SCREEN-ORIENTATION">
     <section id='abstract'>
       <p>
         This document specifies an API that allows web applications to request
@@ -381,7 +381,9 @@ <h3>
         instance, a device might not yield exactly 180° when laying flat, but
         instead values ranging from 175° to 185°. Device makers SHOULD make
         sure that the physical device postures map correctly to the postures
-        defined by this specification.
+        defined by this specification. Device makers are also allowed to determine
+        the posture using more sensors than just the hinge angle for example
+        if the keyboard is docked or not.
       </p>
       <p>
         Some devices might also lack one or more of the postures due to
@@ -524,54 +526,67 @@ <h2>
     </section>
     <section>
       <h2>
-        Security and Privacy considerations
+        Security Considerations
       </h2>
       <p>
-        The Device Posture API exposes a <a>posture</a> determined from the
-        hinge angle value and other sensors.
+        No new security considerations have been reported on this specification.
       </p>
+  </section>
+    <section>
+      <h2>
+        Privacy considerations
+      </h2>
       <p>
-        Typical sensor readings are sent at a constant frequency to whomever is
-        listening to its readings. However the fold angle only communicates its
-        value when the hinge is manipulated by the user. Variations in the
-        angle’s readings and posture calculation, as well as event dispatching
-        frequency offer a possibility of fingerprinting to identify users. User
-        agents may reduce this risk by limiting or coalescing events when
-        exposing this information to web developers. Users don’t constantly
-        adjust the angle, so the fold angle value is changing in bursts: the
-        events may be dispatched at a very low frequency most of the time and
-        fire at a high frequency when the device is being opened or closed. In
-        order for the events to be dispatched, the content must be on the
-        foreground and visible to the user. Because the API does not directly
-        expose the raw angle values, but a more abstract posture with fewer
-        possible states, fingerprinting possibilities are more limited.
+        The Device Posture API exposes a <a>posture</a> determined from the hinge
+        angle sensor, but additional data can be used to determine the posture
+        such as whether the keyboard is attached or not, whether the
+        kickstand is deployed or not, etc.
       </p>
       <p>
-        If the same code using the API can be used simultaneously in different
-        window contexts on the same device it may be possible for that code to
-        correlate the user across those two contexts, creating unanticipated
-        tracking mechanisms.
+        Device Posture exposes high level concept and not sensor values
+        making fingerprinting possibilities more limited. Changing
+        posture is a physical manipulation done by the user. The frequency of
+        the posture changes are low, users don’t constantly adjust the angle,
+        and even if they do the <a>posture</a> will only be changed in certain
+        scenarios as described in [=posture values table=].
       </p>
       <section>
         <h3>
-          Types of security and privacy threats
+          Types of privacy threats
         </h3>
         <p>
           <i>This section is non-normative.</i>
         </p>
+        <h4 id="identifying-users-across-contexts">
+          Identifying users across contexts
+        </h4>
+        <p>
+          If the same code using this API can be used simultaneously in different
+          window contexts on the same device it may be possible for that code to
+          correlate the user across those two contexts, creating unanticipated
+          tracking mechanisms. However because the posture value is typically
+          stable for a long time it could only be used to identify if two users
+          are not the same but it would not help to identify a given user given
+          the fact that there are multiple types and models of foldable devices.
+        </p>
+        <p>
+          This API's entropy is comparable to the
+          <a data-xref-type="css-descriptor" data-xref-for="@media">pointer</a>
+          API which is telling whether the user primary input is touch or not.
+        </p>
+
+        <h4>
+         iframes
+        </h4>
+        <p>
+          iframes have access to the posture through this API and therefore could use
+          this information to identify users as mentioned in [[[#identifying-users-across-contexts]]].
+        </p>
       </section>
       <section>
         <h3>
           Mitigation Strategies
         </h3>
-        <p>
-          <i>This section is non-normative.</i>
-        </p>
-        <p>
-          This section gives a high-level presentation of some of the
-          mitigation strategies specified in the normative sections of this
-          specification.
-        </p>
         <section>
           <h4>
             Secure Context