Chrome for Android adds approximate location sharing: what it does and doesn't protect

Google this week added approximate location sharing to Chrome on Android, giving users a third option when websites request their location: a general area instead of precise coordinates. For use cases that need only regional context, that removes a friction point that has pushed users toward over-sharing for years.

The gain is meaningful. The scope is specific. Approximate location changes what Chrome hands to websites upfront. It has no bearing on what those websites do with that data once they have it.

What users can now choose, and when each option makes sense

When a website requests location access in Chrome on Android, users now see three choices: share precise location, share approximate location, or deny access entirely, per Google's announcement published yesterday.

Google draws a sensible line between use cases. Placing a delivery order, running turn-by-turn navigation, or finding the nearest ATM requires a specific address. Checking a local weather forecast or reading regional news does not, per the same announcement. The implication is that for a substantial portion of everyday web browsing, users have been handing over more data than the task ever required.

One gap in the rollout: Google has not disclosed what radius its "approximate" option actually covers. State privacy legislation offers some context on what the stakes look like in practice. The Massachusetts location privacy bill sets a protected radius of roughly 1,850 feet, while California's proposed threshold extends to five miles, according to EFF's analysis of state location surveillance legislation from last year. Chrome's implementation sits somewhere in that legislative landscape, and where it lands shapes how much exposure the new option actually reduces.

Google says users will not lose functionality by choosing approximate location, pointing to navigation as the case where precision remains available and necessary, per the announcement. What the announcement does not describe is any mechanism to prevent sites from degrading service or repeatedly prompting users to share more precise data. That gap is relevant to how the feature plays out in practice.

Why this fits a broader Chrome privacy pattern, and what that pattern does and doesn't guarantee

Approximate location is the newest layer in a multi-year shift by Google toward permissions that are more limited in scope and easier to revoke.

In late 2024, Chrome added one-time camera and microphone permissions on both Android and desktop: once a user leaves a site, the access is automatically revoked and cannot resume without another explicit grant, Google announced at the time. Site-level permission toggles for location and camera first arrived on Chrome for Android in mid-2021, with broader platform rollout following. The direction is consistent: Android leads, desktop follows, granularity increases over time.

Each iteration has narrowed the default exposure. One-time permissions meant a site couldn't hold onto camera or microphone access after a session ended. Site-level toggles let users review and cut permissions without digging through browser settings. Approximate location extends that logic to coordinates, letting users share enough for a service to function without disclosing a street address.

The most consequential near-term development may not be the user-facing toggle at all. Google is planning developer APIs that would let websites explicitly declare whether they are requesting approximate or precise location, rather than defaulting to maximum precision and leaving users to downgrade manually, per the announcement. If those APIs ship as described, they could shift the default at the source: sites would specify what they need upfront, rather than asking for everything and relying on users to dial it back.

What those APIs will require developers to disclose, and whether any justification must be shown to users, remains unspecified. The pattern establishes that Chrome is capable of this kind of incremental tightening. It does not establish that any of these front-end controls extend into what happens to data after collection.

Where the feature stops: consent isn't the same as protection

Approximate location solves one specific problem. The old binary forced users to share precise coordinates or get nothing, which pushed people toward over-sharing just to access routine functionality. That specific failure is addressed.

Everything downstream remains unchanged. How long a site retains approximate location data, whether it shares that data with third parties, and whether approximate location combined with a device fingerprint or browsing history can still produce a detailed profile are all outside the scope of this feature. The permission dialog governs what leaves the device. It says nothing about what happens next.

Privacy advocates have pushed for data minimization as the operative standard: companies should collect no more precise location data than strictly necessary for the service a user actually requested, and must delete it once that purpose is complete, according to EFF's analysis of model location privacy legislation. Under that framework, no company should sell, rent, trade, or lease location data at all. The Massachusetts bill language EFF cites goes further, restricting covered entities to collecting or processing location data only for a "permissible purpose," defined narrowly as delivering a product or service the user asked for, fulfilling an order, complying with law, or responding to an imminent threat to life. Chrome's permission dialog has no mechanism to enforce any of that.

There is also a coercion dimension. Model bill language analyzed by EFF would prohibit companies from refusing service, charging different prices, or providing a degraded experience because a user declined to share precise location, unless that precision is genuinely essential to the service in question, per the same analysis. Chrome gives users a way to share less. It does not protect them from sites that treat approximate location as grounds for a worse experience.

The consent standard EFF supports sets a high bar regardless of what any browser ships: consent must be freely given, specific, informed, and unambiguous, with no dark patterns involved, as described in the Massachusetts bill language cited in EFF's analysis. A permission dialog, even a well-designed one, is a necessary condition for that standard. It is not a sufficient one.

What comes next, and what it depends on

Desktop Chrome support is coming in the months ahead, which will extend approximate location to a much larger share of browsing sessions, per Google. That rollout matters primarily because desktop browsing represents a different usage pattern: longer sessions, more site interactions per session, and more opportunities for persistent permissions to accumulate.

The more significant test is the developer API timeline. If sites use those APIs to request only the precision they genuinely need, the feature becomes structurally different from what launched this week. Right now, the default is still maximum precision: users choose to share less. With the planned APIs, sites could declare their requirements upfront, and browsers could enforce them. That would flip the default in a meaningful way.

Whether the web ecosystem moves in that direction by choice, or requires legislative pressure to get there, is the open question. Several states have active location privacy bills working through legislatures, and the model language EFF has analyzed would impose data minimization obligations that no browser permission dialog currently enforces. If those bills pass, the gap between Chrome's front-end controls and what sites can do with collected data starts to close through law rather than product design.

For Android users today, the practical picture is straightforward. For weather, news, and other services that function on city- or area-level context, approximate location removes the need to hand over a street address. For navigation, delivery, and anything that depends on an exact destination, precise location remains available. The feature does what it says. The question of what happens after data is collected is a different problem, and one that no browser release has yet answered.