Re: [sensors] Device Proximity

Dave,

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?

Thanks again for bringing this up.
Doug


----- Original Message -----
From: "Dave Raggett" <dsr@w3.org>
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: "Marcos Caceres" <w3c@marcosc.com>, "Dzung D Tran" <dzung.d.tran@intel.com>, "Doug Turner" <dougt@mozilla.com>, "Anssi Kostiainen" <anssi.kostiainen@nokia.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Sent: Friday, May 11, 2012 4:17:38 AM
Subject: Re: [sensors] Device Proximity

In further support of the near/far model, exposing min/max values which
vary from one device to another is a boon for fingerprinting, whereas
near/far is not.

On 10/05/12 23:19, Jonas Sicking wrote:
> On Wed, May 9, 2012 at 2:16 PM, Marcos Caceres <w3c@marcosc.com> wrote:
>> On Wednesday, May 9, 2012 at 10:13 PM, Tran, Dzung D wrote:
>>>> So, what I agreed with jonas about was a new event that only fired when there was a transition between near and far. device proximity for something that was more advanced. <insert this new event name here> for something really simple.
>>>
>>>> Thoughts?
>>>
>>> What I am afraid of is that browsers going to interpret far versus near differently on the same device. I rather to give the control to the programmer to interpret base on value, min, max.
>>
>> I'm afraid of the opposite thing. I more trust the people that are closer to the os (or directly interfacing with the hardware) to handle that.
> 
> I agree with Marcos here.
> 
> My concern is that with an API that exposes the raw data, we also end
> up exposing the inconsistencies between different devices/browsers.
> The web is notoriously bad at dealing with such inconsistencies.
> 
> Say that we only expose .min/.max/.value. This means that in order to
> solve one of the most common use-cases of detecting that the user is
> holding the device against his/her face the page will have to do
> something like:
> 
> window.onproximitysensor = function(e) {
>   if (e.min == e.value) {
>     game.pause();
>   }
>   else {
>     game.unpause();
>   }
> }
> 
> This will work great on low-precision hardware which only returns the
> values 0cm or 5cm (I'm told this is common for proximity sensors
> today).
> 
> However say that 2 years from now hardware vendors start putting in
> higher precision proximity sensors which detect distance down to 1mm.
> This means that the above code will only pause the game if the user
> presses the phone against the sink right where the sensor is.
> 
> I know that I often either hold my phone against my ear, which means
> that if the proximity sensor is located just above the speaker, the
> proximity sensor might end up above my ear and 1-2 cm away from the
> skin on my cranium.
> 
> So the above code would suddenly start to fail since e.value would be
> 1.5 and e.min would be 0. This leaves the browser vendor with the
> choice of:
> 
> 1. Expose high precision data and make websites fail to detect that
> the user is holding the device against the head.
> 2. Not expose high precision data.
> 3. Add a "proximity2sensor" event which contains the high precision data.
> 
> None of these solutions are good.
> 
> We can certainly evangelize that pages write code like
> 
> window.onproximitysensor = function(e) {
>   if (e.min == e.value || e.value < 2) {
>     game.pause();
>   }
>   else {
>     game.unpause();
>   }
> }
> 
> but evangelizing has traditionally not been very effective.
> 
> This is why I think we should expose simple "near"/"far" data,
> preferrably through a separate event. I would also add a warning to
> the "proximitysensor" event in the specification saying that different
> devices will have different .min/.max values as well as different
> resolution and if authors want to just detect "near"/"far" the other
> event.
> 
> / Jonas
> 
> 


-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Friday, 11 May 2012 15:14:14 UTC