Geolocation and Privacy

Matt Reynolds (Google Chrome)

W3C TPAC 2025 breakout

Agenda

• History lesson
• WAP forum, W3C, IETF, OGC
• Geolocation on the early web
• Browser-based location APIs
• Review current proposals
• Approximate geolocation
• <geolocation> element
• Open discussion

WAP = Wireless Application Protocol Forum

IETF = Internet Engineering Task Force

OGC = Open Geospatial Consortium

Notable location privacy orgs

• World Wide Web Consortium
• 1998: Mobile Access Workshop
• 2000: WAP-W3C Joint Workshop on Mobile Web Privacy
• 2008: Geolocation WG formed
• IETF Geographic Location/Privacy WG (GeoPriv)
• 2001: Presence Information Data Format (PIDF)
• 2004: PIDF Location Object (PIDF-LO)
• 2005: Revised Civic Location Format for PIDF-LO
• Open Geospatial Consortium
• 2000: Geography Markup Language (GML)
• 2008: Geospatial eXtensible Access Control Markup Language (GeoXACML)

WAP-W3C Joint Workshop on Mobile Web Privacy (2000)

Goal: Define an architectural framework for location that includes access controls for position information.

Introduction To WAP Location Drafting Committee and Privacy Concerns Ewan Cameron (SignalSoft Corp)

WAP-W3C Joint Workshop on Mobile Web Privacy (2000)

No institutional ownership for location privacy

​

​

​

Agnostic about legal/policy issues

Introduction To WAP Location Drafting Committee and Privacy Concerns Ewan Cameron (SignalSoft Corp)

WAP-W3C Joint Workshop on Mobile Web Privacy (2000)

Who owns the location information?

Introduction To WAP Location Drafting Committee and Privacy Concerns Ewan Cameron (SignalSoft Corp)

WAP-W3C Joint Workshop on Mobile Web Privacy (2000)

At different times or locations, different rules may apply. It's important to distinguish between the device operator and the recipient of the location data.

Introduction To WAP Location Drafting Committee and Privacy Concerns Ewan Cameron (SignalSoft Corp)

IETF Geographic Location/Privacy WG (GeoPriv)

Founded in 2001 to develop a location representation for use in internet protocols.

Privacy concerns:

• Who controls the raw location data?
• Who performs the location computation?
• How are privacy rules communicated when location data passes between entities?

IETF GeoPriv: Presence Information Data Format - Location Object

Goal: Define a standard XML format for geographical information and associated policy requirements.

A <geopriv> element has:

• <location-info> containing one or more chunks of location info
• <usage-rules> containing policy requirements
• "retransmission-allowed" - 'yes' if the recipient is allowed to share the location info with other parties
• "retention-expiry" - The recipient must discard the location info after this datetime
• "ruleset-reference" - URI pointing to the full policy ruleset
• "note-well" - Generic privacy directives as human-readable text, not intended for automatic processing

IETF GeoPriv: A process for obscuring location

​

Goal: Develop algorithms to obscure location information as a privacy mitigation.

Many important observations:

• A non-uniform distribution is not conducive to obscuring.
• The intersection of multiple reported locations may be used to refine a location estimate.
• If the target is changing locations, updating too frequently may reveal precise location information.
• The location update trigger condition must not reveal information.
• Repeatedly visiting the same location may reveal the precise location.

2025 update: Location obscuring is not effective

github.com/mozilla/standards-positions/issues/1193#issuecomment-2726294295

ASCII art appreciation slide

IETF GeoPriv: Civic Location

Goal: Allow <location-info> to contain civic location information.

• <civicAddress> contains one or more of:

Open Geospatial Consortium: GeoXACML

Goal: Provide fine-grained access control for a Geo Data Infrastructure service.

Geometry-specific security & privacy considerations:

• "precision" - The number of digits after the decimal point in latitude and longitude values
• "allowTransformation" - 'true' if the position may be transformed into another coordinate reference system

Geolocation on the early web

• IP-based geocoding
• Estimated latitude and longitude from ISP-sourced information
• google.loader.ClientLocation (Google AJAX API Loader)
• Provides latitude, longitude, city, region, country, country_code
• Uses IP-based geocoding
• Google Gears (browser add-on)
• Explicit per-app permission prompt
• Uses Wi-Fi APs, cellular nodes to estimate location
• Mozilla Geode (browser add-on)
• Uncertainty level is paired with the site permission
• Uses Wi-Fi APs, cellular nodes to estimate location

Google Gears Geolocation API (2008-2011)

Based off of the proposed W3C Geolocation API: getCurrentPosition, watchPosition, clearWatch

Reverse geocoding: Pass gearsRequestAddress:true to request civic address info (streetNumber, street, city, region, postalCode, country)

Mozilla Geode (2008-2009)

Geode provided an experimental implementation of Geolocation API ahead of official support in Firefox.

The add-on prompts for permission and uncertainty level. Uncertainty is introduced by a "fuzzing" algorithm.

Mozilla originally planned to implement location fuzzing in Firefox but decided against it.

2008 spec discussions: Who is responsible for privacy?

​

Can privacy and security be handled by a separate forum?

The spec should highlight the security concerns and suggest possible ways for implementations to address those concerns, and nothing else.

Let other parts of the industry figure this out, such as IETF, OMTP or OMA. The W3C should focus exclusively on defining good APIs, which is a hard enough task.

2008 spec discussions: Who is responsible for privacy?

Is privacy the user agent's responsibility?

I think that the UA is in the best position to to make decisions about the privacy of their users. It is hard to define what the UX should be across varying applications and I believe this work is outside our scope.

Or should it be addressed by W3C?

If you want to settle for loose wording or vague statements with no teeth, you have underestimated how seriously people take privacy for location.

