Compute Pressure Level 1

This section is non-normative.

Feature detection is an established web development best practice. Resources on the topic are plentiful on- and offline and the purpose of this section is not to discuss it further, but rather to put it in the context of detecting hardware-dependent features.

Consider the below feature detection examples:

Example 1: Checking existence of PressureObserver interface

This simple example illustrates how to check whether the User Agent exposes the PressureObserver interface

if ("PressureObserver" in globalThis) {
  // Use PressureObserver interface
}

Note

This specification defines the following concepts:

Computing devices consist of a multitude of different processing units such as the Central Processing Unit (CPU), the Graphics Processing Unit (GPU) and many specialized processing units. The latter are becoming popular such as ones designed to accelerate specific tasks like machine learning or computer vision.

The specification currently defines the supported source types as global system thermals and the central processing unit, also know as the CPU. Future levels of this specification MAY introduce additional source types.

WebIDLenum PressureSource { "thermals", "cpu" };

The PressureSource enum represents the supported source types:

"thermals" represents the global thermal state of the system.
"cpu" represents the average pressure of the central processing unit across all its cores.

Note

The requested sampling interval represents the desired interval between samples to be obtained from the hardware, expressed in milliseconds.

Interval and frequency are inverses of each other, so the requested sampling interval can also be expressed as a requested sampling rate in Hertz (cycles per second) by dividing 1000 by the requested sampling interval value.

The sampling rate for a platform collector is defined as a rate at which the user agent obtains telemetry readings from the underlying platform, and it might differ from the pressure observers' requested sampling rates. The rate is measured in Hertz (cycles per second).

The reporting rate for a pressure observer is the rate at which it runs the data delivery steps, and it will never exceed the sampling rate.

The sampling rate differs from the requested sampling rate when the requested sampling rate exceeds upper or lower sampling rate bounds supported or accepted by the underlying platform and user agent^†.

^†It is recommended that the user agent limits the reporting rate as outlined in 11.2.2 Rate-limiting change notifications.

In case the user didn't request a sampling rate, the sampling rate is implementation-defined.

Note

The platform collector refers to a platform interface, with which the user agent interacts to obtain the telemetry readings required by this specification.

A platform collector can be defined by the underlying platform (e.g. in a native telemetry framework) or by the user agent, if it has a direct access to hardware counters.

A platform collector can support telemetry for different source types of computing devices defined by PressureSource, or there can be multiple platform collectors.

From the implementation perspective platform collector can be treated as a software proxy for the corresponding hardware counters. It is possible to have multiple platform collector simultaneously interacting with the same underlying hardware if the underlying platform supports it.

In simple cases, a platform collector represents individual hardware counters, but if the provided counter readings are a product of data fusion performed in software, the platform collector represents the results of the data fusion process. This may happen in user space or in kernel space.

As collecting telemetry data often means polling hardware counters, it is not a free operation and thus, it should not happen if there are no one observing the data. See 10.5 Life-cycle and garbage collection for more information.

A platform collector samples data at a specific rate. A user agent may modify this rate (if possible) for privacy reasons, or ignore and fuse certain readings.

It is RECOMMENDED that a user agent show some form of user-visible notification that informs the user when a pressure observer is active, as well as provides the user with the means to block the ongoing operation, or simply dismiss the notification.

The Compute Pressure API defines a policy-controlled feature identified by the token "compute-pressure". Its default allowlist is 'self'.

Workers (dedicated and shared) adhere to the permission policy set by their owning document(s).

Shared workers often have multiple owning documents as they can be obtained by other documents with the same origin. In this case, all owning documents must be allowed to use the policy-controlled feature defined by this specification.

Dedicated workers can be created from other workers, in which case the permission policy of the first owning document (or owning documents, in case of a shared worker) up the owner chain will be used.

Note

The default allowlist of 'self' allows usage in same-origin nested frames but prevents third-party content from using the feature.

Third-party usage can be selectively enabled by adding allow="compute-pressure" attribute to the frame container element:

Example: Enabling compute pressure on remote content

<iframe src="https://third-party.com" allow="compute-pressure"/></iframe>

Alternatively, the Compute Pressure API can be disabled completely by specifying the permissions policy in a HTTP response header:

Example: Feature Policy over HTTP

Permissions-Policy: {"compute-pressure": []}

See Permissions Policy for more details.

Each global object has:

