Connecticut bans the sale of precise geolocation data as Public Act 26-64 takes effect

The location provision reaches further into application code than anything else in the act ^[4]. Joseph Sides, writing on dev.to, describes the work as an inventory: every location field, the precision attached to it, where it is sent, which partners receive it, and whether an analytics or advertising arrangement could qualify as a sale ^[5]. "For developers, the responsible response is not limited to changing a privacy-policy sentence," he wrote ^[14]. I agree with him.

The policy edit is the only part of this job that ships without a deploy. The inventory needs two attributes per field. Precision decides whether a value falls in the protected category. The recipient decides whether a transfer might be a sale. A precise value that never leaves the backend and a coarse one sent to an ad partner are different problems with different fixes. Sides points to the enacted text of Public Act 26-64 for the controlling details, with the Attorney General's September 16 guidance describing the obligations that begin October 1 ^[3]. The precision cutoff and the definition of a sale have to come from that text.

In my view the field list should be built from what leaves the system: SDK settings and outbound requests. A schema review finds the columns the team created. It will not find a coordinate that a third-party library collects and sends by itself.

Surveillance pricing is harder to find in code. According to the Attorney General, businesses that use personal data to set different prices or wages must follow new limitations and disclosures ^[6]. Sides lists the ordinary parts such a system can be built from: device identifiers, purchase histories, inferred interests, location patterns, loyalty records and risk scores ^[13]. His test is whether a product team can explain which data affects an offer, whether the system changes a price or wage, and what notice the consumer sees before the decision matters ^[15]. For a model that sets offers, the first question means tracing each input feature back to its source table and keeping that record for each decision.

For records a team treats as public, Sides wants the provenance stored with the data. Each record would name its source, the reason it qualifies for an exception, the date it was collected, the uses attached to it and the systems that received copies ^[12]. On new ingestion, adding those columns is a schema migration. I'd expect most of the cost to be in the backfill, because the downstream copies were made before anyone recorded where they went.