Re: Proximity alarm interface

On Thu, Jun 30, 2011 at 9:18 AM, Wojciech Masłowski
<wmaslowski@opera.com> wrote:
> W dniu 2011-06-29 18:16, Anne van Kesteren pisze:
>>
>> On Wed, 29 Jun 2011 15:18:46 +0200, Andrei Popescu <andreip@google.com>
>> wrote:
>>>
>>> Yep, this would reduce the number of requests to the server, although
>>> that can be even further reduced as Steve suggested. Whether the gain
>>> is big enough to warrant adding a new API just for one
>>> usecase...that's something I'm not totally sure.
>>
>> I think the primary use case is privacy. For store offers (groupon),
>> meetings (conferences, etc.), and a bunch of other cases I'd be happy to
>> tell the site I'm around, but not tell them where I am all the time.
>>
>>
> The problem with privacy here is that it boils down to asking user one of
> two questions either
> A) Do you allow script to set up a proximity alarm at XY
> B) Do you allow script to set up proximity alarms whereever.
>
> With option A you gain some more fine grained privacy, but I think one of
> the main use case is a site setting multiple proximity alerts for it's
> points of interest, for example PizzaHut site would like to set up proximity
> alert when you get next to any PizzaHut in your town. This would imply
> flooding the user with security questions and would result in him just
> clicking ok without thinking after a few.
>
> Option B is no security gain in my opinion as you can just set up loads of
> proximity alerts and locate user using them.
>

Yes, you can probably work out roughly where the user is from IP, then
set up a set of proximity alerts that will track the user with almost
the same accuracy as watchPosition(). It's slightly more involved but
perfectly possible, so I agree the privacy gains aren't that great.

Thanks,
Andrei

Received on Thursday, 30 June 2011 08:23:46 UTC