Re: [sensors] Use Cases and pros/cons Re: [sensors] Device Proximity

On Friday, May 11, 2012 at 4:49 PM, Marcos Caceres wrote:

> Hi All,  
> I think we are reaching the point in the thread where we are starting to see circular discussions. Can we now capture more formally the use cases, requirements, and proposals.  
>  
> Please contribute a bit to the use cases and requirements below…  
>  
> Here is a summary from what I have gathered so far from the discussion.  
>  
> USE CASES
> 1. Detect when phone is next to ear, to, for example:  
> * turn off the screen/stop unintended interaction.
> * << add more here >>
>  
> 2. Detect when user is no longer at computer, to, for example:  
> * stop doing intensive processing.  
> * automatically log user out of Website.  
> * << add more here >>
>  
 3. Control an aspect of a video game…  
TBW… waiting for concrete examples.  
>  
>  
> REQUIREMENTS:
> * Should not eat the battery?
> * Should not force the sensor to be on all the time?  
>  
>  
>  
> API Proposals are:  
>  
> === "Min, Max, Value" ===
> This proposal allows developers to detect the presence of an object.  
>  
> Pros:  
> * Gives developer control to detect presence of physical object (e.g., someone's head) with potentially a high degree of accuracy.  
> * deals with a large number of future use cases, like detecting things at greater distance and with more accuracy.  
> * << add more here >>
>  
>  
>  
> Cons:  
> * could generate a high number of events (which may serve limited purpose).  
> * could lead to finger printing.  
> * could be difficult for developers to understand variation between values provided by hardware (which could lead to wrongly detecting if an object if really near).  
> * << add more here >>
>  
>  
>  
>  
> === "Near/Far" ===
> The API only returns if a physical object is near the sensor or not.  
>  
> Pros
> * Leaves it to the hardware/implementation to work out what is far near.
> * Only two events are fired: when "far" and "near".  
> * Makes it hard to use for fingerprinting.  
> * << add more here >>
>  
>  
>  
> Cons:
> * Leaves it to the hardware/implementation to work out what is far near.  
>  
>  
> * Limited useful feedback/data is given to developers.  
> * << add more here >>
>  
>  
>  
> I hope that helps.
>  
> --  
> Marcos Caceres
>  
>  
> On Friday, May 11, 2012 at 4:29 PM, Dave Raggett wrote:
>  
> > On 11/05/12 16:13, Doug Turner wrote:
> > > I love this kind of input. It is important to remember that
> > > fingerprinting is a concern. However, I think that you might be
> > > better off discussing fingerprinting at the w3 privacy wg.
> > > Fingerprinting can be done on many APIs, not just these Device APIs.
> > > Do you have a concrete proposal to address these concerns across the
> > > main APIs, or are you just waving the fingerprinting flag as a
> > > reminder to us all?
> >  
> >  
> >  
> >  
> >  
> > We were discussing the pros and cons of {min, max, value} events versus
> > near and far events for proximity. Finger printing is just one of the
> > factors to take into account.
> >  
> > I would like to better understand the use cases. Is it mostly about
> > sensing when a smart phone is against someone's ear? I don't really
> > understand that for web apps though, unless you are using the web app as
> > an audio player or a P2P voice call over Web RTC. Another use case is
> > disabling the display or otherwise reducing battery demands when someone
> > isn't near the device. In this case, we are presumably talking about
> > sensing someone further away from the device. What am I missing about
> > the use cases for proximity and web apps?
> >  
> > --  
> > Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>

Received on Friday, 11 May 2012 15:53:44 UTC