DEV Community: Joseph Sides

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.

The TAKE IT DOWN Act’s 48-Hour Rule Is Now a Product Requirement

Joseph Sides — Wed, 23 Sep 2026 12:36:58 +0000

When someone discovers that an intimate image of them has been shared without permission, the platform’s reporting process becomes part of the harm—or part of the response. A buried form, an unexplained rejection, or a request left unread over a weekend can leave the person with little practical control. Privacy protection in this setting depends on what the service can actually do after someone asks for help.

The federal TAKE IT DOWN Act makes that response an operational responsibility for covered platforms. It became Public Law 119-12 on May 19, 2025. The separate deadline for establishing its notice-and-removal process was May 19, 2026. As of September 23, 2026, that deadline has passed. This is an explainer about an enacted law and an existing platform obligation, not a report about a proposed bill or an upcoming vote.

The Federal Trade Commission’s business guidance states that it enforces Section 3, effective May 19, 2026. Under that section, a covered platform receiving a valid removal request must act as soon as possible, and no later than 48 hours after receipt. It must remove the reported intimate depiction and make reasonable efforts to identify and remove known identical copies. The statutory wording matters: this is not a promise to erase every copy across the entire internet.

Coverage also needs careful attention. Section 4 of the law defines covered platforms to include public-facing services that primarily provide a forum for user-generated content, as well as services whose regular business includes making nonconsensual intimate depictions available. The definition has exclusions, including electronic mail and certain services primarily offering provider-selected content with incidental interactive features. A team should evaluate its actual service against the definition rather than assuming that every website—or only a large social network—is covered. The enacted text supplies the controlling details.

This protection addresses both authentic imagery and qualifying digital forgeries. The FTC’s guidance makes clear that digitally created or altered intimate images can fall within the law. A person does not have to treat an AI-generated depiction as harmless simply because the depicted event never happened. At the same time, developers should avoid substituting a broad label such as “AI content” for the statute’s specific definitions and requirements.

A valid written request under Section 3 includes a physical or electronic signature, enough information to identify and locate the depiction, a brief good-faith statement that it is nonconsensual with relevant supporting information, and contact information for the depicted individual or an authorized representative. Covered platforms must explain their notice-and-removal process clearly and conspicuously in plain language. These requirements concern the removal workflow; the Act separately contains criminal provisions with their own elements and exceptions.

For consumers, the practical starting point is the platform’s designated process. Keep the location of the content, the time the request was submitted, and any confirmation or reference number in a secure place. Avoid publicly reposting intimate material to prove that it exists. A complaint about a platform’s response should not require broadcasting the underlying harm to a new audience. The FTC’s platform-violation reporting site provides a separate route for reporting failures under the Act; reporting to the FTC should not be confused with sending the removal request to the platform itself.

For developers, I would begin with the clock. Record when a request arrives, route it promptly, and make approaching deadlines visible to the people responsible for handling it. The law says 48 hours, not two business days. A queue that receives reports continuously but is reviewed only on weekday mornings is an obvious design risk. Test the handoff between intake, review, removal, and confirmation before a real person has to depend on it.

The interface deserves the same attention. The FTC recommends making reporting accessible to people who do not hold an account and providing request identifiers and clear status information. My implementation recommendation is to test the process on mobile, with assistive technology, and while signed out. Those checks can reveal a report button that technically exists but is practically unavailable to the person who needs it.

Removal should also be tested against the platform’s actual content architecture. In a hypothetical service, the original upload, a public thumbnail, a cached delivery URL, and a repost might travel through different systems. Engineering and legal teams should decide how the law applies to those copies and how to verify the required outcome. Removing a database row does not, by itself, establish that the content has stopped being served.

A reporting system can create a second privacy problem if it exposes sensitive submissions too widely. My recommendation is to limit staff access, avoid placing intimate content or identifying details in general application logs, and use controlled review environments. Retention decisions should account for applicable preservation and reporting obligations. Testing should use safe synthetic placeholders rather than real victims’ material, and routine debugging should not create unnecessary new copies.

Speed and careful review both matter. Build escalation paths for uncertainty and abuse of the reporting process, but do not let internal routing become an excuse for an unattended request. From a privacy-advocacy perspective, the measure of a useful system is whether a person can understand it, reach it, and receive the response it promises. The TAKE IT DOWN Act gives covered platforms a concrete deadline; responsible product design has to make that deadline achievable.

A Privacy Opt-Out Button Has to Work: Lessons from California’s Todd Snyder Case

Joseph Sides — Tue, 22 Sep 2026 06:57:10 +0000

