Contact emails [email protected]
[email protected] [email protected] Explainer URL https://github.com/explainers-by-googlers/approximate-geolocation Specification https://github.com/w3c/geolocation/pull/195 Summary We propose an extension to the Geolocation API that introduces a new option, accuracyMode, to getCurrentPosition() and watchPosition(). This change allows the browser to return either precise or approximate location data based on the user's granular permission setting for the site. This mechanism is designed to resolve the existing privacy/utility conflict by honoring the user's intent to share a low-precision location. Blink component Blink>Geolocation Motivation The standard Geolocation API currently creates a poor privacy/utility trade-off: many websites need only an approximate location (e.g., for local weather or content localization) but receive high-precision data, posing a significant privacy risk. While the existing enableHighAccuracy option is intended to indicate the application's preference for accuracy, it is only a non-binding hint and does not provide a mechanism for the user agent (browser) to enforce a specific, low-precision outcome. To solve this, we propose the Approximate Geolocation. This extension introduces a new option, accuracyMode, to getCurrentPosition() and watchPosition() that provides an explicit mechanism for both site and user control: 1. It allows sites to explicitly request an approximate location. 2. Crucially, it enables the browser to reduce precision when a site requests precise location but the user has only granted an "approximate" level of permission. By introducing this new, privacy-preserving permission state, we aim to enhance user control while satisfying the vast majority of website use cases. TAG review https://github.com/w3ctag/design-reviews/issues/1131 RisksInteroperability and Compatibility - Existing Geolocation API: This feature is an addition to the existing API. Existing calls without the new option will function as they do today. - Browser Positions: - Gecko/Firefox: - (Under consideration) https://github.com/mozilla/standards-positions/issues/1193 - WebKit/Safari: - (Positive) https://github.com/WebKit/standards-positions/issues/470 - *Web developers*: - No Signal WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? No change in WebView behavior Debuggability None Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? No, but planning to add web platform tests before shipping. Tracking bug N/A Launch bug https://launch.corp.google.com/launch/4416196 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5143609755828224 -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHdTo6ocBp%2BYSLs%3D7-w9%3Dbizb6G2azmpUVUyWy5yRndTR8LBiA%40mail.gmail.com.
