Re: Formal objection to raised Vibration API issue #33

I think my objection holds because the working group is not chartered to work on haptics. Dropping to CR seems not great unless they recharter. Also, I’d like to see my implementation report adopted and a clear understanding of how all the problems with every website that uses the API will be addressed. 

If we get a plan in place, then I can drop my objection. But as it stands, the objection stands. 

> On 12 Jul 2024, at 02:27, Atsushi Shimono (W3C Team) <atsushi@w3.org> wrote:
> 
>   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
> 
> <OpenPGP_signature.asc>

Received on Friday, 12 July 2024 03:53:42 UTC