- From: Andrei Popescu <andreip@google.com>
- Date: Tue, 2 Aug 2011 16:30:54 +0100
- To: Philippe De Ryck <philippe.deryck@cs.kuleuven.be>
- Cc: public-geolocation@w3.org, Giles Hogben <Giles.Hogben@enisa.europa.eu>, Lieven Desmet <Lieven.Desmet@cs.kuleuven.be>
Hi, Thanks for your email. On Mon, Aug 1, 2011 at 3:12 PM, Philippe De Ryck <philippe.deryck@cs.kuleuven.be> wrote: > The following comment contains detailed information about an issue that > was discovered during a recent security analysis of 13 next generation > web standards, organized by ENISA (European Network and Information > Security Agency), and performed by the DistriNet Research Group (K.U. > Leuven, Belgium). > > The complete report is available at http://www.enisa.europa.eu/html5 > (*), and contains information about the process, the discovered > vulnerabilities and recommendations towards improving overall security > in the studied specifications. > > Summary > --------- > The Geolocatin API allows a script to retrieve the last cached location, > together with an appropriate timestamp > > Based on: Geolocation API, 7 September 2010 > Relevant Sections: 5.1. Geolocation Interface > > Issue > ------- > > By forcing the retrieval of a cached value, using a timeout of 0, a > script can obtain the last cached position. By repeating this with > increasingly smaller values of maximumAge until an error occurs, it can > determine an approximate timestamp of this position. > Why would anyone want to determine the approximate timestamp of cached position? One can just look at the position's "timestamp" attribute to determine the exact value: http://dev.w3.org/geo/api/spec-source.html#timestamp I'm afraid I don't fully understand what the issue is exactly. Thanks, Andrei
Received on Tuesday, 2 August 2011 15:31:19 UTC