a current pressure state (a string), initialized to the empty string.
a pressure observer task queued (a boolean), which is initially false.
a registered observer list per supported source type, which is initially empty.
a reference to an underlying platform collector as detailed in 4. Platform primitives.

A registered observer consists of an observer (a PressureObserver object).

The user agent additionally has a max queued records integer, which is set to an implementation-defined value, greater than 0.

A constructed PressureObserver object has the following internal slots:

a [[Callback]] of type PressureUpdateCallback set on creation.
a [[PendingObservePromises]] list of zero or more source-promise tuples, initially empty, where source holds a PressureSource string and promise holds a Promise object.
a [[QueuedRecords]] queue of zero or more PressureRecord objects, which is initially empty.
a [[LastRecordMap]] ordered map of PressureSource to the latest PressureRecord.
a [[SampleIntervalMap]] ordered map of PressureSource to positive numbers. It represents the sample interval given source type.

For the rate obfuscation mitigation the constructed PressureObserver object additionally has the following internal slots:

an [[ObservationWindow]] integer set as part of the reset observation window steps.
a [[MaxChangesThreshold]] integer set as part of the reset observation window steps.
a [[PenaltyDuration]] integer set as part of the reset observation window steps.
a [[ChangesCountMap]] ordered map, keyed on a PressureSource, representing the source type that triggered transition to the current pressure state. The ordered map's value is an integer representing the number of state changes in the current observation window timeframe.
a [[AfterPenaltyRecordMap]] ordered map, keyed on a PressureSource, representing the source type of the last PressureRecord. The ordered map's value is a PressureRecord.

Pressure states represents the minimal set of useful states that allows websites to react to changes in compute and system pressure with minimal degration in quality or service, or user experience.

WebIDLenum PressureState { "nominal", "fair", "serious", "critical" };

The PressureState enum represents the pressure state with the following states:

"nominal": The conditions of the target device are at an acceptable level with no noticeable adverse effects on the user.
"fair": Target device pressure, temperature and/or energy usage are slightly elevated, potentially resulting in reduced battery-life, as well as fans (or systems with fans) becoming active and audible. Apart from that the target device is running flawlessly and can take on additional work.
"serious": Target device pressure, temperature and/or energy usage is consistently highly elevated. The system may be throttling as a countermeasure to reduce thermals.
"critical": The temperature of the target device or system is significantly elevated and it requires cooling down to avoid any potential issues.

Contributing factors represent the underlying hardware metrics contributing to the current pressure state and can be implementation-defined.

The adjusted pressure state is a pressure state determined by an implementation-defined algorithm that takes as input source type and any other implementation-defined data from contributing factors. This algorithm MUST not be deterministic to ensure break calibration mitigation effectiveness.

The change in contributing factors is substantial steps are as follows:

If implementation-defined low-level hardware metrics that contribute to the current pressure state drop below or exceed an, per metric, implementation-defined threshold for the current pressure state, return true.
Return false.

Note

The change in contributing factors is substantial algorithm allows user agents to avoid flip- flopping between states in certain circumstances. For example, a state might otherwise change too rapidly in response to a certain system metric that fluctuates around a boundary condition that triggers a state change.

This specification does not define the precise algorithm to allow implementations optimize this algorithm to match the underlying hardware platform's behavior. One possible implementation of this algorithm is to use a nonideal relay as a model and identify appropriate lower threshold α and upper threshold β for each pressure state taking special characteristics of each contributing factors into consideration.

The Compute Pressure API enables developers to understand the pressure of system resources such as the CPU.

WebIDLcallback PressureUpdateCallback = undefined (
  sequence<PressureRecord> changes,
  PressureObserver observer
);

This callback will be invoked when the pressure state changes.

The PressureObserver can be used to observe changes in the pressure states.

WebIDL[Exposed=(DedicatedWorker,SharedWorker,Window), SecureContext]
interface PressureObserver {
  constructor(PressureUpdateCallback callback);

  Promise<undefined> observe(PressureSource source, optional PressureObserverOptions options = {});
  undefined unobserve(PressureSource source);
  undefined disconnect();
  sequence<PressureRecord> takeRecords();

  [SameObject] static readonly attribute FrozenArray<PressureSource> supportedSources;
};

The PressureObserver interface represents a PressureObserver.

The new PressureObserver(callback) constructor steps are:

Set this.[[Callback]] to callback.

The observe(source, options) method steps are:

Let relevantGlobal be this's relevant global object.
For each document in relevantGlobal's owning document set:
1. If document is not allowed to use the policy-controlled feature token "compute-pressure", return a promise rejected with NotAllowedError.
Issue 1
Permission policy does not support workers directly yet #110, so they cannot be set per individual worker, so for now we consult the policy for all owning documents. For shared workers this means that all owning documents have to have the policy enabled, which should be easy to coordinate as shared workers require same origin.
Set this.[[SampleIntervalMap]][source] to options's sampleInterval.
Let promise be a new promise.
Let pendingPromiseTuple be (source, promise).
Append pendingPromiseTuple to this.[[PendingObservePromises]].
React to promise:
- If promise was fulfilled or rejected, then:
  1. Remove tuple from this.[[PendingObservePromises]].
Run the following steps in parallel:
1. If source is not a supported source type, queue a global task on the PressureObserver task source given relevantGlobal to reject promise NotSupportedError and abort these steps.
2. Activate data delivery of source data to relevantGlobal.
3. Queue a global task on the PressureObserver task source given relevantGlobal to run these steps:
  1. If promise was rejected, run the following substeps:
    1. If relevantGlobal's registered observer list for source is empty, deactivate data delivery of source data to relevantGlobal.
    2. Return.
  2. Append a new registered observer whose observer is this to relevantGlobal's registered observer list for source.
  3. Resolve promise.
Return promise.

The unobserve(source) method steps are:

If source is not a supported source type, throw "NotSupportedError".
Remove from this.[[QueuedRecords]] all records associated with source.
Remove this.[[SampleIntervalMap]][source].
Remove this.[[LastRecordMap]][source].
Remove this.[[AfterPenaltyRecordMap]][source].
For each (promiseSource, pendingPromise) of this.[[PendingObservePromises]], if source is equal to promiseSource, reject pendingPromise with an AbortError.
Let relevantGlobal be this's relevant global object.
Remove any registered observer from relevantGlobal's registered observer list for source for which this is the registered observer.
If the above registered observer list is empty, deactivate data delivery of source data to relevantGlobal.

The disconnect() method steps are:

Empty observer.[[QueuedRecords]].
Clear this.[[SampleIntervalMap]].
Clear this.[[LastRecordMap]].
Clear this.[[AfterPenaltyRecordMap]].
For each (promiseSource, pendingPromise) of this.[[PendingObservePromises]], reject pendingPromise with an AbortError.
Let relevantGlobal be this's relevant global object.
Remove any registered observer from relevantGlobal's' registered observer list for all supported source types for which this is the observer.
If the above registered observer list is empty, deactivate data delivery of source data to relevantGlobal.

Note

The takeRecords() method steps are:

Let records be a clone of observer.[[QueuedRecords]].
Empty observer.[[QueuedRecords]].
Return records.

The supportedSources attribute is informing on the supported source type by the platform collector.

The supportedSources getter steps are:

Let sources be a list of source.
Return observer's frozen array of supported source types.

Note

WebIDL[Exposed=(DedicatedWorker,SharedWorker,Window), SecureContext]
interface PressureRecord {
  readonly attribute PressureSource source;
  readonly attribute PressureState state;
  readonly attribute DOMHighResTimeStamp time;
  [Default] object toJSON();
};

A constructed PressureRecord object has the following internal slots:

a [[Source]] value of type PressureSource, which represents the current source type.
a [[State]] value of type PressureState, which represents the current pressure state.
a [[Time]] value of type DOMHighResTimeStamp, which corresponds to the time the data was obtained from the system, relative to the time origin of the global object associated with the PressureObserver instance that generated the notification.

The source getter steps are to return its [[Source]] internal slot.

The state getter steps are to return its [[State]] internal slot.

The time getter steps are to return its [[Time]] internal slot.

When PressureRecord.toJSON is called, run Web IDL Standard's default toJSON steps.

WebIDLdictionary PressureObserverOptions {
  [EnforceRange] unsigned long sampleInterval = 0;
};

The sampleInterval member represents the requested sampling interval expressed in milliseconds.

Note

Each global object has a strong reference to registered observers in their registered observer list (one per source).

Note

This section outlines the steps the user agent must take when implementing the specification.

The reset observation window steps given the argument observer, are as follows:

