The Law Is Narrow, But The Signal Is Not
On April 13, 2026, Virginia approved S.B. 338, a bill amending the Virginia Consumer Data Protection Act. The operative idea is simple: a controller of personal data may not sell or offer for sale precise geolocation data concerning a consumer. The law took effect on July 1, 2026. That is not a vague future compliance cloud. It is already here. ([legiscan.com](https://legiscan.com/VA/bill/SB338/2026))
The bill defines precise geolocation data as technology-derived information that directly identifies the specific location of a person within a radius of 1,750 feet. That matters because this is not only about a blue dot sitting exactly on top of someone’s house. It can include location data accurate enough to reveal a person’s habits, workplace, school drop-off, clinic visit, place of worship, protest attendance, or regular late-night taco weakness. One of those is less sensitive than the others, but still nobody asked for it to become a spreadsheet with a price tag. ([regulatoryoversight.com](https://www.regulatoryoversight.com/2026/04/virginia-becomes-third-state-to-ban-sale-of-consumers-precise-geolocation-data/))
Virginia is not alone. Maryland and Oregon have enacted similar restrictions, and privacy lawyers are already treating this as part of a broader state-level pattern around location data. Virginia’s version is also worth reading carefully because its definition of “sale” is narrower than some other state privacy laws: it focuses on monetary consideration, while Maryland and Oregon use broader language that can include other valuable consideration. That distinction sounds boring until your business depends on SDK swaps, enrichment deals, ad-tech integrations, or “free” data partnerships. Then boring becomes expensive. ([regulatoryoversight.com](https://www.regulatoryoversight.com/2026/04/virginia-becomes-third-state-to-ban-sale-of-consumers-precise-geolocation-data/))
Why Location Data Is Different From Ordinary Tracking
Most privacy arguments get flattened into the same tired exchange: users want free apps, companies need revenue, everyone clicks “agree,” and the machine keeps eating. Location data breaks that neat little bargain because it is not just preference data. It is behavioral evidence.
A list of articles you read can suggest what you think. A location trail can show where you sleep, who you meet, where your children go, when you leave town, which doctor you visit, and whether you attend a union meeting or political event. That is why location data is uniquely hard to anonymize in the real world. Even if a dataset does not contain a name, recurring movement patterns can make a person obvious. Home at night plus workplace by day is not exactly a cryptographic puzzle.
This is also why “we only share aggregated data” has become one of the great load-bearing phrases of modern privacy theater. Aggregation can be useful, but it is not magic. If a vendor, broker, or partner can slice the data finely enough, or combine it with other datasets, the privacy risk comes crawling back through the vents.
Notavello has covered how platforms can recognize users even when they believe they are logged out in Why YouTube Still Knows You, Even When You're Logged Out. Location data lives in the same family of uncomfortable truths: identity is not always a username. Sometimes it is a pattern.
The App Developer Problem: Your SDKs May Be The Business Model
The uncomfortable part for developers is that location sharing often does not begin with a villain in a hoodie. It begins with a normal product decision. Add analytics. Add attribution. Add crash reporting. Add fraud detection. Add maps. Add a weather feature. Add an ad SDK because revenue is nice and servers are not paid for with vibes.
Each integration may have a plausible reason to exist. The risk is the total supply chain. A mobile app can collect location for a user-facing feature, pass device or event data through several vendors, and quietly create downstream uses that the product team has never mapped. If the app asks for location permission, but the real monetization path includes data flowing into an advertising, enrichment, or brokerage ecosystem, the privacy policy is not the only thing that needs attention. The architecture does too.
For teams building or maintaining apps, the first practical question is not “Are we selling location data?” The first question is “Do we actually know where location data goes?” If the answer requires three Slack threads and a former employee’s memory, that is not governance. That is archaeology.
A basic location-data review should answer these questions:
- What location signals are collected? GPS, Wi-Fi, Bluetooth, cell tower data, IP-derived location, address input, check-ins, delivery coordinates, background location, or inferred place visits.
- Why is each signal collected? Navigation, safety, fraud prevention, personalization, analytics, ads, compliance, logistics, or “someone added it in 2021 and nobody knows.”
- Where does it go? Internal databases, analytics platforms, cloud logs, data warehouses, ad networks, attribution vendors, customer support tools, map providers, or exported CSVs that definitely should not exist.
- Who can access it? Employees, contractors, vendors, subprocessors, advertisers, law enforcement response teams, or customers in dashboards.
- How long is it kept? Raw location history should not become immortal just because storage is cheap.
Consent Is Not A Force Field
For years, the default compliance move was to ask for consent, bury the details in a policy, and hope nobody read the third paragraph under “Information We Share With Partners.” This approach is getting weaker, especially for sensitive data.
Virginia’s move is important because it targets the sale of precise geolocation data rather than merely requiring another opt-out screen. That is the policy shift: some data practices are becoming less acceptable even when companies can technically manufacture consent around them. A checkbox does not turn a risky data market into a good idea.
This is especially relevant for AI products and agentic tools that run on top of apps, browsers, mobile devices, or workplace systems. AI should not be treated as a privacy laundering machine. If an AI feature receives location-bearing records, summarizes location histories, enriches customer profiles, or routes data through third-party model providers, the team still needs to understand the underlying data rights and restrictions. Calling something “AI-powered insights” does not make the input data less sensitive. It just gives the sensitive data a blazer.
For users, the lesson is simpler: location permission should be rare. Weather apps do not always need precise background location. Coupon apps do not need to know every pharmacy visit. Flashlight apps needing location was always a confession, not a feature.
What Product Teams Should Change Now
The useful response is not panic. It is inventory, minimization, and boring operational control. Boring is good. Boring keeps lawyers from discovering your architecture in a deposition.
Start with a location data map. Document every place where location data is collected, transformed, stored, shared, or sold. Include raw logs, observability tools, data warehouses, customer dashboards, vendor APIs, and machine learning pipelines. If location data can land there, put it on the map.
Then separate location data by sensitivity. A city-level estimate from IP address is not the same as continuous GPS. A one-time delivery coordinate is not the same as a year of background movement history. A fraud signal used internally is not the same as a feed shared with ad partners. Treating all of it as one blob called “location” is how teams miss the thing regulators actually care about.
Next, cut collection. If the feature works with coarse location, do not collect precise location. If the feature works only while the app is open, do not request background access. If the app only needs a current point, do not store a trail. If a vendor only needs a derived region, do not send coordinates. This is privacy minimization, but it is also product hygiene. Less data means fewer breach headaches, fewer vendor surprises, and fewer awkward all-hands meetings.
Finally, review contracts and SDK settings. Many teams assume vendor defaults are sane. That is sweet. Check whether SDKs collect location automatically, whether precise location is enabled by default, whether data is used for the vendor’s own purposes, whether resale is prohibited, and whether deletion requests propagate. The phrase “we do not sell personal information” should be backed by technical and contractual reality, not vibes in a privacy-policy generator.
What Users Can Actually Do
Users cannot audit every data broker, and pretending otherwise is just victim-blaming with a settings menu. But there are still practical moves worth making.
- Use approximate location when possible. Modern mobile operating systems often let users provide coarse location instead of precise GPS.
- Deny background location by default. Very few apps need to know where you are when you are not using them.
- Delete apps that ask for location without a clear reason. If the reason is not obvious, assume the reason is not for your benefit.
- Reset ad IDs periodically. It will not make you invisible, but it can reduce some long-running tracking linkages.
- Prefer paid or privacy-respecting services for sensitive use cases. Free is not always bad. But free plus location plus ads deserves suspicion.
The larger fix, though, has to be structural. Users should not need a forensic lab to understand whether a jogging app, parking app, or coupon app is feeding a location-data economy. Laws like Virginia’s matter because they move some burden back onto companies, where it belongs.
The Direction Is Clear
Virginia’s law is not the end of location-data commerce. It is not a national privacy law. It does not solve every loophole, and companies will argue over definitions because that is what companies with counsel do. But the direction is obvious: precise location data is becoming a regulated liability, not just a monetizable exhaust stream.
For developers, the safest pattern is now straightforward: collect less, store less, share less, and never let a third-party SDK become the secret product manager. If location is essential, make the use visible and narrow. If it is not essential, kill it. The best privacy feature is still the database row that never existed.
For everyone else, Virginia’s ban is a reminder that the mobile app economy has been far too casual about the most intimate sensor in your pocket. Your phone does not merely know where it is. It knows where you are. That distinction is finally getting harder to ignore.