From 8974b7241491b6b27f78575d16cc4153a6efbe2f Mon Sep 17 00:00:00 2001 From: Anssi Kostiainen Date: Thu, 25 May 2023 14:48:41 +0300 Subject: [PATCH 1/2] Reorganize Security and privacy considerations - Add a section for Types of privacy and security threats - Add a section for Mitigation strategies --- index.html | 101 +++++++++++++++++++++-------------------------------- 1 file changed, 39 insertions(+), 62 deletions(-) diff --git a/index.html b/index.html index da04382..28cf6da 100644 --- a/index.html +++ b/index.html @@ -1,4 +1,3 @@ - Compute Pressure Level 1 @@ -1125,44 +1124,52 @@

Handle unloading document and closing of workers

Security and privacy considerations

-

- Please consult the Security and Privacy Self-Assessment - based upon the [[security-privacy-questionnaire]]. -

+
-

Minimizing information exposure

+

Types of privacy and security threats

+
+ The Working Group will list any known attack vectors, both theoretical and real-world, + in this section. +
+

Timing attacks

- Exposing hardware related events related to low -level details such as exact CPU - utilization or frequency - - increases the risk of harming the user's privacy. + It may be possible to identify users across non-[=same origin=] sites if unique + or very precise values can be accessed at the same time by sites not sharing + origin. + + This attack is mitigated by [[[#data-minimization]]], [[[#rate-limiting-change-notifications]]], + and [[[#same-origin-restriction]]].

+
+ +
+

Mitigation strategies

+ +
+ This section gives a high-level view into mitigation strategies applicable to this specification. + The normative definitions of these mitigations are integrated into the respective algorithms of this specification. +
+ +

Data minimization

- To mitigate this risk, no such low level details are exposed. + This specification adheres to the generic + data minimization principles + to limit exposure of data related to low-level details of the underlying platform to the minimum required to + address its high-value use cases. This includes consideration for limiting exposure of + identifying information about devices.

- The subsections below describe the processing model. At a high level, the - information exposed is reduced by the following steps: -

    -
  1. - Rate-limiting - The user agent notifies the application of changes in - the information it can learn. Change notifications are rate-limited. -
    2. -
  2. - Same-origin context - The feature is only available in same-origin contexts by default, - but can be extended to third-party contexts such as iframes via a permission policy. -
    3. -
+ The specific application of data minimization principles in the context of this specification + are discussed in [[[#rate-limiting-change-notifications]]] and [[[#same-origin-restriction]]].

Rate-limiting change notifications

- We propose exposing the pressure state via - rate-limited change notifications. This aims to remove the ability to observe - the precise time when a value transitions between two states. + By rate-limited the delivery of the pressure state information we remove the + attacker's ability to observe the precise time when a value transitions between two states.

More precisely, once the pressure observer is activated, it will be - called once with initial values, and then be called when the values change. + called once with initial values, and then is called when the values change. The subsequent calls will be rate-limited. When the callback is called, the most recent value is reported.

@@ -1185,41 +1192,7 @@

Rate-limiting change notifications

-

No side-channels

-

- It is possible to identify users across non-[=same origin=] sites if unique - or very precise values can be accessed at the same time by sites not sharing - origin. -

-

- If the same [=pressure state=] and timestamp is observed by two origins, that - would be a good indication that the origin is used by the same user on the - same machine. For this reason, the API limits reporting [=pressure - state=] changes to one origin at the time. -

-

- A common way to do this, is only to report changes to the focused page, but - one of the main users of this API are video conferencing sites. These sites - want to make sure that the video streams and effects doesn't negatively affect - the system and thus the conferencing experience - but there are two common - cases where the site will usually not be focused: -

    -
  • - The user is taking meeting notes and the site is in the background. Commonly - the video stream is only visible via a picture-in-picture window. -
    • -
  • - The user is sharing an external application window such as a presentation, - or sharing the whole screen, unusually with some UI indicating sharing is - happening. -
    • -
- For this reason, the API considers these two cases to have - higher priority than whether the site is focused. -

-
-
-

Same-origin contexts

+

Same-origin restriction

By default data delivery is restricted to documents served from the same-origin as an @@ -1230,6 +1203,10 @@

Same-origin contexts

The documents qualifying for data delivery, under the above rules, can delegate it to documents in [=child navigables=].

+

+ The feature can be extended to third-party contexts such as iframes only by a + declared policy. +

From 65ecb0a1aaea1bd47e29164419722d89de642258 Mon Sep 17 00:00:00 2001 From: Anssi Kostiainen Date: Mon, 5 Jun 2023 12:20:39 +0300 Subject: [PATCH 2/2] Tweak wording --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 28cf6da..fc57451 100644 --- a/index.html +++ b/index.html @@ -1164,7 +1164,7 @@

Data minimization

Rate-limiting change notifications

- By rate-limited the delivery of the pressure state information we remove the + By rate-limiting the delivery of the pressure state information we remove the attacker's ability to observe the precise time when a value transitions between two states.