- From: Richard Barnes <rbarnes@bbn.com>
- Date: Tue, 27 Jan 2009 14:25:30 -0500
- To: Erik Wilde <dret@berkeley.edu>
- CC: Doug Turner <doug.turner@gmail.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
I agree with Doug here. As long as the choice of location provider is invisible to the web app (as the current thinking seems to be), "lying" is just providing location from another (false) location provider. --Richard Erik Wilde wrote: > > you could. but you could also imagine the device having a "fake > location" configuration. in that case, apps don't know that they're > being lied to. which probably is what you want as a user, unless you're > lying in a ditch with a broken leg and wish your device would send out > your real location with its emergency app and not the fake one... > > Doug Turner wrote: >> >> Hi Dret, >> >> This is an implementation detail. You could imagine a User Agent >> supporting "Lying" by allowing their user to define their location >> manually in some manner. >> >> Doug >> >> On Jan 27, 2009, at 10:20 AM, Erik Wilde wrote: >> >>> >>> hello everybody. >>> >>> "Any good social geoapp will let you type in a fake position manually." >>> >>> http://www.wired.com/gadgets/wireless/magazine/17-02/lp_guineapig >>> >>> interesting article. we recently had this discussion about "just the >>> current position" vs. "any position", and i guess the underlying >>> question is, given the above statement, can i lie to my app, and/or >>> can i lie to my device? there's a trade-off; if i can lie to my app, >>> all my apps have to support lying, and i have to be consistent at >>> lying. if i can lie to my device, i only have to do it once, and then >>> all my apps will be fed the same lie. this in a way does not affect >>> the API design, but i think if the wording in the draft implies (and >>> i don't know that) that the position has to be the real and true >>> position of the device/user, then this could be changed to saying >>> something like "assumed position". >>> >>> cheers, >>> >>> dret. >>> >> >
Received on Tuesday, 27 January 2009 19:26:13 UTC