To simply assert in a spec that any implementation MUST take privacy into account while being silent on HOW to do so accomplishes nothing, and will do absolutely nothing to change the norm - which is to wholly ignore privacy.

2008 spec discussions: Privacy policy integration

Can browser makers leverage GeoPriv?

Browser makers have the ability (say, by adopting Geopriv) to force downstream site and app developers to consider and (we hope) protect privacy.

The browser makers will of course not be able to force downstream developers to in fact play nice on privacy, but if the user's "expectation of privacy" is made clear to the downstream developer, then the developer's local law may force them to honor those expectations.

As a user of a particular browser, I will hesitate to give permission for my location to be given to anyone, because I have zero assurance that the ultimate recipient of my location info will not abuse it.

2008 spec discussions: Privacy policy integration

Expecting the law to uphold technical specifications is IMHO highly inappropriate. Using technical specifications to uphold morals is equally inappropriate.

Mozilla does share the concerns voiced in the GeoPriv charter, but does not share the idea that creating APIs makes this problem smaller. Instead, we believe that much of what GeoPriv provides could be addressed by a recommended guideline for websites, similar to the Web Content Accessibility Guidelines.

There is no way for the user-agent to ensure that the claims made by the website are actually true. This would break the separation between the (trusted) user-agent UI and the (untrusted) site content and undermine the user's trust in the user-agent.

2008 spec discussions: Location accuracy/uncertainty

If we feel that we need to have levels of privacy shouldn't we add the ability to return a boundary rather than a point?

It might be a good idea to also assert that the user agent can modify the Position object to enforce any specific privacy concerns.

In place of enableHighAccuracy, instead specify a target uncertainty. Different values for horizontal and vertical uncertainty are common. These targets would be "soft" in that if the uncertainty target couldn't be met, the result could still be provided.

2008 spec discussions: Civic location

Geodetic position is one component of a richer Position object. v1 might define a simple structure:

Then v2 could extend this object to add civic and rules without changing the behavior of the API or breaking existing code:

2008 spec discussions: Civic location

• If the civic address were a part of the spec, the web developer will not have to create their own lat/long to civic address lookup.
• As far as I can tell, of the use cases for geolocation given in the spec, only the third ("Automatic form-filling") involves an address, and frankly I'm not convinced that that is a realistic use case.

W3C location APIs

• Geolocation WG
• 2008: Geolocation API
• 2015: Geofencing API
• Device & Sensors WG
• 2018: Geolocation Sensor API
• Current proposals
• <geolocation> element
• Approximate geolocation

Geofencing API

Goal: Background notifications when entering or leaving geographic regions.

Abandoned in 2017

Geofencing API

A geofence event can receive location information without revealing the user's precise location.

includePosition: Include the current position in the geofence event

Geolocation Sensor API

Goal: Geolocation API with better ergonomics and consistency.

• Built on Generic Sensor API
• Integration with Permissions API
• Events and promises instead of callbacks
• No support for caching or timeouts
• Configurable update frequency

Geolocation Sensor API

Geolocation Sensor defers privacy considerations to the Generic Sensor spec, with a TODO to add geolocation-specific mitigations.

​

​

Generic Sensor lists location tracking under privacy threats, but there are no considerations for sensors that have location tracking as an intended use.

<geolocation> element

Goal: Make permissions more accessible, more secure, and more user friendly.

• Reduce permission spam
• Recover from "regret" scenarios

Try in Chrome M134 or later: chrome://flags#permission-element�Demo: https://permission.site/pepc

<geolocation> element

• PEPC privacy considerations:
• Extreme care needs to be taken to ensure that information exposed by the <permission> element is limited to what a site needs to know. Information that can already be determined (for example via the Permissions API) is fine to be exposed via the <permission> element. Other sensitive information should not be.
• One-shot use case:
• watch=false vs getCurrentPosition
• User interaction is required to reuse a one-shot <geolocation> element
• Autolocate use case:
• getCurrentPosition/watchPosition are always "autolocate"
• The user agent can choose how to handle autolocate requests (different UI, for instance)

Try in Chrome M134 or later: chrome://flags#permission-element�Demo: https://permission.site/pepc

Approximate geolocation

Goal: Reduce risks associated with sharing precise location information.

• Sites can request approximate location when precision is not needed
• Users can downgrade permission requests (precise → approximate)

Try in Chrome M140 or later: chrome://flags#approximate-geolocation-permission

Approximate geolocation

• Most location providers already support obfuscation
• Core Location (macOS, iOS): kCLLocationAccuracyReduced
• Windows.Devices.Geolocation: AllowFallbackToConsentlessPositions
• LocationManager (Android): Criteria.ACCURACY_COARSE
• FusedLocationProviderClient (Android): GRANULARITY_COARSE
• Geoclue: CITY
• Not possible to enforce privacy constraints
• Minimum/maximum uncertainty
• Update frequency
• Coarsening algorithm
• Precise location is still exposed to third parties
• Not effective against a resourceful adversary

Android location prompt

iOS app location settings

Try in Chrome M140 or later: chrome://flags#approximate-geolocation-permission

Future work?

• Location APIs that don't expose the user's coordinates
• Civic location API
• Location-based chooser API
• Let's say that the site publishes a list of all of its stores and their locations. You could pick a store from that list that suited your needs. This might use geolocation to find the closest, without revealing anything other than the final choice. In any case, you reveal which stores you are interested in when you check stock levels for some stores and not others. An API for that sort of thing would be difficult to build in a way that didn't turn into a triangulation service, but I suspect that this is far closer to what people are looking for in many cases.
• Location sources without a third party
• GNSS
• IP geolocation database
• Network geolocation database

GeoPriv Scenario 7 - On-device mobile location

Open discussion

​