Re: [w3ctag/design-reviews] Approximate Geolocation (Issue #1131)

alvinjiooo left a comment (w3ctag/design-reviews#1131)

> The proposal looks interesting, we still have a few comments:
> 
> 1/ Requesting several times an approximate location could lead to disclosing the real location, if not cached or strictly rate-limited, the spec should consider being explicit about that risk
I agree that this is a critical risk. I have updated the [explainer](https://github.com/explainers-by-googlers/approximate-geolocation?tab=readme-ov-file#threats-and-mitigations) so now it matched to what we have in spec [PR](https://pr-preview.s3.amazonaws.com/alvinjiooo/geolocation/pull/195.html#preventing-precise-location-reconstruction) to be explicit about this threat, which we refer to as a "precise location reconstruction" attack.

> 2/ location in general is not easy to fake, unlike an ip address which can be hidden using a VPN as an example. Even if it is not currently considered, coarse location should not be considered equivalent to IP geolocation, unless the same capability of intentionally changing location is available.
I agree that approximate geolocation, as proposed here, is not equivalent to IP-based geolocation or a user's ability to provide an arbitrary location. The goal of this proposal is to empower users to share a less precise version of their actual location to enhance privacy, rather than to enable location spoofing. The control offered to the user is the choice between "precise" and "approximate," which we consider is an privacy enhancement for users.

> 3/ There is a concern of leakage of private information due to the granularity of the coarsing algorithm provided at the OS level. The spec includes this in [Preventing Precise Location Reconstruction](https://pr-preview.s3.amazonaws.com/alvinjiooo/geolocation/pull/195.html#preventing-precise-location-reconstruction:~:text=a%20user%2Dagent%2Ddefined%20time%20window%20SHOULD%20return%20the%20exact%20same%2C%20cached%20approximate%20position%20data.%20A%20user%20agent%20might%2C%20for%20example%2C%20use%20a%20time%20window%20of%2015%20minutes.) by throttling the geolocation data intervals to every 15 minutes. There is no mention of that in the explainer. Can you please clarify that, and highlight any other defences against this?
Thank you for pointing out, similar to point 1), I have just updated the [explainer](https://github.com/explainers-by-googlers/approximate-geolocation?tab=readme-ov-file#threats-and-mitigations) to include the threat and mitigation discussion. If we spot on more threats then we can continue to update section and try to come up mitigations.




-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1131#issuecomment-3286398319
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1131/3286398319@github.com>