A person clicks a privacy link because they want something to change. They may be trying to stop information about their browsing from being sold or shared. A confirmation message matters only if the systems behind it carry out that choice. For developers, this makes the privacy interface a feature with consequences that extend well beyond the screen.

California’s Todd Snyder enforcement case provides a concrete example. On May 6, 2025, the California Privacy Protection Agency announced a settlement requiring the clothing retailer to pay $345,178 and change its privacy practices. The agency alleged that a misconfigured privacy portal failed to process opt-out requests for 40 days. It also alleged unnecessary information collection and improper identity verification for opt-outs. The official announcement explains those allegations and the agreed remedies.

The Board’s order adopted the stipulated final order on May 1, 2025, with immediate effect. This is a retrospective look at an enforcement settlement under existing law, written on September 22, 2026. It is not an announcement of a new statute, a pending vote, or a fresh compliance deadline.

What interests me as a privacy advocate is the distance between providing a choice and delivering its result. A business can display a privacy link while the request behind that link goes nowhere. Consumers usually cannot inspect the queue, vendor configuration, or downstream records. They have to rely on the business to make the visible promise match the actual process.

The legal scope matters. California’s Consumer Privacy Act applies to covered businesses and protects California consumers; it does not make every privacy preference a universal legal right everywhere. The California Attorney General’s CCPA guide explains the right to opt out of sale or sharing, including sharing for cross-context behavioral advertising. That right is different from requesting deletion of information. An opt-out should therefore be described precisely, so consumers understand what they have requested and what it changes.

There is also a useful distinction between identifying the information affected by a request and demanding proof of identity. The agency’s April 2, 2024 enforcement advisory explains that businesses must not require identity verification for requests to opt out of sale or sharing. Necessary information to complete a request may be appropriate, but it must not become a burdensome verification process. The advisory also discusses applying data minimization to privacy requests. It is enforcement guidance, not a new law or a guarantee of compliance.

For a development team, my practical recommendation is to treat the complete request journey as a product requirement. Begin with the choice shown to the visitor. Follow it through the consent tool, application state, backend processing, and the destinations that receive information. Assign responsibility for each handoff. A successful form submission is evidence that one step worked; the test still needs to establish whether the intended data practice changed.

Consider a hypothetical retail site that sends advertising events through both browser scripts and a server integration. The browser interface might update a preference while the server continues sending the same events. A useful review would examine both routes and determine which transmissions the opt-out must affect. This is an engineering example, not an allegation about Todd Snyder’s architecture. The broader point is that testing should follow the information through the actual system.

I would also include negative cases in that review. What happens when the consent provider is unavailable, a queued request fails, or a new tag is added? Does the interface report success before the system can support that statement? Can the team detect a mismatch without waiting for a consumer complaint? These questions help turn an abstract privacy commitment into observable behavior. They should be answered with proportionate testing and records that avoid collecting additional sensitive information unnecessarily.

Browser-based choices deserve attention too. The Attorney General’s Global Privacy Control explanation describes GPC as a way to communicate an opt-out of sale or sharing, and says covered businesses must honor it as a valid request. A review that only exercises a website’s manual button can miss this separate entry point. Teams should establish how the signal reaches the parts of their system responsible for carrying out the choice.

For consumers, the practical takeaway is to look for the specific right a control offers. A sale-or-sharing opt-out, a deletion request, and a browser setting can have different effects. Save the date and any confirmation when submitting a request. If a control is broken, document what happened without including passwords or other sensitive details. The Attorney General’s CCPA guide explains complaint options and makes clear that regulators do not act as an individual’s private attorney.

For developers, the lasting lesson is ownership. Buying a privacy tool creates another integration to maintain. Someone still needs to understand its configuration, monitor failures, and check it after changes to the site or advertising stack. Clear language helps people make a choice; reliable implementation gives that choice meaning. Both deserve the same attention we give to the other features people depend on.

HIPAA Isn’t the Whole Story: The FTC Rule Health-App Developers Should Know

Joseph Sides — Mon, 21 Sep 2026 12:45:00 +0000

Health information does not become protected by HIPAA simply because it is sensitive, medical, or collected by an app. That assumption is understandable, but it can leave consumers with an inaccurate picture of their rights and developers with an incomplete compliance plan. Federal health privacy is divided among different laws and regulators, and one of the most important rules for consumer-facing health technology comes from the Federal Trade Commission.

The Department of Health and Human Services explains that HIPAA generally applies to covered health plans, qualifying health care providers, health care clearinghouses, and their business associates. HHS also states plainly that an entity outside the definitions of covered entity or business associate does not have to comply with the HIPAA Rules. That means a wellness app, fitness service, fertility tracker, or connected device may handle deeply personal information without being governed by HIPAA in the same way as a hospital or health plan. HHS guidance on covered entities and business associates

