Additional security/privacy clarifications following horizontal review (

#252)

* Include further clarifications in security/privacy section

- clarify that inferred characteristics may themselves be sensitive (e.g. indicating a user is using AT)
- include mitigation suggestions for UAs (making extended sensor data opt-in/disableable)

See https://lists.w3.org/Archives/Public/public-pointer-events/2018AprJun/0046.html

* Expand pointerId note to include clarification and security/privacy concern

See https://lists.w3.org/Archives/Public/public-pointer-events/2018AprJun/0046.html

index.html

@@ -282,7 +282,9 @@ <h2><code>PointerEvent</code> Interface</h2>
                         <dd>
                             <p>A unique identifier for the pointer causing the event. This identifier MUST be unique from all other <a data-lt="active pointer">active pointers</a> in the <a href="https://www.w3.org/TR/html5/browsers.html#top-level-browsing-context">top-level browsing context</a> (as defined by [[!HTML5]]) at the time. A user agent MAY recycle previously retired values for <code>pointerId</code> from previous active pointers, if necessary.</p>
 
-                            <div class="note">The <code>pointerId</code> selection algorithm is implementation specific. Therefore authors cannot assume values convey any particular meaning other than an identifier for the pointer that is unique from all other active pointers. As an example, values are not guaranteed to be monotonically increasing.</div>
+                            <div class="note">
+                                <p>The <code>pointerId</code> selection algorithm is implementation specific. Therefore authors cannot assume values convey any particular meaning other than an identifier for the pointer that is unique from all other active pointers. As an example, user agents may simply assign a number, starting from <code>1</code>, to any active pointers, in the order that they become active - but these values are not guaranteed to be monotonically increasing. Other user agents may opt to assign a completely randomized and unique number to each active pointer. However, in the latter scenarios user agents MUST ensure that the <code>pointerId</code> that is assigned remains the same only for the lifetime of the current page, and that any new <code>pointerId</code> values are not predictable (e.g. generated randomly with cryptographically strong randomness), to minimize the possibility of users being uniquely fingerprinted and tracked across different pages.</p>
+                            </div>
                         </dd>
                     <dt><dfn>width</dfn></dt>
                         <dd>
@@ -959,7 +961,8 @@ <h2>Security and privacy considerations</h2>
         <p>This appendix discusses security and privacy considerations for Pointer Events implementations. The discussion is limited to security and privacy issues that arise directly from implementation of the event model, APIs and events defined in this specification.</p>
         <p>Many of the event types defined in this specification are dispatched in response to user actions. This allows malicious event listeners to gain access to information users would typically consider confidential, e.g., the exact path/movement of a user's mouse/stylus/finger while interacting with a page.</p>
         <p>Pointer events contain additional information (where supported by the user's device), such as the angle or tilt at which a pen input is held, the geometry of the contact surface, and the pressure exerted on the stylus or touch screen. Information about angle, tilt, geometry and pressure are directly related to sensors on the user's device, meaning that this specification allows an origin access to these sensors.</p>
-        <p>This sensor data, as well as the ability to determine the type of input mechanism (mouse, touch, pen) used, may be used to infer characteristics of a user, or of the user's device and environment. This information can also be potentially used for the purposes of building a user profile and/or attempting to "fingerprint" and track a particular user.</p>
+        <p>This sensor data, as well as the ability to determine the type of input mechanism (mouse, touch, pen) used, may be used to infer characteristics of a user, or of the user's device and environment. These inferred characteristics and any device/environment information may themselves be sensitive - for instance, they may allow a malicious site to further infer if a user is using assistive technologies. This information can also be potentially used for the purposes of building a user profile and/or attempting to "fingerprint" and track a particular user.</p>
+        <p>As mitigation, user agents may consider including the ability for users to disable access to particular sensor data (such as angle, tilt, pressure), and/or to make it available only after an explicit opt-in from the user.</p>
         <p>Beyond these considerations, the working group believes that this specification:</p>
         <ul>
             <li>Does not expose personally-identifiable information.</li>