From 421254b41aab7a3ede528322b818890bbb5924d9 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 5 Dec 2024 01:02:33 +1100 Subject: [PATCH] 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 --------- Co-authored-by: Daniel Appelquist Co-authored-by: Jeffrey Yasskin --- index.bs | 63 ++++++++++++++++++++++++++++++++------------------------ 1 file changed, 36 insertions(+), 27 deletions(-) diff --git a/index.bs b/index.bs index 57a6106f..59a69b0a 100644 --- a/index.bs +++ b/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. -

OS and Device Wrapper APIs

+

APIs that wrap access to device or browser capabilities

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), USB-connected peripherals, automobiles, 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. -

Don't expose unnecessary information about devices

+

Don't expose unnecessary information about capabilities

-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. -

Design based on user needs, not the underlying API or hardware

+

Design based on user needs, not the underlying capability

Expose new native capabilities being brought to the web based on user needs.