Re: Proximity alarm interface

On Thu, Jun 30, 2011 at 3:19 PM, Dominique Hazael-Massieux <dom@w3.org> wrote:
> Le jeudi 30 juin 2011 à 16:12 +0200, Wojciech Masłowski a écrit :
>> Probably watchPosition is better in that case but what I tried to say is
>> that it would be really is hard for
>> UA to differentiate between legit application and application which
>> tracks you. Just asking if user
>> allows the script to set up proximity alarms + a heuristic to warn user
>> about possible tracking and ask
>> him if he wants to retract his permissions is an interesting idea, but
>> it will only work if the heuristic is
>> quite accurate.
>
> What I had in mind was not to retract permissions after the fact, but
> rather that when the application asks for proximity alerts, it needs to
> send as a parameter all the locations that would trigger the alert.
>
> Based on that parameter, the UA would analyze (according to heuristics
> of its own) whether the request should be:
> * granted after asking the user with a non-scary message
> * flatly denied (in which case the app could then ask for watchPosition)
> * granted after asking the user with a really scary message
>
> (or granted only if the user has a privileged relationship with the
> site, or ...)
>

I see what you mean, although I'm not sure that's ideal from the Web
app developer's perspective: we're presenting them with an API that,
when called, will either fail outright, generate a scary or a
non-scary message. What motivation would they have to use it? I'm
afraid it'll just be easier to call watchPosition() as its behavior is
not subject to an opaque heuristic.

Thanks,
Andrei

Received on Thursday, 30 June 2011 15:36:16 UTC