reillyeon
commented
4 months ago For 2.7, the answer could be "yes" since the vibration pattern is an input provided to the platform in order to perform the vibration. While this is trivially true of most APIs it may be important to note here because more complex vibration patterns require sending complex data to the platform which must be interpreted.
For 2.11, it may be worth noting that vibration itself is a part of the user agent or operating system's UI and this API allows a site to generate a stimuli which may otherwise be reserved for use by the system (e.g. as part of a higher-level API such as notifications).
anssiko
himorin
simoneonofri
Security and Privacy Self-review
What follows are the Security and 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:
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-defined reason that is not web-exposed, can be, for example:
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.
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 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:
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. A future version of this specification may specify a Permissions API integration subject to further implementation experience, privacy review, and other feedback.
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?
In theory yes, since the vibration pattern is an input provided to the platform in order to perform the vibration. While this is trivially true of most APIs it is worth noting here because more complex vibration patterns require sending complex data to the platform which must be interpreted.
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 (additional user feedback and additional implementation experience), the specification was updated to normatively require an explicit user mediation through user activation gating, 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). Considerations motivating the adoption of user activation gating over prompting were explicit user feedback 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.
As another UI related consideration, vibration itself is a part of the user agent or operating system's UI and this API allows a site to generate a stimuli which may otherwise be reserved for use by the system (e.g. as part of a higher-level API such as notifications).
See also: earlier implementation experience on limiting user activation gating to cross-origin iframes and 2.3 for Permissions API integration considerations.
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.
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.