Re: Vibration API: making feature detection possible

To chime in on the fingerprinting/feature detection question:

On October 10, 2013, at 12:26 AM, Peter Beverloo <beverloo@google.com> wrote:

> On Tue, Oct 8, 2013 at 9:20 PM, <Frederick.Hirsch@nokia.com> wrote:
> I believe one reason for not doing this is to reduce the possibility of fingerprinting through feature detection. 
> 
> The device being used by the user is already included in the user agent.  It's not hard to set up a mapping to see which devices have a vibrator.  The fingerprinting risk then comes down to (1) user-agent specific limits for the duration, and (2) whether vibration is allowed in the current context.  Both sound reasonable to expose..

It's true that this is a relatively small source of entropy (one bit), but: 1) users who change default settings (likely uncommon) may be much more fingerprintable this way; 2) distinguishing whether a call is being made for functional or fingerprinting purposes would be difficult; and 3) whether the feature is disabled may be an indicator of the user's accessibility settings, which are often considered sensitive.

> Is there a strong reason to need to know whether or not vibration is enabled, when asking for vibration with the expectation for best effort may be good enough?
> 
> What is the use case for the change? If vibration is not possible what would be reasonable fallbacks (flash the screen a la emacs)?
> 
> Being able to provide alternative behavior when vibration is used as a form of haptic feedback.

For at least some of those fallback cases, the browser would likely be in a better position to provide alternative feedback than the web application. For example, "visual beep" is an option in some operating systems or terminal environments as a system-wide setting. When I change preferences in my Mac OS Accessibility panel, beeps are registered by applications in the same way, but presented to me differently; not every application on my machine has to check the alert audio status and do something visual in response.

Thanks,
Nick