[vibration] Security and Privacy Self-review (#36)

anssiko has just created a new issue for https://github.com/w3c/vibration:

== Security and Privacy Self-review ==
# Security and Privacy Self-review

> [!WARNING]
> **This is a work in progress draft to solicit Working Group review and feedback for the Security and Privacy Self-review responses. The primary aim of this self-review is to provide supporting material for the privacy review of the specification. This content may also be helpful later as the group further improves the API.**

>[!TIP]
>Due to a rather long an varied history, some context setting first. Chrome shipped this API in 2013, following the initial implementation in Firefox in 2012. To prevent unintended use of the feature, Firefox made a change to its implementation in 2016 to gate the feature behind a permission prompt. During 2016-2017 Chrome solicited feedback from users and enabled user activation gating for the feature, first for third-party iframes only, then also for top-level, inspired by conceptually analogous web audio and video autoplay also gated by a user activation. Later, Firefox decided to make the API act as no-op.
>
>Due to complexity of revising a Recommendation under the old process, TR for this specification did not receive these latest updates informed by implementation experience, but they were incorporated into the Editor's Draft instead. This caused some unfortunate confusion among readers not closely watching the specification. To clear this confusion, supported by reinvigorated interest and process improvements for revising a Recommendation, this API is now being revived on the Recommendation Track to allow bringing the updates from the ED back to TR and to allow for further improvements using the modern streamlined publication flow.

What follows are the [Security and Privacy questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/) self-review responses for the Vibration API:

## 2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

No information is directly exposed. The security and privacy considerations section of the specification discusses both direct and indirect exposure considerations, quoting:

>[!IMPORTANT]
>Vibration API is not a source of data on its own and as such is not producing any data possible to consume on the Web. However, it is known that it can serve as a source of events for other APIs. In particular, it is known that certain sensors such as accelerometers or gyroscopes are prone to tiny imperfections during their manufacturing. As such, they provide a fingerprinting surface that can be exploited utilizing the vibration stimuli generated via the Vibration API. In this sense, Vibration API provides an indirect privacy risk, in conjunction with other mechanisms. This can create possibly unexpected privacy risks, including cross-device tracking and communication. Additionally, a device that is vibrating might be visible to external observers and enable physical identification, and possibly tracking of the user.

To mitigate these risks, including theoretical risks, the API is purpose-built to allow a conforming implementation flexibly abort the vibrate operation for any reason without disclosing the reason to the script. This bail out can happen at the following step of the perform vibration algorithm:

>An implementation MAY return false and terminate these steps

An implementation-defined reason that is not web-exposed, can be, for example:
- no vibration hardware is present
- the user has set a preference indicating that pages at a given origin should never be able to vibrate the device
- an implementation has set a cap for the total amount of time a page may cause the device to vibrate
- any other reason

This bail-out mechanism allows implementations to mitigate also indirect information exposure. If an implementation detects a web-exposed sensor capable of sensing vibration stimuli is listening, it can act in a no-op matter and bail-out from the perform vibration algorithm at this step. This mitigates the cross-device tracking and communication vectors discussed in the security and privacy considerations.

>[!NOTE]
>The mitigations discussed herein work equally to address user annoyance aspects that may not have a direct security or privacy impact. In such cases this bail-out mechanism allows implementations to avoid surprising the user with unexpected vibrations if implementation-defined additional requirements for enabling the API are not met.

## 2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

The API minimizes information it exposes directly by having only one return value, a boolean. Furthermore, the commonality of this boolean return value is increased and unique fingerprintability is decreased as outlined below.

The API returns true if the vibration operation is successful. An implementation can however also return true even if a physical vibration stimuli did not occur e.g. if a vibration cue is conveyed by other means than physical stimuli such as an implementation-defined visual indicator or other mechanism better suited to accessibility tools.

An implementation can return false for any reason, e.g. if the user has silenced the device or set a preference to ignore vibrations. To mitigate fingerprinting concerns, the reason for returning false is never web-exposed. This design minimizes observable characteristics that could be used to identify or re-identify a visiting user, user agent, device, operating system configuration setting or characteristics, or any combination thereof.

The Working Group is aware of a [theoretical mechanism](https://github.com/w3c/vibration/issues/12) that could allow an attacker to recover an implementation-dependent maximum length of the vibration pattern on a given device. To mitigate this attack, the specification provides the following guidance to implementers:

>If the length of a pattern is greater than max length an implementation of this API could consider breaking the request effectively into multiple shorter requests internally to achieve the same effect, rather than ignoring what follows the max length.

## 2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

This specification does not deal with PII.

## 2.4 How do the features in your specification deal with sensitive information?

See 2.3.

## 2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?

No.

## 2.6 Do the features in your specification expose information about the underlying platform to origins?

No. Availability or characteristics of the vibration hardware cannot be inferred from the boolean return value as discussed in 2.1 and 2.2.

## 2.7 Does this specification allow an origin to send data to the underlying platform?

No.

## 2.8 Do features in this specification enable access to device sensors?

No.

## 2.9 Do features in this specification enable new script execution/loading mechanisms?

No.

## 2.10 Do features in this specification allow an origin to access other devices?

No.

## 2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?

This API allows, but does not require, an implementation to make use of explicit user mediation through a native UI. Specifically, the API design allows a conformant implementation to show a UI to ask the user for permission to choose to allow or deny vibration on first invocation on a per-origin basis. The Working Group is aware of an early implementation in Firefox that showed a UI to the user. However, after considering further [implementation experience and user feedback](https://github.com/WICG/interventions/issues/25#issuecomment-273899959) ([additional user feedback](https://github.com/WICG/interventions/issues/47) and [additional implementation experience](https://groups.google.com/a/chromium.org/g/blink-dev/c/QGcpjisxtik/m/reSqe_HgCgAJ)), the specification was updated to normatively require an explicit user mediation through [user activation gating](https://html.spec.whatwg.org/#user-activation-gated-apis), requiring sticky activation state to be true. That means the user must interact with the site, with both first and third-party contexts considered separately, to allow a site to vibrate. Sticky activation requires an explicit click, tap, or press of a key. Specifically, scrolling past an iframe does not count as a user activation.

This design is conceptually analogous to how web audio and video autoplay is gated by a user activation ([design discussion](https://github.com/WICG/interventions/issues/23)). Considerations motivating the adoption of user activation gating over prompting were explicit [user feedback](https://github.com/WICG/interventions/issues/25#issuecomment-274098049) that user activation gating provides a better user experience for this API compared to native UI controls such as modal prompts, dialogs, or door hanger UIs and learnings from a large-scale use of the same mechanism for web audio and video autoplay.

See also: [earlier implementation experience on limiting user activation gating to cross-origin iframes](https://groups.google.com/a/chromium.org/g/blink-dev/c/7iVcwNcO3xw/m/WQSkkuk5BQAJ)

## 2.12 What temporary identifiers do the features in this specification create or expose to the web?

None.

## 2.13 How does this specification distinguish between behavior in first-party and third-party contexts?

This API is no-op until the user is actively interacting with the context. The sticky activation user activation state is not web-exposed and is considered for first-party and third-party contexts separately. This prevents third-party contexts such as embedded iframes from vibrating the device without user first interacting the third-party context explicitly. As per sticky activation semantics, this requires the user to explicitly interact with the third-party context and simply scrolling past an iframe does not enable the API for third-party context.

Notably, the perform vibration algorithm allows an implementation to block vibration in both first-party and/or third-party contexts even if the user has interacted with the said contexts. The "An implementation MAY return false and terminate these steps." bail-out step provides a specification conformant path for implementations who wish to further tighten privacy protections and employ additional implementation-specific mechanisms.

>[!NOTE]
>More explicitly specified behaviour for cross-origin iframes is [being considered](https://github.com/w3c/vibration/issues/15).

## 2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

No difference to the browser's 'normal' state.

## 2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Yes, combined together.

## 2.16 Do features in your specification enable origins to downgrade default security protections?

No.

## 2.17 How does your feature handle non-"fully active" documents?

The API does not disclose privacy-sensitive information and as such does not consider fully active for scenarios when the user navigates away, but gates access to the feature by sticky activation state and visibility state. Sticky activation spans multiple navigations as long as the same Document gets reused.

That is, vibration is not allowed, if the user has not interacted with the page and if the browser window is minimized, a browser tab is currently in the background, or a system element such as a task switcher obscures the page.

## 2.18 What should this questionnaire have asked?

That's all. Thank you for your review.

Please view or discuss this issue at https://github.com/w3c/vibration/issues/36 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 24 June 2024 20:17:55 UTC