Re: Formal objection to raised Vibration API issue #33

   hi Marcos,

   The Devices and Sensors Working Group has decided to update the Vibration API
specification, by publishing a new Candidate Recommendation Snapshot:

   https://lists.w3.org/Archives/Public/public-device-apis/2024Jun/0004.html


   In order to do so, WG are requesting wide review of their document, including
the security and privacy horizontal reviews:

   https://github.com/w3c/vibration/issues/39


   Potential concerns, including the ones you raised related to privacy and
overall approach, would be addressed as part of this update.

   Since you raised a formal objection related to your request to obsolete the
Recommendation, you may prefer to hold on us proceeding forward while the update
is ongoing. Please let us know before July 16 if you would like to hold,
otherwise we'll continue to proceed with your formal objection and request to
form a council.


   Thank you,

   Atsushi


----
   Below are more details related to current implementation status and current
steps of the Devices and Sensors Working Group.


1. implementation status

    Chrome implementation is in blink part [1], but device mapping was only
implemented on Android platform [2,3]

*1 https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/vibration/vibration_controller.cc;l=202;bpv=0;bpt=1

*2 https://source.chromium.org/chromium/chromium/src/+/main:services/device/vibration/vibration_manager_impl.cc

*3 https://source.chromium.org/chromium/chromium/src/+/main:services/device/vibration/vibration_manager_android.cc;l=23;bpv=0;bpt=1


    Firefox disabled Vibration API totally 2024-06-12 [4]. Related bmo bug at [5,6].
Potential some plan about Permission API integration was pointed [7], but just marked
as v2 and no activity found after 2016. Also, there was past discussion about
'vibration' to Permission Registry Enum [8], but it seems there was no such
coordination happens, nor in mozilla code [9,10]. Also there was a comment about
implementation has not updated since there is no Permission API integrated [11,12].

*4 https://hg.mozilla.org/mozilla-central/rev/3b2c2ba40e73

*5 https://bugzilla.mozilla.org/show_bug.cgi?id=1900037 (bug referenced by [4])
*6 https://bugzilla.mozilla.org/show_bug.cgi?id=1653318

*7 https://github.com/w3c/vibration/issues/10

*8 https://github.com/w3c/permissions/issues/173

*9 https://github.com/mozilla/gecko-dev/blob/master/dom/webidl/Permissions.webidl

*10 https://github.com/mozilla/gecko-dev/commits/master/dom/webidl/Permissions.webidl

*11 https://bugzilla.mozilla.org/show_bug.cgi?id=1495036

*12 https://github.com/mozilla/standards-positions/issues/907#issuecomment-1768244124


    Webkit removed its implementation at 2017-05-11 [13,14].

*13 https://trac.webkit.org/changeset/216696/webkit

*14 https://bugs.webkit.org/show_bug.cgi?id=171766



2. privacy concerns / Permission API integration

    As [7-8], Permission API integration was raised (2016-06-15) before 2nd edition
REC publication (2016-10-18), but marked as future work with label 'v2' [15].
    DAS WG decided to try bringing updates on Vibration API as a draft with
substantive changes [16], and formally submitted (full) HRs on Vibration API [17],
including Privacy review [18]. So, potential concerns will be addressed during
there. Of course, review comments will not directly have any procedural pressure
on existing REC, but most of potential (or listed) concerns should be formalized
there.

*15 https://github.com/w3c/vibration/labels/v2

*16 https://lists.w3.org/Archives/Public/public-device-apis/2024Jun/0004.html

*17 https://github.com/w3c/vibration/issues/39

*18 https://github.com/w3cping/privacy-request/issues/138




> I raise a formal objection on the Vibration API’s issue [#33]. 
> 
> Rationale: 
> 
> The W3C Vibration API is falsely claiming to be implemented by Firefox, as indicated in the implementation report. In reality, Firefox no longer supports the API in that it doesn't actually vibrate. Furthermore, the specification hasn't received interest from any other implementer in years. 
> 
> Additional reasons for obsoleting the Vibration API include:
> 
> - **Privacy Concerns**: The Vibration API can potentially be used in conjunction with other APIs to track or fingerprint devices. For instance, by generating specific vibration patterns and monitoring the timing and response of those vibrations through sensors or other feedback mechanisms, malicious actors could create a unique identifier for a device. This risk is heightened when combined with other data points, leading to more accurate device or user tracking. The specification itself already acknowledges these privacy concerns, but they remain unresolved in practice.
> 
> - **User Experience**: Haptic feedback from vibration can be perceived as intrusive and annoying by users, which is why some browsers have disabled or limited its use.
> 
> - **Technological Redundancy**: Modern devices and platforms offer more advanced and flexible haptic feedback mechanisms that are not reliant on the web's Vibration API (e.g., Gamepad API).
> 
> [#33] https://github.com/w3c/vibration/issues/33