set observer.[[ObservationWindow]] to an implementation-defined randomized integer value in milliseconds within an implementation-defined range.
set observer.[[MaxChangesThreshold]] to an implementation-defined randomized integer value of maximum allowed changes within the observationWindow within an implementation-defined range.
set observer.[[PenaltyDuration]] to an implementation-defined randomized integer value in milliseconds, within an implementation-defined range.
Empty the observer.[[ChangesCountMap]] map.

Run the reset observation window steps and start a timer to re-run the steps when the observer.[[ObservationWindow]] time has passed, using different randomized values.

Note

To determine the owning document set for a relevant global object relevantGlobal:

Let owningDocumentSet be an empty set.
If relevantGlobal is Window, then append relevantGlobal's associated document to owningDocumentSet.
Otherwise, for each owner in WorkerGlobalScope relevantGlobal's owner set:
1. If owner is a Document, then append owner to owningDocumentSet.
2. If owner is a WorkerGlobalScope, set owningDocumentSet to the union of owningDocumentSet and owner's owning document set.
Return owningDocumentSet.

The document has implicit focus steps given the argument document, are as follows:

If document is not fully active, return false.
Let relevantGlobal be document's relevant global object.
For each origin in initiators of active Picture-in-Picture sessions:
1. If relevantGlobal's relevant settings object's origin is same origin with origin, return true.
If relevantGlobal's browsing context is capturing, return true.
Let topLevelBC be relevantGlobal's browsing context's top-level browsing context.
If topLevelBC does not have system focus, return false.
Let focusedDocument be the topLevelBC's currently focused area's node document.
If relevantGlobal's relevant settings object's origin is same origin with focusedDocument's origin, return true.
Otherwise, return false.

The may receive data steps given the argument observer are as follows:

Let relevantGlobal be observer's relevant global object.
If relevantGlobal is a Window object:
1. Return the result of running document has implicit focus with relevantGlobal's associated Document.
If relevantGlobal is a WorkerGlobalScope object:
1. Let owningDocuments be relevantGlobal's owning document set.
2. For each document in owningDocuments:
  1. If the result of running document has implicit focus with document is true, return true.
  2. Otherwise, continue.
Return false.

Note

The passes rate test steps given the argument observer, source and timestamp, are as follows:

If observer.[[LastRecordMap]][source] does not exist, return true.
Let record be observer.[[LastRecordMap]][source].
Let sampleInterval be observer.[[SampleIntervalMap]][source].
Let timeDeltaMilliseconds = timestamp - record.[[Time]].
If timeDeltaMilliseconds ≥ sampleInterval, return true, otherwise return false.

The has change in data steps given the argument observer, source, state, are as follows:

If observer.[[LastRecordMap]][source] does not exist, return true.
Let record be observer.[[LastRecordMap]][source].
If record.[[State]] is not equal to state and change in contributing factors is substantial returns true, return true.
Return false.

The passes rate obfuscation test steps given the argument observer, source, are as follows:

Increment observer.[[ChangesCountMap]][source].
Return observer.[[ChangesCountMap]][source] ≤ observer.[[MaxChangesThreshold]].

Data delivery from a platform collector can be activate and deactivated in an implementation-defined manner per source type and global object.

Note

The data delivery steps that are run when an implementation-defined data sample of source type source is obtained from global object relevantGlobal's platform collector, are as follows:

Let source be the source type of the data sample.
Let state be an adjusted pressure state given data and source.
Let timestamp be a timestamp representing the time the data was obtained from the relevantGlobal's platform collector.
Note
The data sample and mapping between data sample, and pressure states, is implementation-defined and may use many different metrics. For instance, for CPU, it might consider processor frequency and utilization, as well as thermal conditions.
For each observer in relevantGlobal's registered observer list for source:
1. If running may receive data with observer returns false, continue.
2. If running passes rate test with observer, source and timestamp returns false, continue.
3. If running has change in data with observer, source and state returns false, continue.
4. Let record be a new PressureRecord object with its [[Source]] set to source, [[State]] set to state and [[Time]] set to timestamp.
5. If observer.[[AfterPenaltyRecordMap]][source] exists:
  1. Set observer.[[AfterPenaltyRecordMap]][source] to record.
  2. Continue.