That gap does not mean there are no federal obligations. The FTC’s Health Breach Notification Rule applies to vendors of personal health records, personal-health-record-related entities, and certain third-party service providers that maintain information concerning U.S. citizens or residents. It expressly excludes HIPAA-covered entities and activities performed as a business associate of one. The rule implements provisions of the American Recovery and Reinvestment Act of 2009. It is an existing federal regulation, not a new bill awaiting a congressional vote.

The FTC finalized amendments in 2024 to clarify how the rule reaches modern consumer health technology. The final rule was published May 30, 2024, and the amendments became effective July 29, 2024. The agency explained that the changes clarify coverage of many health apps, modernize notice methods, expand required notice content, and confirm that a breach can include an unauthorized disclosure—not only a cybersecurity intrusion. Federal Register final rule

The current regulation defines “health care services or supplies” broadly enough to include websites, mobile apps, and internet-connected devices that help people track matters such as diseases, medications, vital signs, symptoms, fitness, fertility, sexual health, sleep, mental health, genetics, or diet. A “personal health record” is an electronic record of identifiable health information that has the technical capacity to draw information from multiple sources and is managed, shared, and controlled by or primarily for the individual. Coverage still requires analysis of the complete definitions; the fact that software mentions health does not automatically resolve every question. Current text of 16 CFR Part 318

The expanded understanding of a breach is especially important for development teams. Under the current rule, a breach includes unauthorized acquisition resulting from either a data breach or an unauthorized disclosure. A malicious outsider breaking into a database is one example, but it is not the only one. Sending identifiable health information to an advertising, analytics, or other technology provider without authorization may raise a different kind of breach question.

That does not mean every third-party network request is automatically a violation. The technical facts and the legal definitions matter: what information was sent, whether it was identifiable health information, where it originated, which entities were involved, what the user authorized, and whether the record could draw from multiple sources. Developers should be able to answer those questions with evidence rather than relying on a generic privacy-policy sentence.

The rule’s notice duties are concrete. Following discovery of a covered breach, vendors and related entities must notify affected individuals and the FTC. If the breach involves 500 or more residents of a state or jurisdiction, prominent media outlets serving that area must also be notified. A third-party service provider must notify the appropriate official at the vendor or related entity and obtain acknowledgment that the notice was received. The rule treats a breach as discovered when it is known or reasonably should have been known, including knowledge attributable to employees, officers, or other agents as specified in the regulation.

Required notifications generally must be sent without unreasonable delay and no later than 60 calendar days after discovery. For breaches involving 500 or more individuals, FTC notice must be provided at the same time as the required individual notice. Smaller incidents may be logged and reported to the FTC annually within the rule’s deadline. The notice to individuals must use plain language and include, where possible, what happened, the dates, the types of information involved, protective steps, the entity’s response, and ways to ask questions. FTC rule summary and official resources

The FTC has shown that unauthorized advertising disclosures are not merely theoretical. In February 2023, the agency announced its first enforcement action under the rule against GoodRx. The FTC alleged that the company disclosed identifiable health information to advertising platforms and others without providing required notifications. The announced proposed order included a $1.5 million civil penalty and restrictions on health-data sharing for advertising. The case preceded the 2024 amendments, but it illustrates the agency’s view that an unauthorized disclosure can trigger breach-notification duties. FTC’s GoodRx enforcement announcement

For developers, the practical response begins with a data-flow inventory. List the health-related fields, user identifiers, device identifiers, URLs, event names, and derived attributes a product handles. Then map every destination: internal databases, crash reporting, customer support, analytics, advertising, cloud storage, and external APIs. Review whether each transfer is expected, necessary, disclosed, and authorized. An SDK that was harmless on a general marketing page may create a different risk when placed inside a medication, fertility, or mental-health workflow.

Incident planning should reflect that broader view. Monitoring should detect unexpected outbound disclosures as well as unauthorized access. Contracts should identify who receives breach notices and how receipt is acknowledged. Logs should support a reliable discovery date, affected-user count, and reconstruction of the information transmitted. Product, security, privacy, and legal teams should know who starts the notification analysis and who preserves the evidence.

For consumers, the lesson is equally direct: do not assume that a health-themed service is covered by HIPAA. Review who operates it, what it collects, where it sends information, and what controls it provides. For developers, the absence of HIPAA coverage is not the end of the analysis. The FTC’s rule exists precisely because consumer health records can sit outside the traditional medical system while remaining intensely personal.