From bf31b6b79b8b776003894f4eb7d79d2ad8436ae8 Mon Sep 17 00:00:00 2001 From: Anssi Kostiainen Date: Mon, 27 May 2024 17:23:52 +0300 Subject: [PATCH 1/2] Update Privacy considerations - Reorganize mitigation strategies for readability - Give additional mitigation strategies names - Map theoretical attack with mitigations - Remove Secure Context from this section ([SecureContext] in IDL is adequate nowadays) --- index.html | 116 +++++++++++++++++++++++++++++++++++------------------ 1 file changed, 76 insertions(+), 40 deletions(-) diff --git a/index.html b/index.html index a9e5a27..b907a00 100644 --- a/index.html +++ b/index.html @@ -574,7 +574,7 @@

- Security Considerations + Security considerations

No new security considerations have been reported on this @@ -585,20 +585,6 @@

Privacy considerations

-

- The Device Posture API exposes a posture 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. -

-

- 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 do not constantly adjust the angle, and even if - they do the posture will only be changed in certain scenarios as - described in [=posture values table=]. -

Types of privacy threats @@ -610,51 +596,73 @@

Identifying users across contexts

- If 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 verify that 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. + When this API is used simultaneously in different browsing contexts + on the same device it may be possible 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 verify that 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.

- This API's entropy is comparable to the pointer API which tells - whether the user's primary input is touch-based or not. However, the + whether the user's primary input is touch-based or not. Such a primary input can change on devices where the keyboard can be removed/added or the tablet mode is activated/deactivated.

+

+ This theoretical attack is mitigated by [[[#data-minimization]]], + [[[#user-attention]]], [[[#user-mediated-action]]] and + [[[#rate-limiting-change-notifications]]]. +

- iframes + Cross-origin iframes

- 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]]]. + Cross-origin iframes have access to the posture through this API and + therefore could use this information to identify users similarly to + as mentioned in [[[#identifying-users-across-contexts]]]. The same + mitigations apply.

- Mitigation Strategies + Mitigation strategies

-

- Secure Context +

+ Data minimization

- Posture value readings are explicitly flagged by the Secure - Contexts specification as a high-value target for network - attackers. {{DevicePosture}} has the {{SecureContext}} extended - attribute in its declaration, and so does the addition to the - {{Navigator}} interface - ([[[#extensions-to-the-navigator-interface]]]). + The API exposes a high-level abstraction referred to as a + posture that can be either + "{{DevicePostureType/continuous}}" or + "{{DevicePostureType/folded}}". Devices that do not support + different postures default to "{{DevicePostureType/continuous}}". + This means at most one bit of entropy is added to the fingerprint. + At most, because revealing this one bit will require a significant, + explicit physical action by the user to manipulate the physical + posture of the device required to trigger a change. +

+

+ While implementations can use a variety of low-level information to + determine the most appropriate high-level posture, no low-level + details are exposed through this API. Furthermore, there is no + one-to-one mapping from any fine-grained low-level sensor reading + to a high-level posture state. An implementation can use e.g. a + hinge angle sensor, other sensors, information about whether a + keyboard is docked, or whether the kickstand is deployed, or any + combination of such information, to determine the most approriate + posture for the given form factor. This abstraction ensures only a + minimum amount of information necessary to implement the intended + functionality is exposed adhering to the data minimization + principles.

-

- Visibility State +

+ User attention

Posture value change events are only fired for each @@ -665,6 +673,34 @@

"visible" or just changed to "visible".

+
+

+ User-mediated action +

+

+ A user's significant and explicit physical action to modify the + device posture is required for a posture change. Significant, + because the action must cross the implementation-defined threshold + per [=posture values table=], and explicit, because the underlying + operating system adapts to posture changes similarly matching + user's learned expectations for an outcome of such an action. +

+
+
+

+ Rate-limiting change notifications +

+

+ The API is designed to minimize the rate at which posture state + changes are reported. A change is only reported throught this API + when an implementation-defined threshold is crossed per [=posture + values table=]. Given the small number of states and a wide range + of angles that correlate with the default + "{{DevicePostureType/continuous}}" state, the rate of notifications + is limited. We playfully call this mitigation a physical + human-computer interface rate limiter. +

+
From 9548e1e3b6deb3047a32444c282c14da7eea8f16 Mon Sep 17 00:00:00 2001 From: Anssi Kostiainen Date: Tue, 28 May 2024 12:18:40 +0300 Subject: [PATCH 2/2] Add issue link for iframe exposure --- index.html | 1 + 1 file changed, 1 insertion(+) diff --git a/index.html b/index.html index b907a00..8708c6f 100644 --- a/index.html +++ b/index.html @@ -625,6 +625,7 @@

as mentioned in [[[#identifying-users-across-contexts]]]. The same mitigations apply.

+