6. If running passes rate obfuscation test with observer and source returns false:
  1. Set observer.[[AfterPenaltyRecordMap]][source] to record.
  2. Set observer.[[ChangesCountMap]][source] to 0.
  3. Create timer of observer.[[PenaltyDuration]] duration with the following callback:
    1. If observer.[[AfterPenaltyRecordMap]][source] exists:
      1. Let record be observer.[[AfterPenaltyRecordMap]][source].
      2. Remove observer.[[AfterPenaltyRecordMap]][source].
      3. Run queue a record with observer, source, record.
  4. Continue.
7. Run queue a record with observer, source, record.

To queue a record given the arguments observer, source, record, run these steps:

If size of observer.[[QueuedRecords]] is greater than max queued records, then remove the first item.
Append record to observer.[[QueuedRecords]].
Set observer.[[LastRecordMap]][source] to record.
Queue a pressure observer task with observer's relevant global object.

The PressureObserver task source is a task source used for scheduling tasks to 10.6.5 Notify Pressure Observers.

To queue a pressure observer task given relevantGlobal as input, run these steps:

If the relevantGlobal's pressure observer task queued is true, then return.
Set the relevantGlobal's pressure observer task queued to true.
Queue a global task on PressureObserver task source with relevantGlobal to notify pressure observers.

To notify pressure observers given relevantGlobal as input, run these steps:

Set relevantGlobal's pressure observer task queued to false.
Let notifySet be a new set of all observers in relevantGlobal’s registered observer lists.
For each observer of notifySet:
1. Let records be a clone of observer.[[QueuedRecords]].
2. Empty observer.[[QueuedRecords]].
3. If records is not empty, then invoke observer.[[Callback]] with records and observer. If this throws an exception, catch it, and report the exception.

When a Document document is no longer fully active, deactivate data delivery of data of all supported source types to document's relevant global object.

When a worker with associated WorkerGlobalScope relevantGlobal is no longer an active needed workers, deactivate data delivery of data of all supported source types to relevantGlobal.

When a Document document becomes fully active, for each non-empty registered observer list associated the source type source, activate data delivery of source data to document's relevant global object.

When a worker with associated WorkerGlobalScope relevantGlobal becomes an active needed workers, for each non-empty registered observer list associated the source type source, activate data delivery of source data to document's relevant global object.

Note

When a worker with associated WorkerGlobalScope relevantGlobal, once relevantGlobal's closing flag is set to true, deactivate data delivery for all supported source types to relevantGlobal.

As one of the unloading document cleanup steps given Document document, deactivate data delivery for all supported source types to document's relevant global object.

Note

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

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 11.2.1 Data minimization, 11.2.2 Rate-limiting change notifications, and 11.2.8 Same-origin restriction.

In computer security a covert channel creates a capability to transfer information between processes that are not supposed to be allowed to communicate. In modern multi-process web engines in the generic case each window or tab resides in its own process (documents that have the same origin or sites that have the same site typically share the same process). Using this API it may be possible to create a cross-site covert channel C where a site A on one tab first broadcasts to the channel C after having manipulated the state of the CPU. Next a site B (that is not same site with site A) on another tab reads the broadcasted data from the channel C by using this API to learn when the state of the CPU has changed. This process is repeated as long as the scripts run on both the sites A and B.

This attack is mitigated by 11.2.2 Rate-limiting change notifications, 11.2.3 Rate obfuscation and 11.2.6 Break calibration. Implementers are advised to consider all these mitigations for long-running scripts.

Note

The longer the scripts run the more information can be transmitted using the proposed cross-site covert channel. For example, if a user is on a video conferencing site and another long-running site that allows for more information to be transferred compared to a regular browsing scenario. On the other hand, a workload such as a video conferencing session will typically exert sustained pressure on the CPU that makes it harder to manipulate the pressure state in a predictive manner.

Targeted de-anonymization attacks constitute a critical class of threats that jeopardize a user's anonymity. These attacks allow a malicious or partially compromised website (referred to as the “malicious site”) to ascertain whether a website visitor possesses a specific public identifier, such as an email address or a social media handle.

While anonymity may be a luxury for some, for certain individuals, it is far more than that—it is a matter of survival. Consider for instance those who engage in political protests, work as journalists covering sensitive topics, etc.

As an example, an attacker can privately share a resource with the target for instance using a public resource sharing service (“victim site”), and then measure side-effects (indicating successful access) on loading the resource via side-channels. If the logged in visitor can access the embedded resource successfully, that indicates that the current visit is indeed the intended target.

