W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

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

From: Marcos Caceres <w3c@marcosc.com>
Date: Fri, 11 May 2012 16:49:32 +0100
To: public-device-apis@w3.org
Message-ID: <2170C299EF144A4594E592C222856D85@marcosc.com>
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 >>



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:50:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 11 May 2012 15:50:09 GMT