RE: [vibration] Preliminary thoughts on the vibrator spec

Inline with [DG]

Deepanshu Gautam
Service Standards, Huawei Software
T: +86 25 5260008 M: +86 135 85147627


> -----Original Message-----
> From: Robin Berjon [mailto:robin@berjon.com]
> Sent: Wednesday, November 16, 2011 5:56 PM
> To: Deepanshu gautam
> Cc: public-device-apis@w3.org public-device-apis@w3.org; public-device-
> status@w3.org
> Subject: 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] Okay good. End of story :-)
> 
> > [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] Without this exposed to web apps directly, a poor implementation will not try to fix it and leave the user in cold too. As a developer (who wants to write good quality apps not poorly written apps) I would like to have a complete API which should serve all related aspects (if I'm invoking vibration I want to first make sure that vibrator is ON [if it exists] by myself [through the same API] not depending on user agent who *May* do so). Further, having it exposed to pages doesn't preclude user agent to do what it wants to do. User agent may still have this functionality for those poorly written apps who forgets things. 

> 
> > [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.
[DG] What deliverable you are talking about?
> 
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>

Received on Thursday, 17 November 2011 06:38:59 UTC