Issue 15 • Wednesday, June 24, 2026
A concise weekly scan of surveillance, privacy, cybersecurity, and the safeguards public officials should keep in view.
At a glance
- A federal court set aside the government’s 2025 overhaul of the SAVE system after sensitive records were repurposed for bulk voter screening and produced inaccurate citizenship flags.
- ICE reportedly turned to a data broker for tax-identifier records after direct federal sharing faced legal barriers.
- Eugene is beginning the harder work of governing surveillance citywide rather than debating one tool at a time.
- Age verification is advancing through Congress, state law, litigation, and increasingly automated estimates of who is a child.
Federal databases became a voter-screening system—and a court said the government skipped the rules
A federal judge has set aside the federal government’s 2025 overhaul of the Systematic Alien Verification for Entitlements system, known as SAVE, after finding that agencies unlawfully combined sensitive records and transformed an administrative verification tool into a system for mass voter screening.
SAVE is not new. It was built to help government agencies verify citizenship or immigration status when people apply for certain public benefits, licenses, and other services. The court did not eliminate that longstanding function. It instead vacated the 2025 modifications that dramatically changed what the system could search and how it could be used.
According to the 75-page opinion, the modified system differed from the earlier version in three major ways. It added records about people born in the United States, connected SAVE to Social Security Administration records—including full or partial Social Security numbers—and allowed government users to upload lists for bulk searches rather than checking one person at a time.
Those changes matter because they altered both the scale and the purpose of the system. A database designed to verify an individual’s eligibility for a service became a tool that states could use to compare large voter lists against federal records. The court found that the agencies violated provisions of the Social Security Act and the Privacy Act, including statutory and procedural protections governing how personal information is disclosed and how federal record systems are changed.
The accuracy problem was not hypothetical. The court described naturalized citizens whose Social Security records had not been updated and who were identified as potential noncitizens. Some were required to provide proof of citizenship within 30 days to protect their registrations. The record included citizens whose registrations were wrongfully canceled, including one person who learned of the cancellation only later.
This does not mean election officials should ignore reliable evidence that someone is ineligible. It means that a match produced by a repurposed database should not be treated as a fact without understanding where the data came from, how current it is, what error rate exists, and what process allows an eligible person to correct the record before losing a right.
The case also illustrates why bulk search is not merely a technical upgrade. Searching one identified person for a documented reason is different from uploading millions of names to see who a system flags. Once bulk screening becomes available, an administrative database can become a general eligibility, enforcement, or suspicion engine.
Why it matters for Bend: Local and state governments hold sensitive information because residents apply for licenses, permits, utilities, benefits, housing, jobs, school services, and emergency assistance. The original collection may be lawful and necessary. The next question is whether those records can later be combined, searched, or repurposed for a substantially different objective without public notice, accuracy testing, correction rights, or a new decision by elected officials.
The safeguard is not a promise that data will be used responsibly. It is a rule that identifies the authorized purpose, limits the searchable records, documents every query, tests for error, notifies people before adverse action, and provides a meaningful way to correct mistakes.
When direct government access is blocked, agencies may buy the data instead
A nearly $10 million procurement reviewed by 404 Media indicates that Immigration and Customs Enforcement is purchasing records related to Individual Taxpayer Identification Numbers through a commercial data provider.
An ITIN is a tax-processing number issued by the Internal Revenue Service to people who need to file federal taxes but are not eligible for a Social Security number. ITIN holders include people with different immigration and residency circumstances; possession of an ITIN should not by itself be treated as proof of unlawful presence.
The reported procurement is significant because a federal court had already blocked an arrangement under which the IRS would directly share taxpayer information with the Department of Homeland Security. Senator Ron Wyden told 404 Media that buying related information from a private broker appeared to be an end-run around taxpayer-privacy law and the court’s order.
That is an allegation about the apparent purpose and legal effect of the contract, not a final judicial ruling on the procurement itself. But the mechanism raises a policy problem that extends well beyond immigration enforcement: a restriction on direct government access may provide little protection if an agency can purchase the same or similar information from a commercial intermediary.
Data brokers rarely sell only a single raw field. Commercial products can link identifiers to names, addresses, phone numbers, relatives, property records, employment information, location histories, or other records. Even when each source began as a separate administrative or commercial record, the broker’s value comes from connecting them.
That creates a form of policy laundering. Government may be barred from compelling one agency to disclose a sensitive record, yet still acquire a commercially assembled product that reveals or predicts substantially the same information. The practical safeguard therefore has to regulate acquisition, not merely direct sharing.
Why it matters for Oregon: Oregon has already recognized that data-broker relationships can become immigration-enforcement pathways. But the broader lesson applies to every public body: laws and contracts should address broker purchases, enrichment services, vendor-derived identifiers, downstream matching, retention, secondary use, disclosure to outside agencies, and deletion when authority expires.
Public officials should also ask vendors to document the origin of every data category they sell. “Commercially available” does not answer whether the original collection was consensual, accurate, current, lawful for the new purpose, or capable of correction.
Shared pattern
The SAVE case and the reported ICE procurement involve different institutions and different legal questions. One concerns federal databases repurposed for voter screening. The other concerns commercially acquired records used for immigration enforcement. The shared governance problem is the same: a limit on collection or direct sharing does not protect people if sensitive information can later be combined, purchased, or searched through another route.
The search layer is the policy layer. Whoever controls what questions the system can answer may possess more practical power than the institution that originally collected the data.
“In the pre-computer age, the greatest protections of privacy were neither constitutional nor statutory, but practical.”
— Justice Samuel A. Alito Jr., concurring, United States v. Jones (2012)
Eugene is moving from one surveillance dispute to a citywide governance system
Eugene City Councilors have directed staff to begin developing a broader policy for surveillance technology, moving the discussion beyond the city’s earlier controversy over Flock automated license plate readers.
The decision is important because it treats surveillance as a governance category rather than a series of unrelated purchases. Eugene is not currently debating whether to reactivate its Flock cameras. Instead, councilors are asking what rules should apply whenever any department considers a technology capable of identifying, tracking, recording, profiling, or analyzing people.
City staff reviewed approaches used by Portland, Berkeley, and San Jose. According to KLCC, several councilors were especially interested in San Jose’s risk-based model, which applies citywide and requires greater oversight when a proposed technology presents a higher risk to privacy or civil liberties. Portland’s process includes privacy-impact assessments during procurement and a public inventory of city technologies that can be used for surveillance.
Those models separate several decisions that are often blurred together.
An agency-use policy tells employees how to operate a system after it exists. A procurement rule asks what information must be disclosed before money is committed. A public-approval process determines when elected officials and residents should have a role. An oversight system requires reporting, audits, and review after deployment. A city can have one of these without the others.
That distinction helps explain why a police policy alone is not enough. A department may write careful rules for current uses while a contract permits vendor access, outside-agency sharing, future analytics, or automatic product upgrades. A procurement process may review price and legal compliance without examining civil-rights risk. A council may approve a device without knowing that later software changes can substantially expand what it does.
Eugene staff also identified a question many governments avoid: whether the city should review technology already in use. A forward-looking approval process can prevent new problems, but it does not reveal what departments already operate, what records those systems retain, what databases they connect to, or which vendors can access them. A citywide inventory is the starting point for meaningful governance because officials cannot oversee tools they do not know exist.
Eugene’s final policy has not been written or adopted. Staff said the process could take at least six months and may proceed in phases, particularly if the city reviews existing systems and department-specific rules. Councilors also called for meaningful public participation, which could extend the timeline.
That is not a weakness. Surveillance policy should not be rushed merely because technology procurement usually moves quickly. The purpose of a durable framework is to decide the rules before the next vendor presentation, grant deadline, emergency request, or contract renewal compresses the decision.
Why it matters for Bend: Bend’s current ALPR debate demonstrates the limits of reviewing one administrative policy or contract at a time. A durable, CCOPS-aligned process should apply before surveillance technology is purchased, activated, expanded, connected to another system, renewed, or upgraded with a materially new feature.
At minimum, that process should require:
- a citywide inventory of existing and proposed systems;
- a plain-language description of capability, not merely the product name;
- a privacy and civil-rights impact assessment;
- the proposed purpose and prohibited uses;
- data sources, retention, sharing, and vendor access;
- security architecture and breach responsibilities;
- independent audit requirements;
- public reporting on use, searches, errors, complaints, and misuse;
- fresh approval before significant expansion or integration.
Eugene’s approach should not be treated as proof that its eventual policy will be perfect. Its value is that the city is asking the right institutional question: how should surveillance be governed across the whole government before the next tool becomes a fait accompli?
Kansas City plans to turn bus cameras into live identity searches
Kansas City’s transit authority is preparing to add facial-recognition software to cameras on public buses. Images of passengers would be compared in real time against active alerts for banned riders, missing persons, and people on law-enforcement watchlists designated by the transportation authority.
That is a meaningful change in function. A conventional security camera records what occurred so footage can be reviewed later. Live facial recognition asks a different question about everyone entering the camera’s view: does this face match someone on a list?
The Missouri state government declined expected funding because of concerns about the facial-recognition component, but the project is moving forward with local and federal funding. The initial deployment has been delayed, not abandoned, and could eventually reach as many as 30 buses.
The vendor says facial data associated with nonmatches will not be retained. That is a relevant safeguard, but it does not resolve the main governance questions. The transit authority reportedly may retain ordinary bus footage locally for as long as five years. More important, deletion of a nonmatching template does not determine who can be placed on a watchlist, what evidence supports the placement, how long someone remains listed, or how a person can challenge an error.
“Banned rider” can also cover very different circumstances. A narrowly documented temporary exclusion after a serious assault is not the same as an indefinite administrative list built from complaints or disputed conduct. Missing-person alerts may involve people who need assistance, but they also raise questions about consent, family conflict, and whether every reported missing adult should trigger automated identification. Law-enforcement lists may range from judicial warrants to investigative interest that has never been tested in court.
A facial-recognition match should not itself justify detention, removal, questioning, or adverse action. Systems can be wrong because the image is poor, the watchlist record is outdated, the algorithm performs unevenly, or two people look similar. Human review helps only when the reviewer receives independent information and is expected to challenge rather than confirm the machine.
Why it matters locally: Cities increasingly add analytics to cameras that were approved for more limited purposes. Officials may hear that “the cameras already exist” or that the change is merely a software upgrade. But converting recording equipment into a live identification system is a new surveillance decision and should require a new public review.
Before deployment, officials should define eligible watchlists, evidentiary standards, maximum listing periods, independent accuracy testing, confirmation procedures, prohibited uses, notice and appeal rights, retention, audit access, and the approval required for expansion.
The oversight question is not simply whether the technology works
A system may correctly identify many people and still be poorly governed. The deeper questions are who defines success, which errors count, who bears the consequences, and whether a limited pilot can become permanent infrastructure without another vote. The safeguard is to establish those rules before the first live search, not after the first public controversy.
“Awareness that the Government may be watching chills associational and expressive freedoms.”
— Justice Sonia Sotomayor, concurring, United States v. Jones (2012)
Warning Signals
These items point toward where identity systems, vendor platforms, and searchable public records may be heading next.
Age verification is advancing through both legislation and litigation
House Energy and Commerce Committee leaders released revised bipartisan text of the Kids Internet and Digital Safety Act, or KIDS Act, on June 22. The measure has not passed the House, but its age-verification language is now concrete enough to evaluate.
Title I would apply to publicly accessible platforms where more than one-third of the material is sexual material harmful to minors. Those services would have to use commercially available technology to determine whether a user is likely a minor and prevent minors from accessing the covered material. A user simply checking a box or stating that they are an adult would not be sufficient.
The bill contains several safeguards that should be recognized rather than ignored. Verification data could not be collected, used, transferred, disclosed, or retained beyond what is strictly necessary for the age check. Platforms could hire outside verification providers but would remain legally responsible. Reasonable administrative, technical, and physical security would be required. The text also says it does not require submission of government-issued identification.
Those provisions reduce some risks, but they do not determine the actual architecture. Platforms would choose the specific verification technology, subject to statutory requirements. The difference between a privacy-preserving age token, a facial estimate, a credit-history check, a phone-account signal, and an identity-document upload is substantial. So is the difference between learning only “over 18” and retaining enough information to link an age decision to a persistent account.
The bill would require a Government Accountability Office review after implementation, including effectiveness, privacy, security, and effects on speech and behavior. That is useful, but it would occur after verification systems have been deployed. Legislators should also require testing, transparency, and independent review before broad implementation.
At the same time, emergency applications remain pending at the U.S. Supreme Court over Texas’s App Store Accountability Act. The Texas law reaches more broadly by requiring app stores to determine users’ ages and obtain parental consent before minors download applications. Applicants are asking the Court to undo a Fifth Circuit stay that allowed the law to take effect while constitutional litigation proceeds. Texas filed its response June 22, additional briefs were filed through June 23, and no order was listed as this issue was prepared.
The federal bill and the Texas case should not be treated as interchangeable. One targets access to a defined category of adult material; the other makes an app store an age and parental-permission gatekeeper across the application ecosystem. The comparison shows why the mechanism matters as much as the stated objective.
Oregon’s question should be architectural: Which services must request an age signal? Does the system return only a broad category, or a persistent identity record? Who keeps the evidence? Can it be reused, sold, linked, or subpoenaed? Can adults continue accessing lawful speech anonymously? How are mistakes corrected? Who is responsible when a child is classified as an adult—or an adult is locked out as a child?
An age estimate can become a legal decision
The United Kingdom plans to use facial-age estimation in 2027 to help assess the ages of asylum seekers who lack documents. Internal government testing obtained by WIRED, Lighthouse Reports, and The Independent shows why that use is materially different from an age estimate used to suggest child-friendly settings.
The testing reportedly found that systems regularly mistook some children for adults and performed worse for people from Sub-Saharan Africa. For female Sub-Saharan African subjects, the estimated age was off by an average of 4.6 years—enough, in a borderline case, to classify a child as an adult.
That error can affect detention, housing, legal protections, and access to services. The system is not merely recommending content; it is helping place a person on one side of a legal boundary.
High-stakes age estimation should therefore never be decisive on its own. Governments should publish performance by age and demographic group, disclose uncertainty rather than a falsely precise number, prohibit adverse action based solely on the estimate, provide independent review and appeal, and limit retention and reuse of facial images.
The lesson applies to Oregon even if the proposed system is less consequential. Technology that produces an age category is making a probabilistic judgment. Policy must be designed around the possibility that the judgment is wrong.
Axon Watch: Records is making linked people and vehicles easier to surface
Axon’s June 16 Records update changed incident and standalone-report search results so they display linked people and vehicles. Incident cards also show the roles those people and vehicles played.
That may save officers and records staff time. It also makes relational information more visible at the search stage. A person who was a witness, reporting party, passenger, property owner, or otherwise associated with an incident can become easier to surface across repeated queries even when the person was never suspected of wrongdoing.
Axon has additional changes scheduled for June 30. Those include saved search configurations, searches using attached evidence identifiers, improved searches by report author, a report-redaction tool, and audit-log timestamps precise to hundredths of a second. The redaction tool and more precise logs may strengthen accountability when permissions and review are well designed. Saved searches and broader search options increase the need to govern recurring queries.
Public agencies should ask:
- Which roles may search, export, redact, or save queries?
- Must a query include a case number or documented purpose?
- Can a saved search repeatedly surface records about uninvolved people?
- Are searches and exports visible to supervisors and independent auditors?
- Who may change redactions, and is the reason recorded?
- Are new search features enabled automatically or activated after agency approval?
- Does a contract treat a materially expanded search capability as a new feature requiring policy review?
Procurement should not freeze its analysis at the product’s capabilities on signing day. Platform software changes over time, and the search layer can expand without a new camera, device, or contract headline.
Madison Square Garden reportedly cataloged critics of facial recognition
404 Media reports that Madison Square Garden compiled a document containing public comments and social-media posts from people who criticized the venue’s facial-recognition program. The document was found in a 45-gigabyte cache of company data stolen by hackers and later reviewed by the publication.
The reporting does not by itself establish what MSG intended to do with the list. But the existence of a document titled around facial-recognition activists illustrates a serious governance risk: the institution operating a surveillance system may also possess the ability to catalogue the people challenging that system.
Public criticism is part of oversight. It should not become a reason to add someone to an internal profile, watchlist, access restriction, or enhanced-surveillance category. Organizations using biometrics should adopt explicit rules prohibiting retaliation or heightened monitoring based on protected criticism, advocacy, journalism, or legal representation.
Direction of travel
This week’s Signals point toward identity becoming a reusable query. Age systems estimate whether someone is a child. Facial recognition asks whether a rider appears on a list. Records platforms surface associated people and vehicles. Institutions can compile information about critics. The safeguard is not only collecting fewer data. It is narrowing what questions systems are allowed to answer—and ensuring that every consequential answer can be examined, challenged, and corrected.
Safeguards
The strongest protections this week are structural: govern the search, bind the vendor, preserve correction rights, and make misuse provable.
Write the warrant rule, audit access, and termination right into the contract
Shaker Heights, Ohio, has amended its Flock Safety contract and adopted access rules that offer a concrete example of turning privacy promises into enforceable terms.
The city says Flock may not access, preserve, use, or disclose Shaker Heights data to a government authority or other third party without a court-issued search warrant. The contract rejects disclosure based merely on subpoenas, administrative demands, informal inquiries, preservation letters, national-security letters, investigatory convenience, generalized public-safety claims, or the vendor’s own contractual interests.
The vendor must provide prompt written notice before disclosure and give the city an opportunity to seek protective relief. Flock must also make reasonable efforts to resist, narrow, quash, or otherwise challenge legal process that conflicts with the contract.
The city receives on-demand access to audit logs covering searches by users inside and outside Shaker Heights. If Flock violates the assurances, the city may terminate without penalty and receive a refund.
Shaker Heights also limited access so that no federal agency, agency outside Ohio, or agency participating in a 287(g) immigration-enforcement agreement may search the city’s data. The city contacted 434 jurisdictions that had requested access and required them to agree to the restrictions. Its internal police policy requires searches to be connected to a specific department case number or undercover case identifier.
These provisions do not answer every concern. The city still operates 18 license plate readers, and local officials and residents must still evaluate camera locations, retention, authorized purposes, effectiveness, errors, audit review, and whether the network should continue. A contract is not a substitute for legislation, public oversight, or constitutional limits.
But it shows what it means to negotiate rather than accept vendor boilerplate. “We own the data” is not enough if the vendor can respond to demands, preserve records, permit outside searches, or change access without meaningful city control.
A practical procurement checklist for Bend:
- What legal process must the vendor require before disclosure?
- Must the city receive advance notice?
- Is the vendor required to resist or narrow an improper demand?
- Can the city inspect every internal, external, and vendor search?
- Are outside agencies denied access by default?
- Must each local search include a case number and purpose?
- Does the contract prohibit sales, demonstrations, model training, or product development using city data?
- What happens if the vendor violates the rule?
- Can the city terminate without penalty and obtain deletion certification?
- Do materially new features require affirmative approval before activation?
Good contract language cannot prevent every abuse. It can make improper access harder, more visible, and legally consequential.
Outsourcing a public service does not outsource responsibility for the data
Texas Parks and Wildlife reported that an unauthorized actor may have obtained personal information belonging to more than three million hunting and fishing license customers through the vendor that operates the state’s licensing system.
The potentially exposed information included driver-license data, passport numbers when supplied, email addresses, phone numbers, and residential addresses. The agency said Social Security numbers, birth dates, and financial information were not obtained. Texas Cyber Command detected the incident, and the agency says it and the vendor have strengthened access controls and monitoring.
The incident demonstrates why a vendor-operated portal remains public infrastructure. Residents did not choose the contractor or negotiate its security practices. They provided information because the state required or requested it to deliver a government service.
Before a vendor receives resident data, a public contract should identify every data field collected and why it is necessary. It should define privileged-access rules, multifactor authentication, encryption and key control, logging, monitoring, subcontractors, vulnerability management, incident-notification deadlines, evidence preservation, public communication, deletion at contract end, and responsibility for remediation.
Officials should also ask whether a less sensitive identifier would work. A system cannot leak information it never collected or retained.
Patch the system—and invalidate what attackers may already have stolen
CISA confirmed active exploitation of a critical Splunk Enterprise vulnerability that can allow an unauthenticated, network-reachable attacker to create or truncate files through an exposed PostgreSQL sidecar endpoint. Splunk urged customers to upgrade fixed versions, and CISA imposed an accelerated deadline on federal agencies. Where immediate patching is impossible, disabling the affected sidecar service can remove the attack path, although it may disrupt dependent pipelines.
Splunk deserves special attention because organizations often use it to collect the logs needed to understand other security incidents. If the monitoring system is compromised, altered, or unavailable, defenders may lose both operational capability and evidence.
The week’s Fortinet warning adds a second lesson. CISA said compromised credentials associated with roughly 74,000 firewall and VPN devices had been exposed and used in attacks. This was not simply a reminder to install a patch. Credentials, active sessions, tokens, and keys stolen earlier can remain useful after vulnerable software has been updated.
The practical response is broader:
- inventory affected and internet-exposed systems;
- patch supported versions;
- disable vulnerable services when patching must be delayed;
- rotate administrative and VPN passwords, keys, tokens, and service credentials;
- terminate active sessions;
- enforce phishing-resistant multifactor authentication where possible;
- remove management interfaces from the public internet;
- inspect successful logins, new accounts, configuration changes, and lateral movement;
- preserve critical logs outside the potentially compromised monitoring environment.
Patching closes a software flaw. Incident response must also invalidate what an attacker may already possess.
Make privacy rights operational
Vermont enacted S.71, now Act 145, adding another state model for consumer privacy and online-surveillance regulation. The specific provisions will matter, but the larger design lesson is that privacy rights work only when people can realistically exercise them and regulators can enforce them.
A statute should identify who is responsible, create understandable request and correction processes, limit secondary use, provide implementation guidance, fund enforcement, and require records that allow violations to be proven. A right buried behind separate requests to hundreds of companies is much weaker than a right supported by a centralized or standardized process.
Bottom line
This week’s stories are connected by searchability. Sensitive data become more powerful when agencies can combine records, vendors can sell access, cameras can identify faces, and software can surface relationships across incidents.
The strongest safeguards govern that power directly: define the permitted purpose, require a case number or legal basis, limit the datasets and watchlists, give people a meaningful way to correct errors, log every search, let an independent reviewer inspect those logs, and make vendors contractually responsible when they cross the line.
Collecting less remains essential. But once data exist, the next safeguard is controlling what the system is allowed to reveal.
Leave a Reply