Security and Privacy Self-review #36
Comments
|
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). |
|
@reillyeon thank you for your swift review. I integrated your suggestions to the respective sections with minor editorial tweaks only. |
|
between 2.6 (and 2.3), even we have stated mitigation in 2.2, there is possible fingerprinting surface on this vibration device feature (for 2.6), and there is no formally written integration with permissions API (for 2.3), I suppose we may need to state something more about such fingerprinting surface which has been pointed around some places... (note, design model of "allowing implementation to show a UI for user confirmation" does not compatible with nature of Permissions API, I believe) otherwise +1 to go. |
|
Thank you @himorin for your review and suggestions. I've updated 2.3 (and 2.11) to mention the Permissions API integration as a possible future work. Please check that I captured your feedback correctly and let me know if you'd prefer to add some additional text for the fingerprinting surface considerations. |
anssiko
added
the
privacy-tracker
simoneonofri
added
the
security-tracker
|
Security Review here w3c/security-request#71 (comment) |
Security and Privacy Self-review
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 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-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.
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 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.
Note
More explicitly specified behaviour for cross-origin iframes is being considered.
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.
The text was updated successfully, but these errors were encountered: