DEV Community: Joseph Sides

California’s New Seven-Day Rule Changes How Protected Health-Data Requests Are Handled

Joseph Sides — Mon, 05 Oct 2026 13:12:53 +0000

California has added a new checkpoint between certain legal demands and the production of highly sensitive health information. The change is not a proposal awaiting a vote. Governor Gavin Newsom signed Assembly Bill 1930 on September 26, 2026, and it was filed as Chapter 468 the same day.

The new law addresses subpoenas, discovery demands, and other formal requests tied to investigations involving abortion or gender-affirming health care that California treats as legally protected. For developers, compliance teams, and vendors that maintain health-related data, the practical lesson is immediate: responding to a legal request can no longer be treated as a simple export-and-send process.

What AB 1930 actually requires

AB 1930 applies to a person or entity that is located, headquartered, incorporated, or otherwise doing business in California. When that person or entity receives a subpoena, discovery request, or other request that is part of a civil, criminal, regulatory, or legislative investigation concerning protected abortion or gender-affirming health care, it generally must notify the California Attorney General at least seven business days before producing responsive records.

The notice must include a copy of the demand. The receiving organization may redact identifying or confidential information about specific patients, individuals, or providers when confidentiality or applicable law requires it. Unless an exception applies, the organization also must wait at least seven business days after giving notice before producing the records.

The Governor’s September 26 announcement describes the measure as part of a six-bill package designed to strengthen protections for private information. The enacted text matters more than the summary because it defines the precise triggers, exemptions, deadlines, and penalties.

AB 1930 is a chaptered law, not a bill that merely passed one chamber or cleared a committee. Because it is a non-urgency statute enacted during a regular session and contains no special effective-date provision, California’s ordinary constitutional rule makes it effective January 1, 2027. Article IV, Section 8 of the California Constitution supplies that general effective-date rule.

The seven-day rule is not an absolute block

The statute does not automatically invalidate every demand for protected health information. It creates notice and timing obligations, along with authority for the Attorney General to respond.

The seven-business-day process does not apply when the demand is ordered by a court with jurisdiction, issued by a California state or local agency, or accompanied by a qualifying attestation. An attestation may state, for example, that the information will not be used to investigate or impose liability for care that is lawful in California, or that the demand concerns conduct unlawful under identified California law. The exception also covers situations in which references to abortion or gender-affirming services are merely incidental to the investigation.

Federal timing can also change the process. If federal law or another federal obligation requires a faster response, notice to the Attorney General may be given contemporaneously with production. The responding organization must make best efforts to deliver the records on the date the federal obligation requires.

These distinctions are important. A request’s label is not enough. A team must examine who issued it, what investigation it supports, which records it seeks, whether an attestation is present, and whether another binding deadline controls.

Why this becomes an engineering workflow

Many legal-response systems begin with a ticket and end with a database export. AB 1930 requires more structure. The intake form should capture the issuing authority, jurisdiction, service date, response deadline, investigative purpose, data categories, relevant individuals, and any attestation. The workflow then needs a decision point for California coverage and the statute’s exemptions before production is enabled.

That decision cannot be reliable without a usable data map. An organization should know which systems contain appointment details, messages, search activity, location signals, billing information, clinical records, referrals, and support logs. It should also know which processors, cloud vendors, and analytics services may hold copies. If the company cannot locate the data quickly, the seven-business-day buffer can disappear while teams are still identifying systems.

Product architecture matters as well. Data about protected care should not be mixed into broad exports when narrower retrieval is possible. Access to production tools should be role-based, and every search, view, redaction, approval, and disclosure should create an auditable record. A litigation hold must prevent destruction without turning into indefinite retention of unrelated information.

The safest operational design includes separate gates for identification, legal review, Attorney General notice, individual-confidentiality review, executive approval, and production. A deadline service should calculate business days correctly and record why an exception shortened or removed the waiting period. No engineer should be asked to decide the statute’s applicability alone, but engineers must build the controls that let the legal and privacy teams make and enforce that decision.

Enforcement raises the cost of shortcuts

The California Attorney General may intervene in certain civil actions brought to resist a demand, pursue a person or entity that attaches a false attestation, and seek injunctions or other available remedies. A false attestation may carry a $15,000 civil penalty. An intentional, knowing, willful, or reckless violation may result in a penalty of up to $10,000 for a first violation and up to $15,000 for each subsequent violation.

For consumers, the law adds time and public oversight, but it should not be mistaken for a promise that records can never be produced. The Attorney General may attempt to notify the person connected to the protected care, yet the statute does not guarantee that every individual will receive notice before every disclosure. Existing federal and state confidentiality rules may add other protections depending on the data and organization involved.

The larger lesson is that sensitive-data protection depends on process as much as policy. By January 1, 2027, covered organizations should be able to recognize a qualifying demand, pause production, notify the proper authority, document the analysis, and disclose no more than the law requires. A privacy program that begins only after a database export has been created is already too late.

The Education Department’s Instructure Letter Turns FERPA Into an Engineering Checklist

Joseph Sides — Sun, 04 Oct 2026 13:00:51 +0000

The Family Educational Rights and Privacy Act is often summarized as a consent rule for schools. That description is incomplete. A 2026 letter from the U.S. Department of Education shows how quickly FERPA questions can become questions about access controls, patching, incident response, vendor oversight, and evidence.

On May 12, 2026, the Department’s Student Privacy Policy Office sent a four-page letter to Instructure, the company behind the Canvas learning-management platform. The letter followed cybersecurity incidents affecting customers and others. It stated that the incidents resulted in unauthorized access to student education records and that FERPA violations “likely occurred.” It requested a written response by May 25 describing the incidents, the number of affected U.S. K-12 and higher-education students, the types of information exposed, corrective actions, and communications with schools, parents, and students.

That language matters, but so does the procedural status. The letter was a request for information under the Department’s FERPA enforcement authority. It was not a final adjudication, civil penalty, enacted amendment, or scheduled congressional vote. Its significance comes from the evidence the Department requested and the compliance expectations that evidence reveals.

FERPA follows education records into outsourced systems

FERPA is an existing federal law implemented through 34 C.F.R. Part 99. It applies to educational agencies and institutions receiving funds under programs administered by the Department of Education. It gives parents rights involving their children’s education records; those rights generally transfer to the student when the student turns 18 or attends a postsecondary institution.

The law generally requires signed and dated consent before personally identifiable information from education records is disclosed, unless an exception applies. Consent must identify the records, the purpose, and the party or class of parties receiving them. FERPA also gives parents and eligible students rights to inspect records and seek amendment of information they believe is inaccurate, misleading, or in violation of privacy rights.

Schools regularly rely on outside platforms for functions they once performed internally. FERPA’s “school official” exception can permit disclosure to a contractor, consultant, volunteer, or other outside party without prior consent, but it is not a blank check. The Department’s school-official guidance says the outside party must perform a function for which the school would otherwise use employees, remain under the school’s direct control regarding the use and maintenance of the records, follow limits on use and redisclosure, and meet the criteria in the school’s annual FERPA notice.

For a product team, “direct control” cannot exist only in a contract. Roles, permissions, retention, exports, support access, model-training pipelines, and subprocessors must align with the educational purpose for which the data was disclosed.

The letter asked for evidence, not promises

The most instructive part of the Instructure letter is Exhibit A. The Department requested governance documents such as an information-security policy, risk assessments, a risk register, data-classification and handling rules, access-control policies, and vendor-risk procedures. It also requested operational evidence: incident-response plans and testing logs, periodic user-access reviews, patch records, change-management logs, and security-training records.

The technical list continued with network diagrams, asset inventories, configuration standards, penetration-test results, and independent assurance materials such as SOC 2 Type II reports or ISO 27001 certification. The Department also identified AI-use policies and remote-work security as key focus areas for 2026.

This is a useful distinction for every privacy program. A written policy describes intended behavior. Logs, inventories, reviews, test results, and remediation records show whether the organization followed that policy. When sensitive records are exposed, a regulator will not be satisfied by a general statement that security is taken seriously.

Developers should translate those categories into product requirements. Every service should have an owner and a place in the asset inventory. Administrative access should be narrow and reviewable. Security-relevant configuration changes should leave an audit trail. Patches should have severity-based deadlines and documented exceptions. Incident exercises should test who can identify affected students, schools, data categories, and downstream recipients during a crisis.

Classroom convenience does not erase approval and purpose limits

The Department separately advises teachers to check whether an online tool is approved by their school or district before using it. Its guidance on classroom applications says a service receiving education-record information under the school-official exception must remain under the school’s direct control, use data consistently with the annual FERPA notice, and avoid unauthorized use or redisclosure.

That should shape onboarding design. A teacher’s ability to create an account or connect a class roster does not prove that the district approved the product. An OAuth consent screen does not answer whether the school has a permitted FERPA basis for the disclosure. A privacy policy does not create direct control. Ed-tech services need deployment paths that support district review, scoped permissions, documented purposes, contractual restrictions, and reliable deletion or return of records when the service ends.

AI features create another risk of purpose drift. Student submissions collected to provide feedback should not silently become training data for a separate general-purpose model. If an AI feature uses education records, the organization needs to identify the authorized educational purpose, minimize the inputs, control who can retrieve prompts and outputs, and prevent secondary use that exceeds the disclosure basis.

What parents, students, and schools can do

Parents and eligible students can request the school’s annual FERPA notice, ask to inspect education records, and seek correction through the school’s established process. They should also read the school’s directory-information notice, which must identify the designated categories, explain the right to refuse disclosure, and provide a deadline for opting out. Directory information is not a universal license to disclose every student detail.

When a breach occurs, affected people should ask which records were involved, which organization maintained them, who gained access, what the information was used for, and what corrective measures are underway. FERPA is only one part of the analysis; state student-privacy statutes, breach-notification laws, contracts, and other federal rules may also apply.

For schools and vendors, the Instructure letter offers a clear operational lesson: privacy compliance is not complete when a policy is published or a contract is signed. The organization must be able to show what data it holds, why it holds it, who can reach it, what changed, what failed, and what was done in response.

The DPPA Protects DMV Records—Not Every Byte Your Car Creates

Joseph Sides — Sat, 03 Oct 2026 12:46:53 +0000

A driver’s license application may contain a name, home address, telephone number, photograph, identification number, and sensitive medical details. That is enough information to locate a person, impersonate them, or build a detailed profile. Federal law recognizes that risk through the Driver’s Privacy Protection Act, usually called the DPPA.

The DPPA is an existing federal law, not a pending bill or a newly announced rule. It appears in 18 U.S.C. §§ 2721–2725. Its basic structure is important for consumers and developers because it begins with a restriction and then creates specific permitted uses. But its name can also create a false sense of coverage. The statute is about personal information obtained from state motor-vehicle records. It is not a general privacy law for everything that happens inside or around a car.

The source of the data matters

Section 2721 generally bars a state department of motor vehicles, its officers and contractors from knowingly disclosing personal information obtained in connection with a motor-vehicle record, except as the statute permits. The law also regulates recipients: Section 2722 makes it unlawful for a person knowingly to obtain or disclose personal information from a motor-vehicle record for a use the law does not permit.

That repeated phrase—“from a motor vehicle record”—does real work. A name and address pulled from a DMV database may fall within the DPPA. The same facts collected independently through a dealership form, a navigation app, a connected-car account, or a public source may raise other legal and contractual questions, but they do not automatically become DPPA-protected merely because they relate to a driver.

This is why data provenance is not clerical trivia. An organization cannot determine its obligations by looking only at the field name. It needs to know where the information originated, why it was obtained, and whether the proposed use matches a permitted purpose.

What the statute calls personal information

Section 2725 defines “personal information” to include information that identifies an individual, such as a photograph, Social Security number, driver identification number, name, address other than the five-digit ZIP code, telephone number, and medical or disability information. It separately defines “highly restricted personal information” to include a photograph or image, Social Security number, and medical or disability information.

The definition also excludes information about vehicular accidents, driving violations, and a driver’s status. That does not mean those records are privacy-free or available for any imaginable use. State public-records rules and other laws may still govern access. It does mean the DPPA’s defined category is narrower than many people assume. California’s DMV makes the distinction visible in its own explanation of how information is protected or disclosed.

Highly restricted information receives tighter treatment. Section 2721 generally requires express consent for disclosure of that category, subject to a smaller set of statutory exceptions. A product team should not flatten photographs, Social Security numbers, medical information, names, and ZIP codes into one undifferentiated “DMV data” bucket. The law itself does not treat them identically.

Permitted access is not permission for everything

The DPPA contains a detailed list of permitted uses. They include certain government functions, motor-vehicle and driver-safety matters, insurance activities, licensed private investigative work for a permitted purpose, research subject to safeguards, and use in connection with civil, criminal, administrative, or arbitral proceedings. Some disclosures depend on consent. The exact language and conditions in Section 2721 matter more than a broad internal label such as “fraud,” “legal,” or “business need.”

This has a practical consequence: lawful acquisition does not create an unlimited license to reuse the information. A company may receive DMV-sourced data for one authorized workflow and later be tempted to send it into analytics, advertising, model training, identity resolution, or lead generation. The second use needs its own legal basis. A vendor’s access to the data also does not erase the receiving organization’s responsibility to understand the permitted purpose and any redisclosure limits.

For developers, a good implementation should preserve the authorized purpose next to the data, not only in a contract stored somewhere else. Access controls should reflect that purpose. Audit logs should record who accessed the record, when, and for which workflow. Retention rules should prevent a narrowly obtained dataset from quietly becoming a permanent general-purpose asset. Downstream exports should carry restrictions with them.

The law has individual remedies

The DPPA is not only a policy instruction to state agencies. Section 2724 allows an individual to bring a federal civil action against a person who knowingly obtains, discloses, or uses personal information from a motor-vehicle record for an impermissible purpose. The statute lists actual damages, with liquidated damages of not less than $2,500; punitive damages upon proof of willful or reckless disregard of the law; reasonable attorneys’ fees and litigation costs; and appropriate preliminary or equitable relief as possible remedies.

That language is another reason to avoid treating purpose as a checkbox. The operational question is not simply whether a company once had access. It is whether each obtainment, disclosure, and use fits the law.

Consumers who suspect misuse should preserve the notice, communication, lookup result, or other evidence showing how the information appeared and who used it. They can also request information from the relevant state DMV about record-access procedures and applicable state protections. A DPPA claim is fact-specific, and the source of the information often becomes a central question.

A narrow law still deserves careful engineering

The DPPA fills an important gap by restricting access to identifying information that people must provide to state motor-vehicle agencies. It does not replace comprehensive privacy governance. Telemetry, precise location, microphone recordings, diagnostic data, dealership records, financing information, insurance-app data, and infotainment contacts may sit outside the DPPA depending on how they were collected and used.

The right product lesson is neither “car data is protected” nor “car data is unregulated.” The better lesson is to map each data stream to its source, purpose, recipients, retention period, and governing rules. Privacy choices become meaningful only when the system behind them can answer those questions.

A Federal Data-Matching Program Starts November 2—What the Privacy Act Requires

Joseph Sides — Fri, 02 Oct 2026 12:50:55 +0000

The Department of the Interior published a new federal data-matching notice today, October 2, 2026. The program will compare records from 20 Interior programs with the Treasury Department’s Do Not Pay Working System to verify eligibility, prevent improper payments, and support recovery activity. The notice says comments are due November 2, 2026, and the program will be effective from November 2, 2026 through September 10, 2029.

Those dates should be described accurately. This is not a bill waiting for a vote, and it is not a proposed nationwide consumer privacy law. It is a formal matching-program notice issued under the existing Privacy Act of 1974 and related federal authorities. The comment deadline and the program’s effective date happen to fall on the same day, but they serve different purposes.

What the government plans to compare

The program involves Interior records used by the Bureau of Indian Affairs and the U.S. Fish and Wildlife Service. The listed programs range from grants and employment assistance to child care, energy assistance, law-enforcement support, and conservation. Interior will compare relevant records with Treasury’s Do Not Pay system before making certain payments or awards.

The data is not trivial. According to the notice, Interior may disclose a Taxpayer Identification Number, which can include a Social Security number, Employer Identification Number, or Individual Taxpayer Identification Number. The comparison may also involve a person’s or organization’s name, physical address, bank account number, and routing number. Records returned from Do Not Pay can identify a potential match and the database or source in which it appeared.

That combination makes accuracy more than a technical preference. A mistaken match can affect a benefit, grant, award, payment, vendor, or sole proprietor. The notice says an Interior program will independently verify a potential match before taking action that could affect a person or organization. That safeguard is essential because a matching engine identifies candidates; it does not establish that two records necessarily concern the same person or prove ineligibility by itself.

The Privacy Act is about systems, not every database

The current text of 5 U.S.C. § 552a defines a “system of records” as a group of agency-controlled records from which information is retrieved by a person’s name or another assigned identifier. It also defines a matching program to include certain computerized comparisons used to establish or verify eligibility for federal benefits, ensure continuing compliance, or recoup payments and debts.

The law does not function like a universal privacy statute covering every private company. It generally governs federal agencies and qualifying systems of records, with specific definitions, exceptions, and exemptions. The statute’s definition of “individual” also matters: it refers to a U.S. citizen or a person lawfully admitted for permanent residence. Consumers should not assume that every database, every person, or every private-sector use falls within the same framework.

Within its scope, however, the Privacy Act creates meaningful structure. Agencies generally may not disclose a covered record without the individual’s written request or consent unless a statutory exception applies. They must publish notices describing systems of records, including categories of people and records, routine uses, storage and retention practices, system managers, sources, and procedures for access and correction. The statute also requires agencies to maintain records used in decisions with the accuracy, relevance, timeliness, and completeness reasonably necessary to assure fairness.

A notice is a map of the system

The Federal Register maintains a search page for Privacy Act notices, commonly called Systems of Records Notices or SORNs. These publications are not decorative paperwork. They tell the public what a system is called, why it exists, which people it covers, what information it holds, how it retrieves records, and the circumstances in which information may be disclosed.

For consumers, the notice can be the starting point for understanding whether an agency system may contain information about them and how to seek access or request correction. The Privacy Act includes procedures for individuals to request records and challenge information they believe is inaccurate, irrelevant, untimely, or incomplete, although exemptions can limit access in particular systems and situations.

The new Interior notice also offers a public-comment process. Comments are due November 2 and must identify docket DOI-2026-0199. Anyone using that process should read the submission warning carefully: the notice says comments will be posted publicly without change, including personal information provided. A privacy comment does not need a home address, Social Security number, bank detail, or other unnecessary identifier in the comment text.

What developers should build around a match

For developers and contractors, a matching program should never be reduced to one Boolean field labeled “match.” The system should preserve the source and date of every candidate match, identify which fields produced it, record confidence and ambiguity, and separate automated detection from the human or administrative verification required before adverse action. Common names, outdated addresses, shared bank accounts, formatting differences, and recycled identifiers can all create errors.

Security and minimization matter just as much. The statute directs agencies to maintain only information relevant and necessary to an authorized purpose and to establish administrative, technical, and physical safeguards. Teams should restrict access, encrypt sensitive identifiers, avoid unnecessary copies, log disclosures, apply retention schedules, and make correction workflows capable of updating downstream records rather than only the original table.

The practical lesson from today’s notice is larger than one Interior program. Government data matching can protect public funds, but it also concentrates highly sensitive information and can shape decisions about real people. Responsible implementation requires clear authority, public notice, narrowly defined data, independent verification, meaningful access and correction, and evidence that the system works as described. The Privacy Act was enacted more than fifty years ago, yet its core question remains modern: when a database influences someone’s rights or benefits, can the institution explain the data, the decision, and the path to correct a mistake?

Connecticut’s Privacy Expansion Takes Effect Today

Joseph Sides — Thu, 01 Oct 2026 12:30:20 +0000

October 1, 2026 is an implementation date, not a prediction, for a broad set of Connecticut privacy requirements. Public Act 26-64 was enacted in May and many of its provisions take effect today. The law expands Connecticut’s privacy framework across precise location data, surveillance pricing, facial recognition, direct-to-consumer genetic testing, public-record data, and data brokers.

That distinction matters. This is not a proposal awaiting a committee hearing, a bill that passed only one chamber, or a vote advertised for a future calendar. The Connecticut Attorney General’s September 16 guidance describes rights and obligations that begin October 1. The enacted text of Public Act 26-64 supplies the controlling details.

One effective date, several different privacy problems

The law addresses practices that can expose people to harm without looking like a traditional data breach. One example is precise geolocation. Connecticut now prohibits the sale of precise geolocation data, a category that can reveal where a person lives, works, worships, seeks health care, or spends time. For developers, the responsible response is not limited to changing a privacy-policy sentence. Teams should identify 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.

The act also regulates surveillance pricing. The Attorney General explains that businesses using personal data to set different prices or wages must follow new limitations and disclosures. This matters because individualized pricing can be built from ordinary-looking technical components: device identifiers, purchase histories, inferred interests, location patterns, loyalty records, or risk scores. A product team should be able to explain which data affects an offer, whether the system changes a price or wage, and what notice the consumer sees before the decision matters.

Facial recognition receives its own transparency requirement. A business using the technology in a physical location must post conspicuous signage and provide a link or QR code leading to a policy that explains the purpose, use, retention, and deletion of the facial data. A small sign at the entrance is therefore only the visible layer of a larger obligation. The policy behind the code must match the system actually deployed, including vendor access, storage periods, and deletion workflows.

Direct-to-consumer genetic testing is another major part of the law. Connecticut’s framework gives consumers stronger consent and property protections for genetic data, including restrictions on disclosure and secondary uses. Genetic information is unusually persistent: a password can be changed, but a genome cannot. It can also reveal information about relatives who never bought the service. Developers working on testing, ancestry, wellness, or research features should separate the consent needed to provide the requested service from permission for research, marketing, or other secondary uses.

“Publicly available” is becoming a narrower shortcut

The law narrows the treatment of publicly available information and expands deletion rights in some circumstances. That change deserves attention from data brokers, enrichment services, people-search products, and machine-learning teams. Information appearing in a government record, on a website, or in a purchased dataset does not automatically mean every later collection and use is outside privacy obligations.

For engineering teams, provenance needs to be more than a database label that says “public.” A useful record should identify the source, the reason the information qualifies for an exception, the date it was collected, the uses attached to it, and the systems that received copies. If a consumer requests deletion, the company needs a method to locate derived profiles and downstream transfers rather than deleting only the most visible row.

Consumers should also understand the limits. Connecticut’s privacy law contains applicability thresholds and exemptions. A new right does not necessarily apply to every organization, every record, or every transaction. The correct question is not simply whether a company holds data about a Connecticut resident, but whether the entity and the processing activity fall within the statute’s scope.

The data-broker calendar is staged

The data-broker provisions begin a longer implementation sequence. The Attorney General states that brokers must register with the Connecticut Department of Consumer Protection by January 1, 2027. The legislature’s official summary of Public Act 26-64 also directs the department to establish an accessible deletion mechanism by July 1, 2028.

Those are different milestones. October 1, 2026 is the effective date for the newly enacted framework and numerous privacy protections. January 1, 2027 is the registration deadline identified by the Attorney General. July 1, 2028 is the deadline for the state’s centralized deletion mechanism. Describing all three as one deadline would hide the work required between them.

A broker preparing for registration should document the categories of personal data it collects, the sources it uses, the customers to whom it provides data, and the process for honoring rights. It should also identify how a centralized deletion request will reach internal databases, derived products, and service providers. Waiting for the state mechanism to go live before mapping those systems would leave too much work for the end.

What responsible implementation looks like

The practical message is that privacy compliance is increasingly an architecture question. Location controls, price-setting logic, facial-recognition notices, genetic-data permissions, public-data provenance, and broker deletion all depend on systems that can explain what they do. A legal review can identify the rules, but software and operations determine whether the promised controls work.

Teams should use today’s date to test facts rather than assumptions: inspect network traffic, trace precise location fields, document pricing inputs, scan physical deployments, separate genetic-data consents, and rehearse deletion across copies and vendors. Consumers, meanwhile, should look for meaningful notices and exercise available access or deletion rights when a covered business’s practices concern them.

Connecticut’s new law is broad because modern privacy problems are connected. A location signal can influence a price. A face scan can become a persistent identifier. A public record can feed a commercial profile. A genetic test can create data with consequences far beyond the original transaction. The law’s implementation dates are important, but the more durable lesson is that responsible technology begins with knowing what data a system uses and being able to honor the choices the law gives people.

HIPAA Is Not the Whole Health-Privacy Map

Joseph Sides — Wed, 30 Sep 2026 12:54:28 +0000

“We are not covered by HIPAA” is sometimes treated as the end of a health-privacy review. For many digital products, it should be the beginning. A wellness app, symptom tracker, connected device, medication tool, or reproductive-health platform may sit outside HIPAA and still face federal duties under the Federal Trade Commission Act and the FTC’s Health Breach Notification Rule.

This is not a proposed bill waiting for a vote. It is an existing federal framework. The FTC’s app-focused amendments to the Health Breach Notification Rule have been effective since July 29, 2024. Developers and product leaders should understand what that means before a data-flow decision becomes a notification problem.

HIPAA depends on who holds the data

HIPAA is often described as if it protects every piece of health-related information everywhere. The actual coverage is narrower. The Department of Health and Human Services explains that the HIPAA Rules apply to covered entities and business associates. Covered entities are health plans, health care clearinghouses, and certain health care providers that conduct specified electronic transactions. Business associates perform particular functions or services for covered entities involving protected health information.

That status matters more than the sensitivity of a data point by itself. A diagnosis inside a hospital record may be protected health information under HIPAA. Similar information entered directly into a consumer app may not be, if the app is neither a covered entity nor acting as a business associate. HHS states plainly that an organization outside those categories does not have to comply with the HIPAA Rules.

That does not make the information unregulated, unimportant, or safe to share. It means the analysis must continue under other federal and state rules.

The FTC rule reaches beyond hackers

The FTC’s Health Breach Notification Rule applies to certain vendors of personal health records, related entities, and third-party service providers that are not covered by HIPAA. The 2024 amendments clarified the rule’s application to many health apps, connected devices, and similar technologies.

Coverage can turn on product architecture. FTC guidance explains that a personal health record is an electronic record that can draw health information from multiple sources and is managed, shared, or controlled primarily for the individual. A fitness app that accepts information from the user and has the technical capacity to sync data from a wearable may qualify even when some users never activate the connection. The important question is not whether the product calls itself a medical record. It is what information the product can draw together and how the individual uses it.

The definition of a breach is equally important. Under the FTC’s detailed compliance guidance, a breach can include unauthorized acquisition of unsecured, identifiable health information. It is not limited to ransomware, a stolen password, or an outside attacker. An unauthorized disclosure by the company itself—including sending covered information to a social media or advertising platform without the individual’s authorization—can trigger the rule.

That changes the engineering conversation. A tracking SDK, analytics event, advertising pixel, crash-reporting payload, or customer-support integration may create risk without anyone “breaking into” the system. Teams need to examine what fields are transmitted, what can be inferred from page names or event labels, which identifiers accompany the event, and whether the receiving company may use the information for its own purposes.

The notification clock is real

When the rule applies, affected people generally must be notified without unreasonable delay and no later than 60 calendar days after discovery. A company cannot automatically wait until day 60 if it already has the information needed to provide notice.

The FTC deadline depends on scale. For a breach affecting 500 or more people, the FTC must be notified at the same time as affected individuals, without unreasonable delay and within the 60-day ceiling. For a breach affecting fewer than 500 people, the FTC filing is due within 60 calendar days after the end of that calendar year. If at least 500 residents of one state, the District of Columbia, or a U.S. territory are affected, notice to prominent local media is also required. Individual notice remains required; media notice is not a substitute.

These obligations should shape incident-response design before an incident. A company needs reliable logs, ownership for escalation, a way to identify affected users, and a process for determining when someone in the organization knew—or reasonably should have known—about the event.

Privacy promises create another layer

The FTC Act applies more broadly than the breach rule. The FTC’s health-information guidance says companies must not mislead consumers about how they collect, use, retain, secure, or share health information. It also warns that health information includes more than diagnoses and treatments. Browsing, location, purchase, and app-use data can reveal or support an inference about a person’s health.

The GoodRx enforcement action showed the practical consequences. In 2023, the FTC alleged that GoodRx shared sensitive health information with advertising companies contrary to its privacy promises and failed to provide required breach notifications. The resolution included a $1.5 million civil penalty, advertising-related sharing restrictions, consent requirements, deletion directions, retention limits, and a comprehensive privacy program.

The lesson is larger than one company. “Not HIPAA-covered” is not permission to treat health data like ordinary marketing data. Product teams should map sources and destinations, minimize collection, separate operational analytics from advertising, review third-party defaults, test actual network behavior, document authorization, and plan for notification. Consumers should also look beyond a HIPAA badge and ask who operates the product, which law applies, and where their information goes.

Federal health privacy is a patchwork, but the gaps are not empty. The responsible starting point is to identify the product’s role, follow the data, and apply the correct rules before a breach or enforcement action forces the issue.

California’s Adam’s Law Gives Child-Facing Chatbots a July 2027 Deadline

Joseph Sides — Tue, 29 Sep 2026 12:46:31 +0000

California has moved companion-chatbot safety from a policy debate into a product requirement. On September 10, 2026, Governor Gavin Newsom signed Senate Bill 1119, known as “Adam’s Law.” The measure was filed with the Secretary of State the same day as Chapter 190 of the Statutes of 2026. It is enacted law—not a proposal, not a bill awaiting another vote, and not a regulation that may or may not arrive.

That distinction matters because several of the law’s central duties become operative on July 1, 2027. The official chaptered bill page and the Governor’s September 10 announcement describe a framework built around age assurance, risk assessments, child-facing defaults, crisis response, privacy limits, and outside review. Developers should treat the coming months as implementation time, not as a reason to postpone planning.

The law is about design, not only disclosures

Adam’s Law applies to operators that make covered companion chatbots available to California users. The statute defines a child as a person under 18 and uses an existing legal definition of “companion chatbot.” Not every automated help widget is necessarily covered. The precise product definition, user population, and statutory exclusions matter, including exclusions for certain postsecondary educational and workplace-only uses.

For products within scope, the law requires an operator to determine a user’s age through California’s age-assurance framework or apply specified child protections more broadly. Beginning July 1, 2027, an operator must perform and document a comprehensive risk assessment before making a new or substantially modified companion chatbot available in the state. The assessment must address foreseeable covered harms, including physical or financial harm, severe psychological or emotional harm, certain privacy intrusions, and unlawful discrimination.

This is more than a requirement to publish reassuring language. The operator must document reasonable mitigation measures for identified child-safety risks. If children are permitted to use the chatbot, the operator must publish a child-safety policy explaining, at a high level, how the product prevents covered harms and responds when harm is detected.

Child accounts need safer defaults

The chaptered text turns several safety concepts into specific interface and account requirements. A child-facing companion chatbot must have a documented crisis-response protocol addressing suicide and self-harm risks. The product must provide timely in-service support and referrals to an appropriate crisis service. When an operator identifies a credible and imminent threat, the law requires specified action, which can include notifying a linked parent account when doing so would not create a threat of serious harm, or providing streamlined access to the 988 Suicide & Crisis Lifeline or an equivalent service.

Default settings are also central. Settings controlled by a parent must disable push notifications, limit one continuous session to one hour, and limit total daily chatbot use to two hours. Persistent conversational memory is generally disabled by default for child users unless the operator implements effective safety guardrails described by the law. If no parent account is linked, those defaults cannot simply be changed by the child.

The law also requires recurring, age-appropriate notices that the user is interacting with AI. That requirement recognizes an important design reality: a disclosure shown once during onboarding may not be meaningful during an extended, emotionally charged conversation.

Privacy is part of the safety model

Adam’s Law does not treat privacy as separate from child wellbeing. Beginning July 1, 2027, an operator may not display cross-context behavioral advertising to a child through the companion chatbot. It may not target ads using personal information from the child’s conversation, although the statute permits limited contextual advertising subject to conditions. Ads shown to children must be clearly labeled.

The operator also may not sell personal information gathered from a child user through the chatbot. Use and sharing are limited to purposes such as providing the requested service, protecting safety and security, complying with law, or defending legal claims. Dark patterns involving required safety features and controls are prohibited.

There is a related preservation duty. If the operator knows a child has died or engaged in serious self-harm based on chatbot conversations, or has provided a specified safety notice, it must preserve relevant conversation records in a usable, exportable form for at least three years. The statute says the associated account cannot be deleted during the applicable preservation period. That creates a difficult but necessary engineering question: how will a platform preserve evidence without turning an exceptional safety workflow into indefinite general retention?

The audit clock is different from the product deadline

The independent-audit provisions operate on a later schedule. The law sets an initial child-safety audit deadline of January 1, 2029, or before the operator first makes a companion chatbot publicly available, whichever is later. Audits then generally recur every two years, with additional review before certain substantial modifications that increase child-safety risk. Audit summaries go to the Attorney General, and a high-level summary must be posted publicly.

Operators with less than $500 million in gross revenue in the prior calendar year are not required to comply with the audit section before January 1, 2032. That limited delay should not be confused with a blanket exemption from the law’s earlier product, privacy, risk-assessment, or crisis-response requirements.

Enforcement can be significant. Public prosecutors may seek civil penalties of up to $5,000 per affected child for each negligent violation and up to $15,000 per affected child for each intentional violation. The law also authorizes a civil action by a child who suffers actual harm from a violation, or by a parent or guardian acting for the child, subject to the statute’s terms.

The practical message is simple: child safety cannot live only in a trust-and-safety memo. Age signals, session limits, memory controls, parental tools, advertising logic, incident response, retention, and audit evidence all touch real product systems. Teams that wait until June 2027 may discover that compliance requires changes across identity, data architecture, interface design, model evaluation, and customer support. Adam’s Law gives them a date, but responsible design should begin well before it.

ECPA Turns 40: Your Cloud Privacy Still Depends on a 1986 Law

Joseph Sides — Mon, 28 Sep 2026 13:11:22 +0000

On October 21, 1986, President Ronald Reagan approved the Electronic Communications Privacy Act, or ECPA. Forty years later, the law still supplies much of the federal framework for electronic surveillance and government access to stored communications. That anniversary should not be mistaken for a new deadline, a newly enacted amendment, or an upcoming vote. ECPA is existing federal law, and its importance comes from how much modern life now runs through services that barely existed when Congress wrote it.

The official text of Public Law 99-508 shows the law’s October 21, 1986 approval date. Congress designed it to extend privacy rules beyond traditional telephone calls as computers, electronic mail, and new transmission systems were emerging. Today, those rules reach a world of cloud inboxes, collaboration tools, direct messages, account logs, backups, and data stored across borders. The technology changed dramatically; the statutory architecture remained.

ECPA is a framework, not one simple privacy rule

ECPA amended the federal Wiretap Act and created what is commonly called the Stored Communications Act. It also addressed pen registers and trap-and-trace devices. Those components govern different forms of access, so saying that “ECPA protects email” is accurate only at a very high level.

The Wiretap Act generally addresses interception while communications are in transit. The current 18 U.S.C. § 2511 prohibits specified intentional interceptions, disclosures, and uses, subject to important exceptions. The Stored Communications Act, found in Chapter 121 of Title 18, addresses unauthorized access to stored communications and the circumstances in which service providers may or must disclose communications and records.

That division matters because a live communication and the copy sitting on a provider’s server can be treated under different legal provisions. It also means the answer to “Can this information be disclosed?” depends on what the data is, where it sits, who is asking, and which exception or legal process applies.

Content and account records are not treated alike

The Stored Communications Act separates communication content from many non-content records. Under the current 18 U.S.C. § 2703, the required process can vary among stored content, subscriber information, and other records. The statute includes warrants, subpoenas, and court orders, with requirements that depend on the category of information sought.

That is not a minor technical distinction. The contents of a private message can reveal a conversation. Subscriber and transactional records can reveal identity, contacts, timing, devices, and patterns of activity. A product team that labels all of this simply as “user data” may miss the distinctions that matter when a government request arrives.

The Supreme Court’s 2018 decision in Carpenter v. United States also shows why statutory process is not the end of the analysis. The Court held that obtaining the historical cell-site location information at issue was a Fourth Amendment search. Carpenter did not rewrite ECPA or decide every question involving digital records, but it rejected the idea that all information held by a third party automatically falls outside meaningful constitutional privacy protection.

Voluntary disclosure has rules too

Government demands receive much of the attention, but developers should also understand voluntary disclosure. 18 U.S.C. § 2702 generally restricts certain providers from voluntarily divulging communication contents or customer records, then lists exceptions. Those exceptions cover circumstances such as consent, disclosures necessary to provide the service, protection of the provider’s rights or property, and specified emergencies involving danger of death or serious physical injury.

An exception is not a blank check. Teams should know which statutory provision they rely on, document the facts supporting it, and limit disclosures to what the situation justifies. Vague internal labels such as “safety issue” or “law-enforcement request” are not substitutes for identifying the requester, validating legal process, recording scope, and escalating difficult cases.

What developers and consumers should take from the anniversary

For developers, ECPA should influence data architecture before a request ever arrives. Maintain a defensible data map. Separate content from account and security records. Set retention periods intentionally instead of keeping everything by default. Build a process to preserve data when legally required without turning preservation into general surveillance. Section 2707 provides a civil cause of action for knowing or intentional violations of the chapter in specified circumstances, making disciplined access controls and request handling more than administrative housekeeping.

Global systems add another layer. 18 U.S.C. § 2713 addresses preservation and disclosure of communications or records within a provider’s possession, custody, or control, even when the data is stored outside the United States. Location alone is therefore not a complete answer to a disclosure question.

For consumers, the lesson is not that privacy disappeared in 1986. It is that cloud privacy comes from overlapping sources: federal statutes, constitutional rules, state laws, provider policies, contracts, and technical choices such as encryption. ECPA can restrict access and create remedies, but it does not function like a universal consumer privacy law governing every collection, inference, sale, or advertising practice.

Forty years is a useful moment to ask whether the language, categories, and procedures built for an earlier communications era still match how people live online. Until Congress changes the law, however, ECPA remains operational law—not history. Companies that hold communications should treat that fact as a design and governance requirement, while users should understand that the privacy of a message can depend on more than what appears on the screen.

Smart Glasses Have a Bystander Privacy Problem: Texas’s Meta Investigation Shows Why

Joseph Sides — Sun, 27 Sep 2026 12:20:14 +0000

Smart glasses are moving from novelty to ordinary consumer technology, but their privacy problem is different from the one created by a phone. When someone raises a phone to record, the act is usually visible. Glasses can capture the same room, conversation, face, or private moment while looking much more like something a person simply wears.

That difference is now becoming a product-design and legal issue. Reuters reported on September 22, 2026, and updated its report September 23 that privacy concerns are affecting the emerging market for AI wearables. The report described lawsuits, venue sestrictions, camera-free alternatives, and growing interest in devices that process more data locally or make recording more deliberate and visible.

The renewed attention also makes a pending state investigation worth understanding. On May 20, 2026, the Texas Attorney General announced an investigation into Meta AI Glasses. The announcement raised concerns about recording, privacy representations, access to captured material, and potential collection of facial geometry. It said the state issued a civil investigative demand to determine whether Meta deceptively misrepresented its use of consumer data in violation of Texas law.

An investigation is not a finding of liability. The announcement contains allegations and questions, not a court judgment. As of September 27, 2026, I did not locate an official Texas announcement resolving this specific investigation.

The user is not the only data subject

Traditional consent screens focus on the person who bought the device or opened the app. Smart glasses complicate that model because the people whose voices, faces, homes, workplaces, and behavior enter the system may never see a screen at all. The wearer can accept a privacy policy. A bystander across the room cannot.

This is why a recording light should not be treated as the entire privacy system. Notice is useful only if people can see it, understand it, and respond before collection. A device also needs controls for what is captured, whether information stays local, what reaches a cloud service, how long it remains available, and whether it is used for model improvement or human review.

The Texas announcement specifically discussed an “always enabled” mode and alleged that a visual indicator was not active during that processing. Meta’s position deserves equal clarity: Reuters reported that the company says its recording light cannot be disabled during filming, that the camera is disabled when the light is covered or tampered with, and that it filters identifying information. Meta also said it disagrees with allegations in a separate lawsuit and will contest them.

Those competing claims show why privacy cannot rest on marketing language alone. Terms such as “always enabled,” “recording,” “processing,” and “uploading” need precise technical definitions. People should not have to guess whether a device is waiting for a wake word, analyzing locally, saving a clip, or transmitting data.

Texas law puts facial geometry in a special category

Texas already has a specific biometric privacy statute. The state’s Capture or Use of Biometric Identifier Act, commonly called CUBI, covers retina or iris scans, fingerprints, voiceprints, and records of hand or face geometry. For commercial capture, the Texas Attorney General explains that a person must inform the individual and obtain consent before collecting the biometric identifier.

CUBI also restricts sale, lease, and disclosure, subject to exceptions; requires reasonable care in maintaining and transmitting biometric identifiers; and requires destruction within a reasonable time, no later than one year after the collection purpose expires unless an exception applies. The Attorney General has exclusive enforcement authority and may seek civil penalties of up to $25,000 per violation. The current statutory text is available from the Texas Legislature.

Not every image of a face is necessarily a record of face geometry, and not every camera function automatically triggers CUBI. The important questions include whether the system creates or captures a biometric identifier, whether that happens for a commercial purpose, what notice was provided, and whose consent was obtained. Those are fact-specific legal questions—not conclusions that can be answered from a product name.

The enforcement backdrop is significant. In 2024, Texas announced a separate $1.4 billion settlement with Meta concerning allegations that Facebook’s earlier facial-recognition feature captured Texans’ facial geometry without the authorization required by law. That resolved a different matter involving Facebook photo-tagging technology. It does not resolve the 2026 smart-glasses investigation, but it shows that Texas has used CUBI in major enforcement.

What developers should build before the backlash arrives

Developers of wearable products should begin with a complete data-flow map, not a simplified consumer diagram. Separate sensor activation, temporary buffering, local inference, saved recordings, cloud uploads, human review, derived biometric templates, model training, and third-party sharing. If those actions are collapsed into one vague label, the product team may not understand its own legal and privacy exposure.

Bystander-facing notice also needs to be designed as a real interface. Indicators should be visible from ordinary angles, difficult to defeat, and connected to the actual state of capture and transmission. Products should fail safely when an indicator is blocked or damaged. Audible notices may help in some settings, while physical shutters and camera-free modes can provide stronger assurance than software promises alone.

Data minimization is equally important. If a feature can operate with local processing, the system should not automatically transmit raw audio or video. If a task needs a short buffer, the device should not retain an entire conversation. If facial recognition is unnecessary, the product should not create face-geometry records merely because the hardware makes it possible. Retention schedules should attach to the purpose of collection, and deletion should reach cached copies, derived data, and training pipelines where required.

Consumers and bystanders also need understandable controls and complaint paths. Wearers need clear settings for recording, cloud processing, storage, sharing, and model improvement. Bystanders need a realistic way to report misuse or ask what happens to their data, even without an account.

Privacy will shape whether wearables become normal

The most useful smart glasses may be the ones that make privacy visible. A product can offer convenience without treating everyone nearby as free training data. Clear indicators, local processing, deliberate activation, limited retention, and biometric safeguards are not obstacles to adoption. They are part of what makes adoption possible.

The Texas investigation remains an investigation, but the policy lesson is already clear. Wearable technology changes who becomes a data subject. Developers should design for the person in front of the camera, not only the person behind it.

When an Algorithm Becomes a Consumer Report: The FCRA Questions Developers Should Ask

Joseph Sides — Sat, 26 Sep 2026 12:54:13 +0000

Privacy law is often discussed as if it begins and ends with whether a company collected data or shared it without consent. The Fair Credit Reporting Act adds another question: what happens when a dossier, score, or recommendation helps decide whether someone gets a job, keeps a job, rents a home, receives credit, or obtains insurance?

The FCRA is not a new bill awaiting a vote. It is an existing federal law, codified at 15 U.S.C. §§ 1681–1681x. The Federal Trade Commission explains that it governs consumer reporting agencies, organizations that furnish information to them, and businesses that use consumer reports. The law is commonly associated with credit bureaus, but its reach can extend to tenant-screening services, employment background-check companies, and other firms that assemble information for eligibility decisions.

That broader frame matters in an era of automated screening. A product does not fall outside the FCRA simply because its output is called an “insight,” “risk signal,” “fit score,” or “recommendation.” The practical questions are what information the product assembles or evaluates, where that information came from, who receives the output, and whether the output is used to decide a consumer’s eligibility for a covered purpose.

A score can carry the same consequences as a report

Under the statute, a consumer report can include information from a consumer reporting agency about a person’s creditworthiness, character, general reputation, personal characteristics, or mode of living when it is used or expected to be used for a covered eligibility decision. Employment is one of those purposes, and the term includes hiring, promotion, reassignment, and retention.

In Circular 2024-06, the Consumer Financial Protection Bureau explained that background dossiers and algorithmic scores may qualify as consumer reports when the statutory elements are met. The circular gives a useful example: a company that monitors transportation workers and produces scores for employers could be acting as a consumer reporting agency if it uses information from other employers or public sources to create those scores.

That guidance does not mean every workplace analytics product is automatically covered. The FCRA contains an exclusion for certain communications based only on transactions or experiences between the consumer and the person making the report. The CFPB also notes that this exclusion may not apply when outside information is added. That is why a careful data-flow analysis matters more than a product label.

What the law is trying to protect

The FCRA is a privacy law, but it also treats accuracy and the ability to challenge consequential information as privacy protections. The FTC’s guidance for employment background-screening companies emphasizes reasonable procedures to assure maximum possible accuracy, permissible purposes for obtaining reports, client certifications, consumer access, and dispute rights.

When an employer obtains a consumer report for employment purposes, it generally must have the worker’s written permission. Before taking an adverse action based on the report, the employer must provide a copy of the report and a summary of rights. After the decision, a separate adverse-action notice is required. Those steps give the worker a chance to see the information and identify errors before the decision becomes final.

Housing decisions create similar practical concerns. The CFPB’s tenant background-check guidance says a landlord must provide notice when a report leads to a denial or less favorable terms, such as a higher deposit or fee. The notice must identify the screening company, and the applicant may request a free copy of the report within 60 days. Consumers can then dispute inaccurate or outdated information.

Product design is part of compliance

For developers and product teams, the first question should be whether the service is helping make a covered eligibility decision. If the answer may be yes, map the data sources, intended uses, customers, outputs, and downstream actions. A model trained on public records and information from multiple businesses creates a different risk profile from an internal tool using only a company’s direct interactions with its own workers.

Accuracy must be engineered, not promised. Identity matching should not treat a similar name as a reliable match. Records need dates, provenance, and rules for handling dismissals, expungements, duplicates, and stale information. A confidence score can look precise while concealing weak source data. Human review is not a cure if the reviewer cannot see why a record was matched or what evidence supports the score.

Dispute handling also needs a real product workflow. Consumers should be able to request their file, understand the source of disputed information, submit supporting documents, and receive the result of a reinvestigation. Corrections should propagate to derived scores and to customers who received the bad information when the law requires it. A support inbox with no ownership, deadline tracking, or connection to the underlying data is not an effective dispute system.

Access controls matter too. Because consumer reports may be furnished only for permissible purposes, platforms should record who requested a report, the certified purpose, the affected person, and the customer account that received it. Audit logs, retention controls, customer attestations, and misuse monitoring are not administrative extras; they help demonstrate that the product is not turning sensitive dossiers into general-purpose surveillance.

Finally, notices should be built into the decision process rather than assembled after launch. A customer using a report for employment or housing needs enough information to send accurate pre-adverse-action and adverse-action notices. If the platform cannot identify which report or score influenced a decision, the consumer may be left unable to understand or challenge it.

The practical takeaway

For consumers, a negative employment or housing decision should prompt a simple question: was a third-party report or score involved? If it was, ask for the required notice and report, review identifying details and source records, and dispute errors promptly.

For builders, the larger lesson is that automated decision tools are not outside older privacy laws merely because the technology is new. The FCRA focuses on function and consequence. When information is assembled and communicated for eligibility decisions, the product may carry duties involving purpose, accuracy, access, correction, and notice.

Privacy is not only about keeping information secret. It is also about whether a person can see, understand, and challenge the data used to make important decisions about their life. That principle remains highly relevant whether the decision comes from a traditional background report or an algorithmic score.

The FTC’s “Active Listening” Orders: Consent Cannot Be Invented

Joseph Sides — Fri, 25 Sep 2026 12:28:30 +0000

The idea that a phone is secretly listening to everyday conversations has circulated for years. In August, the Federal Trade Commission finalized three orders involving companies that marketed something even more direct: an “Active Listening” advertising service said to use AI and conversations captured from smart devices to target local ads. The FTC says the service did not use voice data at all.

On August 27, 2026, the FTC announced final approval of consent orders involving CMG Media Corporation, which does business as Cox Media Group, MindSift LLC, and 1010 Digital Works LLC. The companies agreed to pay a combined $930,000: $880,000 from CMG and $25,000 from each of the two marketing firms. The Commission approved the final orders by a 2–0 vote after receiving two public comments.

This was not a trial verdict finding that the companies secretly recorded consumers. It was an administrative settlement of FTC allegations. The CMG final order states that the company neither admitted nor denied the complaint’s allegations except for facts necessary to establish jurisdiction. The resulting orders are nevertheless final and binding on the companies’ future conduct.

What the FTC alleged

The FTC’s original May announcement described marketing claims that the service listened for relevant conversations through smart devices, used a special algorithm to identify potential customers, and placed ads in selected geographic areas. According to the complaints, the actual service did not listen to voice data and did not accurately deliver the advertised geographic targeting. Instead, it consisted of reselling email lists obtained from other data brokers at a significant markup.

The FTC also alleged that the companies told prospective business customers that consumers had opted into Active Listening. The supposed consent was said to come from the terms people accept when they download and use apps. But the agency said the companies had not sought or obtained consumer consent for the advertised service. Its May announcement made the point plainly: clicking through mandatory terms of service does not amount to opt-in consent for an invasive service using voice data from inside a home.

That last point reaches beyond these three companies. Consent is not a label that can be attached to data after the fact. A business needs to know what people were told, what choice they were offered, what data practice the choice covered, and whether the product actually honored the resulting preference. A distant reference inside general app terms is not automatically evidence that a person knowingly agreed to an unexpected use of a microphone or voice data.

Why this is still a privacy case

It may sound strange to call this a privacy case when the FTC alleges that the advertised listening did not occur. But the deception itself concerned privacy. The product was sold by representing that intimate data could be captured and used, while the companies allegedly described consumers as having consented when they had not. If the service had operated as advertised, the FTC said that collecting and using voice data without adequate consent would itself violate Section 5 of the FTC Act.

