Re: [vibration] Preliminary thoughts on the vibrator spec

[Do we really need to CC public-device-status? This work is normally part of public-device-apis and not the TF.]

On Nov 16, 2011, at 10:45 , Deepanshu gautam wrote:
> [DG] I don't quite understand "fingerprinting surface" in this context but I guess you are referring to "added authorization" which may be a concern for user privacy, correct me if I'm wrong? If I'm right then I don't understand how it will increase "needed authorization" specifically when user may/must have been authorized by so many other existing ways before even start using the page/application in question here. Vibration is just a part of the page/application which user must be authorized/authenticated to use/consume.

Fingerprinting is the practice of identifying a user without requiring cookies or other such identifier storage simply by looking at the properties publicly exposed by her user agent. A good demo is http://panopticlick.eff.org/.

In general we try to avoid fingerprinting because it is a major privacy concern. I'm not convinced that fingerprinting is an issue in this specific case, however.

> [DG] I'm sure there are reason for volume control to work this way. But here, if vibrator is OFF (natively) user may never know (until notified) that the page/application supports vibrations (this will degrade user experience). And, if Vibration API can handle it without depending on the OS, then why shouldn't it?? This is the model users already understand, so I think we should reuse it.
> [DG] Do you think user will not understand "Switch on Vibrator?, allow, not-allow, allow-now, allow-forever"?

I understand your use case but I don't see why it would have to be exposed to the web application. The user agent can, of its own accord, notice that a page is trying to use vibration (or sound, or whatever else) while it is turned off, and notify the user of the issue. UAs can get this right across the board whereas exposing it to pages means that poorly written apps that could use this functionality will forget to do so and leave the user in the cold, and poorly written apps that shouldn't use this functionality will use it and annoy users.

> [DG] PS: Further, I can come up with many usecases where it will be very beneficial for a web app to know if the device is muted, but that not something we should put up here :-)

If you have use cases, please be sure to send them (in a separate thread) as that topic is a deliverable of this group.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Wednesday, 16 November 2011 09:56:17 UTC