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
>