Two formal objections submitted, one formal objection resolved per the Devices and Sensors WG discussion and resolution at TPAC 2024, and another still stands.
(Member) is submitting a formal objection to the recommendation of marking the Vibration API as obsolete. This recommendation would have significant implications for the web ecosystem and the developers who actively use this API.
The web ecosystem expands and improves when it is more capable, making it a viable option for developers to build their apps on. Conversely, when the capabilities of the web contract, this reduces the potential for developers to build their apps with the web.
If the primary concerns are that the Vibration API has only a single implementor, privacy issues, or that it should be part of another specification, we believe these issues can all be addressed without an obsolete recommendation. Specifically:
If a change is necessary, we recommend publishing as Note instead of removing Recommendation status.
We advocate for iterating on API designs rather than marking them obsolete. Doing so will allow the web ecosystem to grow and adapt instead of shrinking and becoming less capable for developers.
In parallel to preparation by the Team on AC review for Vibration API (Second Edition) Specification as Obsolete Recommendation, the Device and Sensors Working Group started their work on publication of Vibration API with changes incorporated. Publication made at 2024-11-28, see Appendix for full history. During discussion to deal with horizontal reviews, the Devices and Sensors Working Group resolved during TPAC 2024 to agree with obsoletion of existing Recommendation and to start new Recommendation track with publication as Candidate Recommendation Snapshot whose work was already in progress, since the second edition was published before updatable Recommendation procedure introduced to the Process and there is no way to update Recommendation in place with Candidate Amendments or Additions.
Conversations with the objector continued after WBS of AC review closed at 2024-11-05, including updates on Vibration API publication as Candidate Recommendation Snapshot, but the Formal Objection stands with request of written report.
This is consistent with a draft for Implementation Report for the W3C's Vibration API by manual tests at June 8, 2024 provided in the github comment by Marcos Cáceres.
Per comments raised during discussions for removal or disabling Vibration API in Firefox and WebKit, concerns related to Permission API integration are strictly raised and already discussed, but the Devices and Sensors WG has discussed and rejected explicitly (e.g. comment at issue on integration with Permission API).
Before the last Recommendation publication of Vibration API (2016-10-18), horizontal review by PING pointed out six privacy considerations including adding Security and Privacy Considerations section (original thread for draft text) and several threat models.
In the past implementation discussion, potential plans about Permission API integration were discussed (issue raised 2016-06-15), but just marked as v2 and no activity found after 2016. Also, there was past discussion about adding 'vibration' to Permission Registry Enum (in permissions space), but it seems there was no such coordination happens, nor in mozilla code (code and commit). There was a comment in bugzilla.mo about implementation not being updated since there is no Permission API integrated.
Privacy horizontal review at 2024 July has pointed out missing Integration with permissions API (#42), and the Devices and Sensors WG stated other mitigation is sufficient and no need to integrate with Permissions API, and PING agreed to mark it as non-blocking with resolving in the next version (2024-10-10).
Although Gamepad API (working draft status as of 2024-07-15, latest publication at 2025-02-14) has GamepadHapticActuator Interface to support a configuration of motors or other actuators that can apply a force for the purposes of haptic feedback, but haptics feature on mobile devices are not exposed as Gamepad.
Permissions API is to enable standard way of requesting and granting Permissions from user, but is not a place to enable specific device oriented feature like vibration.
Considering the current implementation status, and the unlikeliness to be re-implemented by others who have been removed their implementation without further specification development including integration with Permissions API, the W3C Team recommends 1) overruling the Formal Objection and marking the Vibration API (Second Edition) as Obsolete Recommendation, and 2) the Devices and Sensors Working Group should revisit to the discussion related to mitigation of privacy concerns without any past option or selection on table, and seek the best way under the current situation of market and technology with Web communities in general.