Specifically, exposing reliable information about the total CPU pressure can let an attacking site understand if a target of a cross-origin navigation (e.g. an iframe or pop-up window from another site) performed a CPU-intensive operation.

Techniques such as pop-under and tab-under can be used to hide the loading from the user.

One possible attack is that the malicious website opens e.g., a popup to a resource on a victim site to which the user is logged in (e.g. a video streaming site or online document editor) pointing to a resource shared with specific users.

Assuming that loading the resource puts increased pressure on the CPU, this would create a side-channel reveals to the attacking site if the user is logged into an account with access to the resource, deanonymizing the user.

Given that modern CPUs recover quickly from high pressure, one possible mitigation strategy could be to temporarily disable readings for a few seconds after loading popup and iframe content.

Note

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. Implementers are advised to consider the TAG guidance on private browsing modes when implementing the mitigations defined in this specification.

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 specific application of data minimization principles in the context of this specification are discussed in 11.2.2 Rate-limiting change notifications and 11.2.8 Same-origin restriction.

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.

More precisely, once the pressure observer is activated, it will be 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.

The specification will recommend a rate limit of at most one call per second for the active window, and one call per 10 seconds for all other windows. We will also recommend that the call timings are jittered across origins.

These measures benefit the user's privacy, by reducing the risk of identifying a device across multiple origins. The rate-limiting also benefits the user's security, by making it difficult to use this API for timing attacks. Last, rate-limiting change callbacks places an upper bound on the performance overhead of this API.

Rate limiting can be implemented in the user agent, but it might also be possible to simply change the polling/sampling rate of the underlying hardware counters, if not accessed via a higher level framework.

The specification requires implementing the rate obfuscation mitigation to keep track of the number of pressure changes over an implementation-defined sliding observation window and set a flag if an implementation-defined threshold for the number of pressure changes is exceeded. Similarly, it is also recommended for the implementation to observe any abnormal activity such as a high number of pressure state changes spanning across multiple states, and set this flag similarly.

If this flag is set, the implementation is recommended to give the pressure observer a penalty during which it will not be able to inform scripts of changes in its pressure state as it normally would. The duration of this penalty is implementation-defined and it is recommended to be randomized. When notify pressure observers resumes operation after the penalty, it only reports the latest pressure state and disregards any interim state information received from the platform collector during this penalty.

Based on implementation experience, implementers must use:

a range in between 50 and 100 changes for PressureObserver's [[MaxChangesThreshold]] internal slot.
a range in between 5000 milliseconds and 10000 milliseconds for PressureObserver's [[PenaltyDuration]] internal slot.

Note

This section is non-normative.

Based on implementation experience, implementers are advised to use:

a range in between 300000 milliseconds (5 minutes) and 600000 milliseconds (10 minutes) for PressureObserver's [[ObservationWindow]] internal slot.

Note

In a calibration process an attacker tries to manipulate the CPU so that this API would report a transition into a certain pressure state with the highest probability in response to the pressure exerted by the fabricated workload. This break calibration mitigation solution can slow down or prevent this calibration process from succeeding by slightly changing at runtime the implementation-defined low-level hardware metrics that contribute to these pressure state transitions. Even if the initial calibration would succeed, its results will be invalidated at runtime when this mitigation is running continuously. Any attempts to recalibrate will similarly be mitigated against.

Note

This section is non-normative.

Based on implementation experience, implementers are advised to apply the mitigation to a randomized time value within a range between 120000 milliseconds (2 minutes) and 240000 milliseconds (4 minutes).

Note

By default data delivery is restricted to documents served from the same-origin as an initiator of an active picture-in-picture-session, documents capturing or the document with system focus, if any.

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.

Shared workers can be shared across documents, such as top level document and those associated iframes. If one of the documents in the owner set passes the above data delivery requirements, the shared worker will qualify for data delivery. This means that the embedded iframe is able to pass along the data to the embedding document.

The Compute Pressure API is focused on improving the user experience. There are two ways in which applications that build on the API can positively impact accessibility.

Considering users' access needs when making decisions based on information gathered using the API.
Designing and making user interfaces based on information gained from the API with accessibility in mind.

As a consumer of the API, it's important to consider both of these opportunities. Here are some examples:

Decision: In a video conferencing scenario, there may be multiple video streams. The system may determines that it needs to drop certain streams in order to conserve resources. If one of the video streams comes from a sign language interpreter, then that stream must be prioritized over others, so that the user can still understand the conversation. In practice, this could be simply implemented by allowing the user to "pin" a certain stream, and ensuring that that pinned stream is never automatically dropped by the system.
User Interface:
- A simple load-level meter, in which the current usage level bucket is indicated on the screen. This information must be conveyed using more than just color, so that people who cannot perceive color can still perceive the information. A symbol could be used in conjunction with color. Text could also be used in conjunction with both shape and color.
- Some applications may present a notification to the user when some functionality is restricted due to compute pressure. These notifications may take the form of "toast" messages, in which case care must be taken to ensure that people using assistive technologies (including screen readers) can be made aware of the notification, and dismiss it, without unduly interrupting their workflow.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, and RECOMMENDED in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This specification defines conformance criteria for a single product: a user agent that implements the interfaces that it contains.

[dom]: DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[hr-time]: High Resolution Time. Yoav Weiss. W3C. 19 July 2023. W3C Working Draft. URL: https://www.w3.org/TR/hr-time-3/
[html]: HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[infra]: Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[mediacapture-streams]: Media Capture and Streams. Cullen Jennings; Bernard Aboba; Jan-Ivar Bruaroey; Henrik Boström; youenn fablet. W3C. 7 March 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/mediacapture-streams/
[PERMISSIONS-POLICY]: Permissions Policy. Ian Clelland. W3C. 18 December 2023. W3C Working Draft. URL: https://www.w3.org/TR/permissions-policy-1/
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[WEBIDL]: Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/

[ECMAScript]: ECMAScript Language Specification. Ecma International. URL: https://tc39.es/ecma262/multipage/

Compute Pressure Level 1

Abstract

Status of This Document

1. Introduction

2. A Note on Feature Detection

3. Concepts

3.1 Processing Units

3.2 Supported sources

3.3 Sampling and Reporting Rate

4. Platform primitives

5. User notifications

6. Policy control

7. Internal Slot Definitions

8. Pressure States

9. Contributing Factors

10. Pressure Observer

10.1 The PressureUpdateCallback callback

10.2 The PressureObserver object

10.2.1 The constructor() method

10.2.2 The observe() method

10.2.3 The unobserve() method

10.2.4 The disconnect() method

10.2.5 The takeRecords() method

10.2.6 The supportedSources attribute

10.3 The PressureRecord interface

10.3.1 The source attribute

10.3.2 The state attribute

10.3.3 The time attribute

10.3.4 The toJSON member

10.4 The PressureObserverOptions dictionary

10.4.1 The sampleInterval member

10.5 Life-cycle and garbage collection

10.6 Processing Model

10.6.1 Supporting algorithms

10.6.2 Data delivery

10.6.3 Queue a PressureRecord

10.6.4 Queue a Pressure Observer Task

10.6.5 Notify Pressure Observers

10.6.6 Handling change of fully active

10.6.7 Handle unloading document and closing of workers

11. Security and privacy considerations

11.1 Types of privacy and security threats

11.1.1 Timing attacks

11.1.2 Cross-site covert channel

11.1.3 Targeted de-anonymization attacks

11.2 Mitigation strategies

11.2.1 Data minimization

11.2.2 Rate-limiting change notifications

11.2.3 Rate obfuscation

11.2.4 Rate obfuscation normative parameters

11.2.5 Rate obfuscation non-normative parameters

11.2.6 Break calibration

11.2.7 Break calibration parameters

11.2.8 Same-origin restriction

12. Accessibility considerations

13. Examples

14. Conformance

A. Acknowledgments

B. IDL Index

C. References

C.1 Normative references

C.2 Informative references

10.1 The `PressureUpdateCallback` callback

10.2 The `PressureObserver` object

10.2.1 The `constructor()` method

10.2.2 The `observe()` method

10.2.3 The `unobserve()` method

10.2.4 The `disconnect()` method

10.2.5 The `takeRecords()` method

10.2.6 The `supportedSources` attribute

10.3 The `PressureRecord` interface

10.3.1 The `source` attribute

10.3.2 The `state` attribute

10.3.3 The `time` attribute

10.3.4 The `toJSON` member

10.4 The `PressureObserverOptions` dictionary

10.4.1 The `sampleInterval` member