Device access permissions and fingerprinting (fixes #479)

* Device access permissions and fingerprinting

This rewords some of the text from #470 to address a latent concern.

It also switches from "id" to "identifier".

Closes #479.

* Broaden the device section to include capabilities

Consider LLM access in much the same way.

Closes #526.

* to

* Update index.bs

Co-authored-by: Jeffrey Yasskin <[email protected]>

---------

Co-authored-by: Daniel Appelquist <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>

Author: 3 people

index.bs

@@ -2570,7 +2570,7 @@ Represent errors in web APIs as ECMAScript error objects (e.g., {{Error}})
 or as {{DOMException}}.
 whether they are exceptions, promise rejection values, or properties.
 
-<h2 id="device-apis">OS and Device Wrapper APIs</h2>
+<h2 id="device-apis">APIs that wrap access to device or browser capabilities</h2>
 
 New APIs are now being developed in the web platform for interacting with devices.
 For example, authors wish to be able to use the web to connect with their
@@ -2581,22 +2581,28 @@ accelerometer),
 <a href="https://wicg.github.io/webusb/">USB</a>-connected peripherals,
 <a href="https://www.w3.org/community/autowebplatform/">automobiles</a>, etc.
 
-These can be functionality provided by the underlying operating system,
-or provided by a native third-party library
-to interact with a device.
-These are an abstraction which "wrap" the native functionality
+The same applies to capabilities that might be optionally provided
+by either the host system or an external service.
+This includes capabilities that depend on users paying for access to the capability.
+
+These capabilities can be functionality provided by the underlying operating system,
+or provided by a native third-party library.
+APIs can provide an abstraction which "wraps" the native functionality
 without introducing significant complexity,
 while securing the API surface to the browser.
 So, these are called wrapper APIs.
 
-This section contains principles for consideration when designing APIs for devices.
+This section contains principles for consideration
+when designing APIs for these capabilities.
 
-<h3 id="device-ids">Don't expose unnecessary information about devices</h3>
+<h3 id="device-ids">Don't expose unnecessary information about capabilities</h3>
 
-In line with the [Data Minimization](#data-minimization) principle, if you need to give web sites access to information about a device, only expose the minimal amount of data necessary.
+In line with the [Data Minimization](#data-minimization) principle,
+if you need to give web sites access to information about capabilities,
+only expose the minimal amount of data necessary.
 
 Firstly, think carefully about whether it is really necessary
-to expose identifying information about the device at all.
+to expose information at all.
 Consider whether your [user needs](#priority-of-constituencies) could be satisfied
 by a less powerful API.
 
@@ -2605,8 +2611,11 @@ additional information about a device,
 or device identifiers,
 each increase the risk of harming the user's privacy.
 
-A web app should not be able to distinguish between the user rejecting
-permission to use a sensor/capability, and the sensor/capability not being present.
+When a user makes a choice to deny access to a device or capability,
+that should not reveal whether the capability exists.
+Reducing information leakage in that scenario
+is more important
+than when the capability is granted.
 
 As more specific information is shared,
 the
@@ -2618,44 +2627,44 @@ to user privacy.
 If there is no way to design a less powerful API,
 use these guidelines when exposing device information:
 
-: Limit information in the id
+: Limit information in any identifier
 :: Include as little identifiable information as possible
-    in device ids exposed to the web plaform.
+    in device identifiers exposed to the web plaform.
     Identifiable information includes
     branding, make and model numbers, etc
-    You can usually use a random number
-    or a unique id instead.
-    Make sure that your ids aren't guessable,
+    You can usually use a randomly generated identifier instead.
+    Make sure that your identifiers aren't guessable,
     and aren't re-used.
 : Keep the user in control
 :: When the user chooses to clear browsing data,
-    make sure any stored device ids are cleared.
-: Hide sensitive ids behind a user permission
-:: If you can't create a device id in an anonymous way,
+    make sure any stored device identifiers are cleared.
+: Hide sensitive information behind a user permission
+:: If you can't create a device identifier in an anonymous way,
     limit access to it.
     Make sure the user can provide
     [[#consent|meaningful consent]]
     to a Web page accessing this information.
-: Tie ids to the same-origin model
-:: Create distinct unique ids for the same physical device
+: Tie identifiers to the same-origin model
+:: Create distinct identifiers for the same physical device
     for each origin that has has access to it.
 :: If the same device is requested more than once
-    by the same origin, return the same id for it
+    by the same origin, return the same identifier for it
     (unless the user has cleared their browsing data).
     This allows authors to avoid having
     several copies of the same device.
 : Persistable when necessary
-:: If a device id is time consuming to obtain,
-    make sure authors can store an id generated in one session
+:: If a device identifier is time consuming to obtain,
+    make sure authors can store an identifier generated in one session
     for use in a later session.
     You can do this by making sure that
-    the procedure to generate the id
-    consistently produces the same id
+    the procedure to generate the identifier
+    consistently produces the same value
     for the same device,
     for each origin.
 
 See also:
 
+* [[#consent]]
 * [[LEAST-POWER]]
 * [[FINGERPRINTING-GUIDANCE]]
 * [[UNSANCTIONED-TRACKING]]
@@ -2729,7 +2738,7 @@ Note: While APIs should not
 expose a full list of devices in an [=implementation-defined=] order,
 they may need to for web compatibility reasons.
 
-<h3 id="usecase-oriented-apis">Design based on user needs, not the underlying API or hardware</h3>
+<h3 id="usecase-oriented-apis">Design based on user needs, not the underlying capability</h3>
 
 Expose new native capabilities being brought to the web based on user needs.