The FTC Act gives the Commission authority to challenge unfair or deceptive acts or practices affecting commerce. In this matter, the final orders prohibit misrepresentations about the features of advertising services, the collection or use of voice data, whether consumers consented to the collection, use, or disclosure of voice data, and the geographic targeting capabilities of the services.

The CMG order illustrates that this is more than a direction to rewrite a sales page. It requires payment, compliance reporting, recordkeeping, and distribution of the order to relevant personnel. Its core obligations can remain in place for 20 years. The order also requires records supporting covered advertising representations, including evidence the company relied upon and material that may contradict or qualify those representations.

What product and development teams should learn

The first lesson is that marketing claims need a technical source of truth. If a sales deck says a system listens to voice data, targets within a defined location, uses AI to infer intent, or relies on consumer opt-in, a company should be able to map each claim to how the product actually works. Product, engineering, privacy, and marketing teams should review the same data-flow documentation rather than relying on separate stories.

Second, consent needs to be designed around the actual practice. Teams should document the exact disclosure presented to the consumer, when it appeared, whether the choice was optional, which data and purposes it covered, and how a withdrawal travels through the system. A generic representation that “users consented through app terms” should trigger questions, especially when the proposed practice involves microphones, homes, health information, precise location, or other sensitive contexts.

Third, vendor due diligence cannot stop with a polished demonstration. A business buying an advertising or AI service should ask what data powers the product, where it comes from, how consent was obtained, and what validation supports targeting claims. Developers integrating a vendor’s SDK or audience product should understand permissions, identifiers, and outbound data rather than assuming the product name explains the architecture.

Finally, adding “AI-powered” to a claim does not reduce the need for evidence. It may increase the need for careful explanation because customers and consumers cannot easily see what a model, algorithm, or data pipeline is doing. An AI label should describe a real function, not act as a substitute for verifiable product behavior.

What consumers should take away

People should not assume that a surprisingly relevant advertisement proves a microphone captured their conversation. Ad systems can make uncomfortable inferences using browsing activity, location, purchases, email lists, and information acquired from data brokers. At the same time, companies should not be free to market secret listening as a feature or claim that consumers agreed to it without evidence.

Consumers can review microphone permissions and privacy controls on their devices, question services that make unusually broad data claims, and report deceptive practices to the FTC. The larger lesson is that meaningful privacy depends on both sides of a representation: what the technology actually does and what the company tells people about it.

The FTC’s Active Listening orders are a reminder that privacy accountability is not limited to proving that sensitive data was collected. It also includes truthfulness about product capabilities and honesty about consent. For developers and businesses, the safest foundation is simple: know the system, document the claim, and never describe consent that the product did not actually obtain.

California’s Data Broker Warning: Accuracy Is Not Optional

Joseph Sides — Thu, 24 Sep 2026 12:34:23 +0000

California’s data broker registry is supposed to answer a basic privacy question: who has information about me, what kind of information do they have, and where might it be going? That promise depends on the answers in the registry being true. On September 3, 2026, the California Privacy Protection Agency’s Enforcement Division issued Enforcement Advisory 2026-01, warning data brokers that incorrect registration information can violate the Delete Act and lead to a $200 administrative fine for each day the error remains in the registry.

This is not a newly enacted statute, a court ruling, or a final enforcement order against a particular company. It is an enforcement advisory explaining how the agency views an existing obligation. The advisory also says that the Enforcement Division has already brought multiple actions involving reporting errors. For privacy teams, product leaders, and developers, the message is practical: annual registration cannot be treated as a clerical form that gets copied forward without checking the underlying data practices.

Why registry accuracy matters

Data brokers usually do not have the direct relationship with consumers that a bank, retailer, or streaming service has. A person may never recognize the name of a company that holds or sells information about them. California’s registry is designed to reduce that visibility gap. The agency’s September 3 announcement explains that registration disclosures cover subjects such as the types of data collected, request metrics, and whether information was shared with certain categories of recipients.

Those details are not abstract. The advisory identifies categories including precise geolocation, biometrics, reproductive-health information, citizenship or immigration data, union membership, sexual orientation, gender identity, and common identifiers such as names, dates of birth, email addresses, phone numbers, and home addresses. It also discusses disclosures about sharing or selling information to government entities, law enforcement, certain foreign actors, and developers of generative-AI systems or models.

When a registry entry is wrong, a consumer may make a privacy decision using an incomplete picture. They may not understand that a broker handles sensitive data or that information may have reached a category of recipient they care about. Accuracy therefore supports more than regulatory paperwork. It supports informed use of privacy rights.

That connection is especially important now that California’s Delete Request and Opt-out Platform, known as DROP, is operating. According to CalPrivacy’s official DROP guidance, California residents have been able to submit a single request to active data brokers since January 2026, and brokers were required to begin processing those requests on August 1, 2026. The same guidance says brokers must access and process DROP requests at least once every 45 days. Reliable registration information helps make that centralized system meaningful.

The obligation is annual—and factual

Under the Delete Act framework described by the agency, a business that operated as a data broker in the prior year must register by January 31, pay the required fee, and make required disclosures. The advisory points to Civil Code section 1798.99.82 and the implementing regulations. It emphasizes that the rules require “only true and correct responses” in the registration.

The agency also makes an important point about intent: the law does not distinguish between an unintentional mistake and an intentional misrepresentation when the result is incorrect information. That does not mean every error will produce the same enforcement outcome; the advisory says enforcement decisions are made case by case. But it does mean that “we did not mean to” is not a substitute for maintaining an accurate reporting process.

The hypothetical examples in the advisory are useful because they show where mistakes can begin. A lead-generation business may add new data fields or new customers during the year. A company operating tracking cookies or mobile software development kits may start collecting location data and associating it with nearby stores. A data buyer may use purchased information in connection with a generative-AI product. Each change can alter what must be disclosed during the next registration cycle.

What developers and product teams should do

Registration accuracy should be supported by the same systems used to understand the product’s data flows. A once-a-year questionnaire is fragile if no one can trace what production systems actually collect, derive, receive, sell, or share. Engineering, privacy, security, legal, sales, and vendor-management teams need a common inventory that reflects reality rather than assumptions.

Developers can help by documenting the data categories created by new features, the third-party SDKs and tracking tools in use, the purpose and destination of outbound data, retention behavior, and whether a recipient’s role has changed. Product change reviews should ask whether a new data source, model-training use, government customer, or location feature will affect future registry disclosures. Versioned records are valuable because registration concerns activity during the prior year, not simply the configuration visible on the day the form is submitted.

Companies should also build an owner-and-review process around registration. Someone should be accountable for gathering evidence, another person should verify the answers against data maps and contracts, and changes made after submission should be evaluated promptly. CalPrivacy’s registry page provides public access to submitted information and a way for brokers to request updates, so discovering an error should trigger correction—not a wait-until-next-year approach.

For consumers, the practical takeaway is to treat the registry and DROP as useful tools while remembering that their value depends on accurate company reporting and active enforcement. If an entry appears inconsistent with a broker’s public practices, CalPrivacy’s announcement directs consumers to the agency’s complaint process. A transparent system works best when businesses maintain accurate records, regulators test them, and consumers can flag problems.

California’s advisory turns a simple concept into an operational privacy requirement: transparency has to be true to be useful. A registry filled with stale or incomplete answers creates the appearance of accountability without the substance. For developers and organizations, the durable response is not better wording alone. It is better knowledge of the data moving through the product—and a process that converts that knowledge into accurate public disclosures.