- From: Wojciech Masłowski <wmaslowski@opera.com>
- Date: Thu, 30 Jun 2011 10:18:14 +0200
- To: Anne van Kesteren <annevk@opera.com>
- CC: Dominique Hazael-Massieux <dom@w3.org>, Andrei Popescu <andreip@google.com>, Steve Block <steveblock@google.com>, Doug Turner <doug.turner@gmail.com>, Lars Erik Bolstad <lbolstad@opera.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
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. -- Wojciech Masłowski Engeneering CORE Wrocław Opera Software ASA http://www.opera.com
Received on Thursday, 30 June 2011 08:23:37 UTC