Author: Jonathan

  • Signals & Safeguards Issue 17: Flock’s Trust Problem, New Jersey’s Data-Broker Law, and Redmond’s Bundled Surveillance Contract

    Signals & Safeguards

    Issue 17 • Wednesday, July 15, 2026

    A concise weekly scan of surveillance, privacy, cybersecurity, and the safeguards public officials should keep in view.

    At a Glance

    • LAPD’s audit findings and continuing Flock contract dispute show why surveillance-vendor assurances must be converted into configurations, logs, and contract terms that an independent reviewer can test.
    • The Seventh Circuit rejected Clearview AI’s unusual biometric settlement because differently situated class members did not have adequate representation.
    • New Jersey prohibited sales of sensitive data, while new research shows why privacy rights still fail when each data broker controls its own opt-out and deletion process.
    • Redmond’s $410,762.16 Axon award includes six Skydio drones, 38 vehicle fleet-camera upgrades, and DroneSense livestreaming—and the department already operates fixed Axon plate readers—showing why bundled technology contracts need a complete capability and data-flow inventory.

    Flock’s trust problem is now a governance problem

    The American Civil Liberties Union has assembled a national record of instances in which it says Flock Safety gave police departments, elected officials, or the public inaccurate or misleading accounts of how its automated license plate reader network operates. The July 2 analysis points to disputes involving federal access, national searches, product capabilities, camera status, sharing settings, and vendor control.

    The document is advocacy, not an adjudication. Its most serious examples should therefore be read alongside underlying records and the affected jurisdiction’s response. But the pattern matters even before every disagreement is resolved. A surveillance vendor is not selling an ordinary office product. Its descriptions can determine whether officials approve deployment, what a policy prohibits, what the public believes is possible, and whether a later audit is designed to detect the right risks.

    Issue 16 described how Woodburn learned that its cameras had appeared in broad outside-agency searches through a pilot architecture city officials said they had not knowingly approved. The broader warning is that officials cannot assume contract language, dashboard labels, or a verbal assurance fully describe the live system.

    That problem is especially serious in a networked platform. A local agency may control its own users while the vendor controls hosting, software updates, administrator privileges, integrations, federation rules, default settings, and the practical meaning of a feature name. A city may prohibit national sharing yet remain exposed through a pilot, external search path, inherited configuration, support account, or later product update.

    The clearest example arrived in Los Angeles. In a review of two months of LAPD automated-license-plate-reader activity, the Los Angeles Police Commission’s Office of Inspector General found that ALPR activity contributed to recovery of 337 stolen vehicles. It also identified 161 alerts that officers initially treated as matches to stolen vehicles but that later proved inaccurate. That is not a general error rate across every plate scanned, and the public report does not establish that every inaccurate alert resulted in a vehicle stop.

    The review covered LAPD’s larger, multi-vendor ALPR environment rather than Flock cameras alone. Flock operated 138 pole-mounted cameras within a department-wide network of roughly 2,000 readers. The governance lesson is not that one percentage fully measures one vendor. It is that an independent reviewer could reconstruct alert handling, identify inaccurate matches, and examine data-sharing and contract risks across the system.

    LAPD then allowed its three-year Flock agreement to expire and suspended ordinary access while negotiating stronger terms involving privacy, security, data ownership, and sharing. The Los Angeles Times reported on July 14 that negotiations continue, so the lapse should not be treated as a final decision to abandon Flock. The Police Commission separately supported suspending new Flock deployments and contracts pending additional oversight and public input.

    This is why public bodies should treat material vendor representations as testable contract requirements. Before approval, officials should require a live demonstration of every sharing and administrator screen, a diagram of all local, outside-agency, vendor, and subprocessor access paths, and an export showing the exact audit fields generated by each action.

    The contract should attach the approved configuration, prohibit silent changes, and require written notice and affirmative approval before a pilot, integration, network expansion, administrator role, or new search mode touches local data. It should require preservation of evidence when a disputed representation arises and permit independent technical review. A vendor’s failure to produce the agreed audit evidence should itself be a material breach.

    Why it matters for public officials: Oversight cannot depend on asking the same company that designed the system whether the system complies. The agency needs technical controls and records that allow someone else to reconstruct what happened.

    A practical verification test: Can the agency independently identify every person and organization that searched, viewed, exported, shared, administered, or changed the system—including vendor staff—and can it prove that prohibited access was technically blocked rather than merely discouraged by policy?


    Clearview settlement fails on who represented the class

    The U.S. Court of Appeals for the Seventh Circuit has vacated approval of an unusual nationwide settlement involving Clearview AI. Instead of conventional cash relief, the agreement would have given class members a financial interest tied to about 23 percent of the facial-recognition company’s future value.

    The court did not hold that an equity-like remedy is inherently improper, and it did not decide the underlying biometric-privacy claims. It also did not require additional injunctive relief. The decisive problem was procedural: the settlement created much larger potential benefits for favored state-law subclasses, but the nationwide class lacked representatives who could adequately protect the interests of people in those different groups.

    The case now returns to the district court. The policy conflict remains important. A privacy remedy should compensate affected people and constrain unlawful conduct without making their recovery depend on the future commercial success of the very surveillance practice being challenged.

    For public officials, the lesson is not limited to class actions. Remedies should be evaluated operationally: What conduct stops? What data are deleted? What future collection is restricted? Who receives compensation? Who can enforce the agreement? A settlement can be creative without being accountable.

    “We cannot get past a key procedural problem in the settlement process.”

    — U.S. Court of Appeals for the Seventh Circuit, In re Clearview AI, Inc. Consumer Privacy Litigation (2026)

    New Jersey moves upstream—but privacy rights still need a working compliance system

    New Jersey enacted A5328 on June 30 as P.L. 2026, c.25. The law prohibits selling, offering to sell, or licensing sensitive data and directs the state to create a public registry for data brokers and a newly defined category of data collectors.

    The sensitive-data sales prohibition took effect immediately. The registry provisions are delayed for 270 days and are scheduled to become operative on March 27, 2027. That timing distinction matters: New Jersey has already made the upstream policy choice that covered sensitive information cannot be sold, even though the registration system is not yet operational.

    The prohibition is structurally important because it applies regardless of how many consumers’ records an entity controls or processes and regardless of whether the seller would otherwise fall within the New Jersey Data Privacy Act’s usual thresholds. That avoids a common weakness in privacy statutes: numerical thresholds that leave smaller but highly sensitive datasets outside the rule.

    The law’s definition of sensitive information reaches categories that can expose a person’s body, beliefs, associations, movements, and vulnerability. The precise exceptions, registration disclosures, fees, and enforcement provisions will matter in implementation, but the central policy choice is clear: some data should not become a commercial product merely because a company can collect or infer it.

    This advances the data-broker discussion from Issue 16. A warrant requirement or procurement restriction controls the government buyer. A sales prohibition controls the market that supplies the buyer. Neither approach is complete by itself.

    If government cannot compel sensitive location information without judicial process but can buy a commercially assembled substitute, constitutional protection becomes dependent on the acquisition route. If a state prohibits government purchases but permits unrestricted commercial sale, the same information remains available to private investigators, employers, insurers, landlords, political operatives, abusive partners, and intermediaries that may later sell to government.

    An upstream rule also reduces the burden placed on individuals. A person should not have to identify hundreds of hidden companies, submit separate requests, disclose more identity data, and repeatedly opt out of a market they never knowingly joined.

    Rights on paper still fail at the doorway

    A July UC Irvine study using synthetic identities found that opt-out and deletion processes among California-registered data brokers remained inconsistent, burdensome, and sometimes ineffective. Researchers reported nonresponses, intrusive verification demands, and substantial variation in how requests had to be submitted. These are research findings rather than enforcement judgments, but they test what consumers actually encounter when trying to use rights that exist on paper.

    A separate large-scale study of registered brokers found that only 9 percent of 522 brokers were fully compliant with transparency requirements. In an audit of 250 consumer-request processes, 43 percent made it impossible to exercise all privacy rights and 64 percent introduced at least one feature that created substantial friction.

    Together, the studies illustrate a recurring design failure: the regulated company controls the doorway through which a person must pass to invoke the right against that company.

    The consumer may not know the broker exists. The broker may demand identity documents that create new risk. Names, addresses, emails, and phone numbers may not match the records the broker bought. A deletion request may remove one profile while another affiliate, source, or later purchase recreates it.

    The better model is centralized and testable. California’s Delete Request and Opt-Out Platform provides a developing example: one verifiable request can direct registered brokers to delete covered information, with broker processing requirements beginning August 1, 2026. A state can also prohibit unnecessary identity collection, publish response rates, conduct regulator-run test requests, and impose consequences when firms do not respond or reacquire deleted data.

    Officials should distinguish deletion from suppression. A company may stop displaying a profile while retaining data, hashes, linkage keys, derived attributes, or source relationships that allow the profile to reappear. A meaningful deletion standard should specify what must be erased, what may be retained for legal compliance, how downstream recipients are notified, and how completion is certified.

    A registry should make the market inspectable

    A useful registry should identify each broker’s legal and trade names, parent and affiliates, categories of data collected, original sources, customer categories, sensitive-data practices, government clients, opt-out and deletion methods, retention periods, security incidents, and whether the company honors universal opt-out signals.

    Registration alone is not validation. Regulators should compare claims against sample transactions, consumer requests, website behavior, contracts, and technical data flows. Repeated failure should lead to escalating penalties, suspension from the market, and notice to downstream customers.

    Public agencies should consult the registry before purchasing or accepting commercially sourced data. Procurement files should identify the original collector and every intermediary, not merely the company that signed the government contract.

    The combined safeguard: Restrict collection and sale of sensitive data upstream; require a warrant or equivalent judicial process for government acquisition downstream; and prohibit contractors or partner agencies from doing indirectly what the public body may not do directly.


    The larger risk is what happens when separate databases become one system

    A July 9 Brennan Center report warns that federal agencies are increasingly linking government records with commercially acquired location, biometric, financial, social-media, and other personal information. The report describes the Department of Homeland Security as an emerging hub for this consolidation and says AI-assisted analysis can turn records collected for unrelated purposes into searchable profiles of people’s movements, relationships, beliefs, and activities.

    The warning reaches state and local government. Driver’s-license, benefits, voter-registration, law-enforcement, and other records may be requested or shared for purposes far removed from the reason they were originally collected. Protecting one local database is not enough if its contents can become an input to a much larger federal or commercial system.

    Why it matters for public officials: Data-sharing agreements should state the permitted purpose, prohibit onward transfer and unrelated reuse, require notice and audit records for outside requests, and allow access to be suspended when the receiving agency changes how the information will be used.

    Flock shows why officials need visibility into a vendor’s network and administrator actions. Clearview shows why a remedy must fairly represent differently situated people. Data-broker regulation shows why the original collector and every intermediary matter. Data consolidation shows why risk grows again when once-separate records become one searchable system.

    In each case, accountability fails when review stops at the nearest interface: the local dashboard, the named defendant, the final seller, or the written policy. The safeguard must follow the system from collection through processing, sharing, decision, remedy, and deletion.

    Data minimization includes separation: Before linking systems, document the original purpose and legal authority for every dataset, the people and agencies receiving access, the risks of inaccurate matches, and the conditions for ending the connection.


    Local Watch

    A closer look at how a bundled local purchase connects drones, vehicle cameras, license-plate readers, and livestreaming.

    Redmond adds drones and fleet cameras to an existing Axon surveillance ecosystem

    On June 23, the Redmond City Council approved a five-year, $410,762.16 award to Axon Enterprises and Skydio. The official council packet, pages 76–77, describes two Skydio R10 indoor drones, four Skydio X10 outdoor drones, software for livestreaming and integration with patrol and SWAT operations, and 38 Axon vehicle fleet cameras. The vehicle cameras will expand patrol-car coverage from two views—front-facing and rear-seat—to three by adding a rear-facing camera.

    The agreement also provides for six new drones at the 30-month mark while allowing Redmond Police to retain and use the original six. If the first group remains operational, the department could have as many as 12 Skydio aircraft after the refresh rather than simply exchanging old equipment for new.

    The staff report identifies $100,000 in General Operating Fund reserves for implementation. The remaining payments are scheduled unevenly: $70,256.02 in fiscal year 2026–27, $8,265.41 in 2027–28, and $110,746.91 in each of the following three fiscal years. Because the public packet contains the police staff report rather than the executed agreement and itemized vendor quote, it does not disclose every software license, storage term, administrator role, or data-control provision included in the award.

    The purchase sits inside a larger Axon environment

    Redmond Police already uses Axon body-worn cameras, vehicle cameras, interview-room cameras, Evidence.com, and fixed license-plate-reader cameras, according to the staff report. The new award therefore adds drones and expanded vehicle-camera coverage to an existing evidence and plate-reader environment rather than creating a stand-alone UAS program.

    That distinction matters because surveillance capabilities can be shaped by how separate tools work together. A fixed plate reader may identify a vehicle and location; dispatchers or officers may then use patrol cameras or a drone to follow the response. The staff report does not say that Redmond currently connects fixed-LPR alerts to drone deployments, but both systems are now part of the department’s technology environment and should be governed as a combined workflow when they interact.

    Skydio says the X10’s VT300-Z telephoto package can resolve a license plate from approximately 800 feet under suitable conditions. That is an optical capability: the camera may capture an image in which a plate is legible. It is not, by itself, automated plate recognition, optical-character recognition, or a database search.

    Skydio separately describes drone-response systems that can receive alerts from third-party ALPR platforms. In that type of workflow, the fixed reader produces the plate match and the drone supplies aerial observation. Public records should make clear whether Redmond has enabled such a connection, what legal and policy rules apply, who may authorize a deployment, and what audit trail links the original plate alert to the drone mission.

    DroneSense carries the livestream

    The staff report names DroneSense as the livestreaming platform used by Redmond Police and SWAT during critical incidents and investigations. Redmond’s published UAS information says the department does not store data obtained by a UAS in third-party storage and has no UAS data-sharing agreements with outside agencies.

    Livestreaming through a third-party platform does not necessarily mean that the provider permanently stores the video. It does mean the department should publicly document how the stream is secured and handled: whether DroneSense buffers or retains video or metadata; who can receive a stream; whether recipients can record it; how viewers are authenticated; whether access expires automatically; what viewer logs are created; and where flight telemetry, operator identity, and incident metadata are stored.

    The same records should show whether completed drone recordings enter Evidence.com, whether live feeds can be viewed through an Axon command interface, which company controls administrator settings, and how access is revoked when an incident ends.

    San Francisco shows the risk of weak sharing controls

    A recent San Francisco incident demonstrates why those details matter even when a department has a written security policy. WIRED reported that live feeds from five San Francisco Police Department drones were reachable through a public Skydio ReadyLink without a password or authentication code. The feeds included color and thermal video, real-time location information, and the names and email addresses of drone pilots.

    Researchers archived about 48 hours of activity: 60 videos from 20 flights showing detentions, searches, apartment windows, rooftops, streets, courtyards, unhoused people, and many bystanders who did not appear to be subjects of an investigation. The link had been set to remain active for a year and may have exposed the feeds for roughly six months.

    ReadyLink is not the platform named in Redmond’s staff report; Redmond identifies DroneSense. The control lesson nevertheless applies to any livestreaming system. Authentication, named recipients, short expiration periods, complete viewer logs, and automatic revocation should be mandatory defaults rather than options left to the person creating a link.

    The federal transition should be described precisely

    Redmond’s existing drone fleet includes foreign-manufactured Autel and DJI aircraft. The staff report cites the American Security Drone Act and related National Defense Authorization Act provisions as the reason for moving to U.S.-manufactured Skydio equipment.

    The federal restrictions are narrower than a general ban on commercial sales of all foreign-manufactured drones. Federal acquisition rules restrict federal agencies from procuring or operating covered systems and, beginning December 22, 2025, restrict the use of federal funds to procure or operate prohibited systems, subject to exceptions and waivers. Moving away from Autel and DJI may preserve federal-funding eligibility and reduce the risk that existing aircraft become harder to support, but the legal rule should not be described as a universal sales ban.

    Why it matters locally: Redmond’s award adds indoor and outdoor drones and 38 vehicle cameras to an environment that already includes fixed Axon plate readers, Evidence.com, and DroneSense livestreaming. Oversight should focus on the combined data flows and operational workflows, not only on the label attached to each product.

    Before fixed-LPR alerts are connected to drone response, live-feed access is expanded, storage or retention changes, remote or docked operations begin, or automated analysis is added, Redmond should require public notice, documented legal review, and approval proportionate to the new capability.

    Local verification test: Can Redmond produce the executed agreement, complete product and license inventory, data-flow diagram, fixed-LPR integration map, livestreaming settings, retention rules, viewer logs, and approval history needed to show that the combined system matches its published UAS commitments?

    “There’s a certain trust given to the police to use these things correctly.”

    — Security researcher Sam Curry, quoted by WIRED (2026)

    Warning Signals

    Warning Signals

    Early indicators of how connected systems, software transitions, and delayed maintenance can expand risk before policy catches up.

    Axon Watch: July 31 transition brings AI oversight questions

    Axon says that on July 31 the legacy Axon Evidence experience will be deprecated and the redesigned interface will become the only version available. The deadline does not establish that any AI product will automatically be licensed or enabled for Bend. Availability may depend on licensing, configuration, rollout status, and agency activation.

    But a mandatory interface change is still an oversight point. Officials should request a current feature inventory showing every AI-assisted capability available, licensed, enabled, or planned; the evidence it can analyze; the output it creates; retention and sharing; model providers and subprocessors; audit fields; human-review requirements; and whether activation requires notice, legal review, or Council approval.

    Council question: Which Axon capabilities will be available to Bend after July 31, which are enabled, and what record will show when a new analytical or AI-assisted function is activated?


    A federal information-sharing network was breached after warnings were twice dismissed

    According to Nextgov’s account of an internal Department of Homeland Security incident readout, intruders accessed the Homeland Security Information Network, a platform used to share sensitive but unclassified records with federal, state, local, and international partners, after analysts twice concluded that suspicious activity was a false positive. By the time officials declared a breach, the intruders had installed hidden backdoors and stolen credential files. Public reporting has not established exactly what information was obtained from HSIN.

    The same architecture that lets many agencies exchange information also lets one successful intrusion reach every connected partner. Any agency using a federal or regional sharing network should know who can close an alert, what independent verification occurs before suspicious activity is dismissed, and how partners are notified when the network may be compromised.


    Active exploitation turns maintenance into an emergency

    CISA warned on July 14 about active exploitation of Microsoft SharePoint vulnerabilities and urged organizations to harden affected systems. A vulnerability bulletin becomes a safeguard only when someone knows which systems are affected, has authority to act immediately, verifies that mitigation was completed, and checks whether attackers gained access before the patch.


    Safeguards

    Safeguards

    The strongest protections this week turn assurances into evidence, keep connected systems visible, and establish what happens when technology does not perform as promised.

    Turn vendor promises into enforceable specifications

    Attach the approved configuration, architecture diagram, sharing settings, administrator roles, audit fields, feature inventory, and data-retention schedule to the contract. Require a live demonstration before deployment and after material updates. A statement such as “national sharing is off” should identify every technical pathway the phrase covers, including pilots, federated searches, vendor support accounts, integrations, and inherited defaults.

    Require written notice and affirmative approval before a pilot, integration, new administrator role, subprocessor, network expansion, or policy-changing default touches local data. Preserve both the old and new configuration so reviewers can identify exactly what changed, who approved it, and when the change took effect. Contract remedies should include suspension, corrective work, fee recovery, and termination when a material representation proves false.

    Give the agency independent evidence

    The agency should be able to export complete, tamper-evident logs without vendor assistance. Logs should identify the user and organization, date and time, case number, purpose, legal authority, search terms, datasets, result count, exports, sharing, denied attempts, vendor access, administrator changes, and final disposition.

    The log format and required fields should be contract deliverables rather than whatever a dashboard happens to display. Assign someone outside day-to-day use of the system to review records on a fixed schedule, investigate anomalies, and document corrective action. Contract for independent technical testing, incident preservation, audit cooperation, and meaningful remedies. A vendor’s failure to produce required evidence should itself be a material breach.

    Govern integrations and live links before activation

    Maintain a current diagram of local users, outside agencies, vendor administrators, subprocessors, federated networks, application-programming interfaces, evidence systems, exports, backups, and legal-process pathways. For each route, specify who can authorize access, what purpose is allowed, what data leave the system, how long the connection lasts, and what evidence the action creates.

    Require authentication, short expiration periods, named recipients, viewer logs, and automatic revocation for every live video or data-sharing link. Prohibit public or reusable URLs for police-surveillance feeds and regularly test access from outside the government network. Limit recording and retention to the documented mission; a secure link can still expose unnecessary footage of homes, bystanders, and private spaces.

    Control sensitive data throughout the chain

    Prohibit the sale of sensitive location, biometric, health, communications, and association data upstream. Require a warrant or equivalent judicial authorization when government seeks the same information downstream, regardless of whether it comes from a carrier, platform, advertiser, broker, contractor, or partner agency. Ban indirect acquisition: a public body should not ask another agency or vendor to obtain information it could not lawfully obtain itself.

    Provide one state-run mechanism for access, correction, opt-out, and deletion requests. Define deletion precisely: address source data, derived attributes, linkage keys, backups, downstream recipients, later reacquisition, and certification. A profile that silently reappears was not meaningfully deleted. Before combining datasets, document each source’s original purpose, legal authority for reuse, receiving agencies, matching risks, and the conditions for ending the connection.

    Review software capabilities before deadlines and updates

    A mandatory interface transition should trigger a feature and policy review. Identify every analytical or AI-assisted tool available, licensed, enabled, or planned; the data it can ingest; the output it creates; retention and sharing; model providers and subprocessors; auditability; and the human decision that remains accountable.

    Do not treat interface availability as authorization. New summarization, search, identification, prediction, streaming, remote-operation, or automated-dispatch capabilities should require documented legal review and approval proportionate to their effect. The system should record who activated each feature, the governing policy, the effective date, and whether the feature can be disabled without losing access to unrelated functions.

    Patch, investigate, and plan for failure

    Maintain a current inventory of internet-facing services and unsupported equipment. Assign emergency patch authority, restrict management access, enforce strong authentication, preserve logs, and review for indicators of compromise after active exploitation is announced. Installing an update does not establish that attackers were not already present; agencies should document what was exposed, how far investigators looked back, and why they concluded the environment is safe to return to service.

    For every sensitive system, name who can suspend use, preserve evidence, notify affected people, correct records, commission an independent review, and terminate the contract. Define what must be reported to elected officials and the public after unauthorized access, inaccurate matches, vendor nonperformance, or a policy-changing software update. The morning after an incident is too late to decide who has authority to stop the system.

    Bottom line

    Trust is not an audit. A safeguard exists when an independent reviewer can test the representation, reconstruct the action, identify the responsible person, correct the error, and impose a consequence.

    The common question for Issue 17 is simple: What evidence would prove that the system did what officials were told it would do?

  • Request to pull July 15 agenda items 4D and 4F for brief discussion

    Mayor Kebler and Members of the Bend City Council,

    On behalf of Bend Privacy Alliance, I am writing to request that consent-agenda items 4D and 4F on the July 15, 2026 agenda be pulled for brief public discussion.

    We are not asking the Council to reject either item. We are asking for basic public clarification about the security and privacy protections associated with two systems that will hold or generate potentially sensitive information.

    Item 4F concerns the purchase of Aclara water-meter transmission units. The supporting materials indicate that these devices can generate hourly, time-stamped household water-use readings and support on-demand readings. Data at that level of detail can reveal occupancy and household activity patterns.

    Before authorizing a five-year purchase, we ask the City to publicly explain:

    • How long hourly household readings are retained.
    • Who may access individual household histories.
    • Whether the transmissions and stored data are encrypted.
    • Whether access is logged and periodically audited.
    • Under what circumstances the data may be shared with law enforcement, contractors, landlords, insurers, researchers, or other agencies.
    • Whether the information may be used for purposes beyond billing, system maintenance, leak detection, and customer-requested services.
    • Whether Aclara or its subcontractors have remote access to Bend customer data.

    Item 4D concerns the ProjectTeam cloud platform for capital-project documents, workflows, financial records, contractor collaboration, and integrations with other City systems.

    The proposed data-protection addendum contains several encouraging provisions, including City ownership of its data, restrictions on sale and unrelated data mining, domestic data-storage requirements, incident-reporting obligations, and post-contract data destruction.

    However, the public packet does not clearly state whether:

    • Multifactor authentication will be mandatory for every City, contractor, and vendor account.
    • City data and backups will be encrypted in transit and at rest.
    • The City has reviewed an independent security assessment, such as a SOC 2 report or comparable audit.
    • External contributors will be governed by least-privilege access controls and complete access logging.
    • The hosting providers and subprocessors that may possess City data have been disclosed and reviewed.
    • The vendor maintains appropriate cyber-liability insurance.

    These may already be addressed through the City’s internal security-review process. A brief explanation during the meeting would give the public confidence that the privacy and cybersecurity implications were considered before approval.

    As more public services rely on connected devices and cloud platforms, procurement is one of the most important points at which the City can establish meaningful safeguards. Addressing these questions before approval is easier and less costly than trying to add protections after deployment.

    Thank you for your consideration and for making these issues part of the public record.

    Sincerely,

    Jonathan Westmoreland
    Bend Privacy Alliance
    Protecting privacy, transparency, and civil rights in Bend

  • Signals & Safeguards Issue 16: Location-Data Warrants, the Data-Broker Loophole, and Proving Safeguards Work

    Signals & Safeguards

    Issue 16 • Wednesday, July 1, 2026

    A concise weekly scan of surveillance, privacy, cybersecurity, and the safeguards public officials should keep in view.

    At a glance

    • The Supreme Court held that obtaining even two hours of precise Google Location History is a Fourth Amendment search.
    • Bend strengthened its ALPR policy, but the vendor audits needed to verify compliance had not yet arrived.
    • Bipartisan oversight caused ATF to cancel one commercial-location contract, while the broader data-broker loophole remains.
    • The House passed a broad youth-online-safety package, keeping age checks and data minimization at the center of the debate.

    Using an app is not consent to government access

    The Supreme Court has extended Carpenter‘s protection for cell-phone location records to a more precise form of digital location history – and rejected the idea that a short search or an “optional” smartphone feature falls outside the Fourth Amendment.

    In Chatrie v. United States, police investigating a Virginia bank robbery used a geofence warrant to make Google identify devices near the crime scene. Google first supplied anonymized data for 19 devices. Investigators selected nine for a broader two-hour view, including movement outside the original geofence, and then selected three users whose identities Google disclosed.

    The Court held that police conducted a Fourth Amendment search when they obtained Okello Chatrie’s Location History. That remained true even though the request covered only two hours and the records came from a technology company rather than directly from his phone.

    The majority explained why the information is unlike an ordinary business record. At the time, Location History could record a phone roughly every two minutes, locate it within about 20 meters, and sometimes estimate which floor of a building it occupied. A short slice could expose a home, medical visit, political gathering, school, hospital, or place of worship.

    The Government argued that the period was too brief and that Chatrie had voluntarily enabled the feature. The Court rejected both arguments. Fourth Amendment protection does not begin only after surveillance “goes too far,” and ordinary use of modern apps does not mean that private information is freely available to government.

    The duration issue matters because officers were not following a known suspect for two hours. They were selecting a short interval from an all-encompassing database after the fact. The Court reasoned that a system does not become less intrusive merely because government can use hindsight to choose the most revealing hours. Even one trip can expose a political rally, abortion clinic, criminal-defense lawyer, or other association a person reasonably expects to keep private.

    The Court also rejected an app-by-app version of the third-party doctrine. Google repeatedly prompted users to enable Location History, sometimes warning Android users that devices would not work correctly without it, while not fully explaining the frequency, precision, or potential government access. More broadly, the point of a smartphone is to use apps and cloud services. Sending email, storing photos, or adding a calendar entry should not become blanket consent for government access merely because a company hosts the data.

    The judgment was 6-3. Justice Elena Kagan wrote for five Justices. Justice Neil Gorsuch supplied the sixth vote through a separate concurrence reasoning that digital location history can be a person’s electronic “papers or effects,” even when a company stores it.

    The ruling is important but narrower than saying all geofence warrants are unconstitutional. The Fourth Circuit must still decide whether each stage of this warrant satisfied probable cause and particularity, and whether the good-faith rule affects suppression. Justice Ketanji Brown Jackson, joined by Justice Sonia Sotomayor, would have found at least stages two and three unconstitutional because officers – not a neutral magistrate – chose who received deeper scrutiny.

    Why it matters for public officials: A multi-stage search should not become progressively more intrusive through an internal vendor workflow. A judge should define the narrowing criteria and find probable cause before officials expand the time period, follow devices beyond the original location, or reveal identities.

    Google told the Court that it moved Location History storage from central servers to users’ devices in July 2025 and can no longer respond to this particular centralized demand. The old Google process may be fading, but the Court’s principle reaches a broader question: using an ordinary digital service does not itself surrender constitutional privacy.

    The decision therefore matters beyond geofences. Government databases increasingly allow officials to begin with a place, event, face, plate, device, or pattern and work backward toward a person. The constitutional question is not only whether a warrant exists at the beginning, but whether each material expansion remains tied to probable cause, particularity, and neutral review.


    Bend strengthened its ALPR policy. Now the system has to prove it follows it.

    Bend Police has expanded Policy 428 following Oregon’s new statewide rules for automated license plate readers. The revised policy adds privacy, accountability, and civil-rights language; states that Bend owns its database; and bars use for protected First Amendment activity, federal immigration enforcement, and out-of-state abortion investigations.

    Those are meaningful improvements. The remaining question is whether the technical system and vendor relationship can demonstrate compliance. Oregon law requires 30-day and quarterly vendor audits that agencies must publish promptly after receiving them. As of the June 29 reporting, Bend had not received the required reports from Axon and was working with the company on automated delivery.

    Until the audits exist, the public cannot examine which agencies queried the system, why they searched, or when the searches occurred. The policy calls for 30-day and quarterly reports to be posted quickly after receipt, which makes vendor delivery part of the safeguard rather than a back-office detail. An audit requirement that the vendor cannot or does not produce is not yet an audit system.

    The same distinction applies to encryption. Oregon’s law allows existing contracts to continue for a limited period even if they do not yet meet the new end-to-end-encryption rule, while new contracts and add-ons face the stronger standard. That makes procurement timing, feature activation, and key management important. Officials still need to know what is encrypted, who controls the keys, whether Axon can decrypt or export records, and how support, sharing, legal process, and exceptions are logged.

    Database ownership alone does not answer those questions. A city may “own” the records while a vendor controls the hosting environment, administrator privileges, software updates, integrations, or encryption keys. The practical test is whether Bend can independently inspect every local, outside-agency, and vendor action and can prevent access that conflicts with policy.

    Questions for the next review: Have the required audits arrived? Do they include case number, purpose, user, agency, date, data source, and result? Can Bend see vendor access? Who holds the decryption keys? What happens when a search is denied, an integration is added, or a new feature changes what the system can reveal?

    A written rule is an essential starting point. It becomes a safeguard when the system enforces it and leaves enough evidence for an independent reviewer to verify that it worked.

    “A new technology should not transform what individuals had reasonably thought they could withhold from the Government.”

    — Justice Elena Kagan, Chatrie v. United States (2026)

    Oversight stopped one warrantless tracking contract – not the underlying loophole

    The Bureau of Alcohol, Tobacco, Firearms and Explosives has canceled its contract for Penlink’s Webloc location-surveillance product after bipartisan congressional scrutiny. The cancellation is a concrete example of oversight changing agency behavior – but it also shows how much still depends on discovering one contract at a time.

    According to Senator Ron Wyden and Representative Michael Cloud, Webloc used location information originating in commercial advertising systems. ATF disclosed 341 searches: 55 for training or demonstrations, 64 related to violent-crime matters, and 222 associated with active case numbers.

    In one arson investigation near a defense contractor, the prosecutor and judge reportedly raised serious concerns about the warrantless commercial data. Investigators then obtained a traditional court order for bulk cell-tower information.

    ATF canceled the contract six days after a briefing in which congressional staff raised constitutional concerns, state-law restrictions, and Federal Trade Commission actions against sellers of sensitive location data. The agency also committed to reviewing other contracts for similar adtech-derived information.

    The episode shows why contract inventories matter. A surveillance capability can enter an agency as a subscription, analytics service, demonstration account, data-enrichment feature, or add-on to a broader platform. If officials and the public cannot see the product name, data sources, authorized uses, and query counts, there may be no practical opportunity to test legality before the tool is used in active investigations.

    It also shows that oversight can work. The contract was not canceled because the vendor voluntarily narrowed the product or because an internal policy review happened on schedule. It was canceled after lawmakers obtained records, asked how the data were sourced, compared the practice with constitutional and state-law limits, and forced the agency to explain specific searches.

    This story is related to Chatrie, but the legal routes are different. In Chatrie, government compelled a provider to disclose stored account information. With Webloc, an agency purchased commercially collected location data. The first route is governed by warrant and subpoena doctrine; the second is often called the data-broker loophole because agencies argue that information available for purchase can be acquired without the process normally required for a search.

    That distinction should not determine whether movements receive protection. A visit to a clinic, religious service, union meeting, political gathering, or private home does not become less revealing because the information reached government through an advertiser rather than a cellular carrier.

    A durable rule should follow the sensitivity and use of the data, not the route by which it was obtained. Otherwise, a warrant requirement can be bypassed by purchasing a commercially assembled substitute, and a restriction on one agency can be bypassed by a contractor or another agency with access to the same market.

    The safeguard: Require a warrant or equivalent judicial authorization for sensitive location information regardless of whether the source is a carrier, platform, advertiser, broker, or contractor. Agencies should also disclose the products they use, the legal process attached to each search, and the number and purpose of queries.

    A procurement test for commercially sourced data

    Before buying any investigative dataset, an agency should document the original collector, every intermediary, the collection method, consent or notice, accuracy controls, retention, permitted uses, opt-out process, and whether the seller obtained the information in compliance with law and platform rules. The contract should prohibit substitution of a new source without notice and review.


    Facial recognition cannot remain invisible when it helps identify a defendant

    The New Jersey Supreme Court has unanimously ruled that prosecutors must give criminal defendants basic information about facial-recognition technology used during an investigation – even when the State describes the result only as an investigative lead and does not plan to introduce the software output at trial.

    The case concerns Tybear Miles, who was identified as one of several possible matches after police submitted an Instagram image to a facial-recognition system during a murder investigation. Miles sought information about the system and its use so he could test reliability, examine whether police pursued other candidates, and challenge later identifications influenced by the initial search.

    The court rejected a rigid universal checklist but held that defendants generally must receive information identifying the tool and explaining how it was used in the investigation and prosecution. That basic disclosure can expose the source image, database, candidate list, analyst choices, investigative sequence, and possible alternatives to meaningful review.

    The distinction between a “lead” and evidence can be misleading. A facial-recognition result may never be shown to a jury, yet it can determine whose social-media account is examined, which person is placed in a photo array, which witnesses are re-interviewed, and which competing suspects receive less attention. Later evidence may appear independent even when the initial algorithmic match shaped the entire path of the investigation.

    The justices did not automatically require proprietary source code. A defendant seeking trade-secret material must first show a particularized need. The ruling therefore distinguishes between the minimum facts needed to test a government’s case and deeper technical discovery that may depend on the circumstances.

    That approach also avoids a false choice between total secrecy and unlimited disclosure of proprietary material. Agencies can preserve and disclose operational facts – the probe image, database, candidate rankings, thresholds, analyst steps, and corroboration – without assuming that every case requires the vendor’s source code. If those basic facts reveal a specific reliability problem, a court can then decide whether deeper technical material is necessary.

    The policy lesson is broader than one criminal case. Facial recognition should not be insulated from scrutiny merely by placing its output at the beginning of an investigation rather than in the trial exhibit list. An algorithmic lead can shape who police question, which images witnesses see, what evidence receives attention, and whether another candidate is ignored.

    The safeguard: Preserve the original probe image, all preprocessing, vendor and product version, database description, search settings, complete candidate results, analyst actions, and corroborating steps. Disclose that record early enough for meaningful review.

    What minimum disclosure should answer

    A useful record should show what image entered the system, how it was cropped or enhanced, which database was searched, what threshold or ranking method applied, how many candidates were returned, who reviewed them, and what investigators did next. It should also identify any witness procedure influenced by the result and preserve evidence about candidates who were not pursued.

    Shared pattern

    Congress could challenge Webloc because it learned the contract existed. A defendant can challenge facial recognition only if the State reveals that the tool was used. Oversight fails when the decisive system remains outside the record.

    Visibility is not paperwork. It is the condition that makes constitutional, contractual, and technical safeguards enforceable.

    For public bodies, that means maintaining a current surveillance inventory, publishing contracts and policies, recording each sensitive query, preserving investigative provenance, and giving an independent reviewer enough detail to reconstruct what happened. A safeguard that cannot be inspected or challenged is ultimately dependent on trust.

    Trade secrecy should not erase government accountability. Agencies may protect genuinely proprietary material while still disclosing the tool’s identity, data source, purpose, user, query terms, outputs, human decisions, and consequences. When a vendor cannot support that record, the product is not ready for a public-sector decision that affects liberty.

    “Such basic information will, in most cases, constitute the minimum necessary to safeguard a defendant’s right to a fair trial.”

    — Justice Douglas M. Fasciale, State v. Miles (2026)

    Warning Signals

    Warning Signals

    Early indicators of how surveillance expands: through network defaults, age checks, credential phishing, and reusable search tools.

    Woodburn’s experience shows why sharing architecture must be understood before deployment

    Woodburn has permanently removed its Flock Safety cameras after an audit showed that outside agencies – including federal immigration agencies – had been able to include Woodburn’s network in broad searches.

    The city’s public Q&A provides important context. It reports 3,318,618 searches during the period reviewed, but says 99.99% were multi-network searches rather than searches aimed only at Woodburn; 306 uniquely targeted Woodburn. Homeland Security Investigations and U.S. Border Patrol were among the federal agencies whose broader queries included Woodburn during a Flock pilot program that city officials say they had not been told about.

    The document says the city disabled national lookup in October 2025 and found no federal searches after June 24, 2025. But the most important fact is that Woodburn did not knowingly approve the pilot architecture that allowed its network to appear in those searches. The cameras were ultimately removed in May 2026 after the city ended the contract.

    That nuance does not erase the governance failure. It explains it. A local agency can believe it has not affirmatively shared data while a vendor’s network design silently makes its cameras part of a much larger search surface.

    Before deployment, officials should see the default sharing settings, national-search capabilities, pilot programs, vendor administrator access, notification rules, and every route by which a local database can be included in another agency’s query.

    They should also require a change-control rule: no pilot, federation, network expansion, integration, or new search mode should apply to local data without written notice, legal review, and affirmative approval. Vendor defaults are policy choices when they determine who can search a community’s records.

    The procurement lesson: Ask for a live demonstration of every sharing screen and administrator setting, then attach the approved configuration to the contract. Require notice before the vendor changes a default, joins a pilot, or makes local data searchable through a new network path.


    The KIDS Act clears the House – with age checks still the privacy fault line

    The House passed H.R. 7757, the Kids Internet and Digital Safety Act, on June 29 by a bipartisan 267-117 vote. The package now moves to the Senate and is not law. It combines proposals involving platform design, youth privacy, targeted advertising, AI chatbots, online games, data brokers, parental controls, audits, and research.

    The House package is not the same as the stronger KOSA framework the Senate passed in 2024, and key senators have criticized the compromise. That makes House passage a major status change, not a final policy settlement. Any Senate amendment would require further agreement between the chambers.

    The age-verification provisions require careful attention. The SCREEN Act title directly requires covered platforms substantially devoted to sexual material harmful to minors to use commercially available verification technology and prevent minors from accessing that material. It also limits collection, use, retention, and disclosure of verification data to what is strictly necessary.

    The KOSA title separately says it should not be construed to require age gating or age verification. But other provisions impose duties when a service “knows or should have known” a user is a child or teen. The Electronic Frontier Foundation argues that this pressure will lead broader services to determine users’ ages, including by asking adults to prove they are adults.

    That is an advocacy interpretation, not a settled outcome. But it identifies the key implementation question: Can a service comply without building a persistent identity or age-classification system for everyone?

    The privacy question is not whether protecting children is worthwhile. It is what infrastructure compliance creates. A system that collects identity documents, biometric estimates, device signals, or persistent age labels can become useful for advertising, account linkage, content control, or government access unless reuse and retention are technically and legally prohibited.

    Any final bill should minimize data, prohibit reuse, protect anonymous and pseudonymous access, avoid biometric estimation where less intrusive methods work, publish error rates, and require independent testing for demographic bias. The strongest design proves only the necessary threshold and then forgets the underlying evidence.

    What to watch in the Senate: whether the final package changes the “knows or should have known” standard, narrows or expands direct age-verification duties, preserves state protections, limits data retention, and creates a realistic enforcement path when an age system is inaccurate or discriminatory.


    Treat messaging-app recovery keys like master passwords

    The FBI warns that Russian intelligence-linked actors are impersonating messaging-app support services and trying to obtain verification codes, account PINs, and backup recovery keys.

    A recovery key can be more damaging than an ordinary password. An attacker who obtains one may be able to download historical private and group messages and later take over an account. The old key can remain useful even after the victim creates a new account with the same phone number.

    No legitimate support agent should ask for a backup key, verification code, or PIN. After suspected exposure, generate a new recovery key from inside the application; changing the account alone may not invalidate the compromised key. Regeneration cannot retrieve a backup already downloaded, but it can block future use of the old credential.

    Civic organizations should write this into incident-response plans. If a member reports a suspicious support message, the response should include regenerating the key, reviewing linked devices and active sessions, preserving the phishing message, warning affected groups through a trusted channel, and assuming that messages already restored by the attacker may have been copied.

    The broader lesson is that encrypted messaging still depends on unencrypted human workflows. Attackers often do not break the cryptography; they persuade a user to hand over the recovery path.


    Axon Watch: better logs, easier recurring searches

    Axon’s June 30 Records and Standards notes describe a report-redaction tool that records who made a redaction, when it occurred, and the reason – if the user provides one. They also add reusable saved searches and more precise audit-log timestamps. The rollout began at 11 a.m. Pacific and may continue into the following day; Axon says availability can change.

    These are governance changes, not merely interface changes. A redaction log is stronger when the reason is mandatory and tied to a policy category. If the reason remains optional, an audit may prove that a field was hidden without explaining the legal basis for hiding it.

    Saved searches can improve efficiency, but they can also turn a one-time query into a standing practice. A reusable search may silently encode a broad location, person category, vehicle pattern, or data combination that is run again and again. Agencies should control who may create, share, and execute saved searches, require a purpose and expiration date, and review recurring sensitive queries as surveillance programs rather than personal shortcuts.

    More precise timestamps are useful only if records are retained, protected from alteration, and connected to user identity, case number, query terms, and result handling. Better software fields become safeguards when policy makes them complete and review makes them consequential.


    Safeguards

    Safeguards

    The strongest protections this week control who can take the next, more intrusive step – and make that step provable.

    Put a judge at every material expansion point

    A digital warrant should specify more than the first geographic circle or time window. When a search proceeds in stages, define objective narrowing criteria and require renewed judicial approval before investigators expand the period, follow devices beyond the original location, or reveal identities.

    The order should identify the offense, factual basis, data source, geographic boundary, duration, expected number of affected people, minimization procedure, deletion rule, and the evidence required before moving to the next stage. Investigators should not receive a “roving commission” to decide whose private movements deserve deeper review.

    Apply one constitutional standard to sensitive location data

    Do not let the purchase route determine the privacy rule. Require a warrant or equivalent judicial authorization for sensitive location information obtained from carriers, platforms, advertisers, brokers, or contractors. Record the legal authority, requesting official, case number, purpose, date range, geographic scope, and disposition for every query.

    The rule should cover direct access, subscriptions, trial accounts, demonstrations, enrichment services, federated searches, and records received from another agency. A restriction on compelled disclosure is incomplete if the same movement history can be bought from a commercial intermediary.

    Verify vendor promises with deliverables

    A contract should identify the exact audit reports a vendor must produce, their fields and format, delivery schedule, retention period, public-posting process, and consequences for nonperformance. Encryption terms should state what is encrypted, when, who possesses the keys, and whether the vendor can decrypt or export records.

    A practical contract checklist:

    • Can the agency inspect every local, outside-agency, and vendor action?
    • Must each search include a case number, purpose, and legal authority?
    • Are outside networks and new integrations disabled by default?
    • Must the vendor give notice and resist conflicting legal demands?
    • Does the agency approve pilots, feature activations, and policy-changing updates?
    • Can the agency terminate, obtain deletion certification, and recover fees after a material breach?

    “We own the data” is not enough if the vendor controls administrator access, encryption keys, integrations, or the audit evidence needed to prove compliance.

    Make facial recognition reproducible

    Preserve the original image, all preprocessing, vendor and version, database searched, settings, complete candidate results, analyst decisions, later witness procedures, and corroborating evidence. Disclose the system’s use even when prosecutors call it only a lead.

    Do not treat a candidate list as an identification. Require trained human review, independent corroboration, and a record of why other candidates were rejected. Later witnesses should not be shown a single algorithm-selected person in a way that converts a tentative lead into an apparently independent identification.

    Map every route into and out of the system

    A sharing diagram should identify local users, outside agencies, vendor administrators, subcontractors, federated networks, application-programming interfaces, exports, backups, and legal-process pathways. For each route, specify who can authorize access, what purpose is allowed, what data leave the system, how long the connection lasts, and what evidence the action creates.

    Review the diagram whenever a contract is renewed, a pilot begins, an integration is enabled, or a software update changes search or sharing. Woodburn’s experience shows that an agency can misunderstand its own exposure when the vendor’s network architecture changes the practical meaning of “sharing.”

    Make audit evidence usable, not ceremonial

    A useful audit record needs the user and agency, date and time, case number, stated purpose, legal authority, search terms, datasets queried, result count, exports, sharing, and final disposition. It should also record denied attempts, administrator changes, vendor access, retention overrides, and creation or reuse of saved searches.

    Assign someone independent of day-to-day users to review the logs on a fixed schedule. Publish aggregate reports quickly, investigate anomalies, document corrective action, and preserve detailed records long enough for litigation, public-records review, and contract enforcement. A log no one reads is storage, not oversight.

    Build age assurance to forget, not remember

    Reveal no more than the minimum fact necessary – such as whether an age threshold is met – and do not create a reusable identity record. Prohibit secondary use, advertising, cross-service tracking, indefinite retention, and conversion of an age check into a biometric profile. Require appropriate legal process before government access.

    Legislation should require public documentation of the method, error rates, demographic testing, retention schedule, appeal process, and all downstream recipients. A child-protection system should not quietly become identity infrastructure for every adult who uses the service.

    Treat recovery keys as offline secrets

    Store backup recovery keys separately from the device and account they protect. Never send them through chat, email, forms, or a support conversation. Regenerate the key immediately after suspected exposure and review linked devices and active sessions.

    Organizations should designate a trusted channel for security alerts and rehearse what happens after compromise. Preserve the fraudulent message, warn affected groups, rotate related credentials, and assume that any backup already downloaded may be outside your control.

    Govern recurring searches as policy, not convenience

    Saved searches, alerts, watchlists, and automated recurring queries can become standing surveillance programs. Require a documented purpose, owner, approval period, review date, access list, and deletion rule. Audit not only who ran a search but also who created the template and how often it was reused.

    A recurring query should expire unless someone affirmatively renews it. Material changes to search terms, geography, datasets, or sharing should trigger a new review. The easier software makes repetition, the more important it becomes to distinguish a lawful one-time inquiry from ongoing monitoring.

    Plan for failure before deployment

    Every sensitive system should have an incident plan that covers unauthorized access, inaccurate matches, vendor nonperformance, exposed credentials, unlawful outside queries, and policy-changing software updates. Name the decision-maker, evidence-preservation steps, notification duties, suspension authority, correction process, and conditions for terminating the system.

    Failure planning changes incentives before anything goes wrong. Vendors know which records they must preserve and what breach consequences apply; staff know when to stop using a tool; affected people have a correction path; and elected officials receive facts rather than reassurances.

    Bottom line

    The strongest safeguards this week all control the next step. A judge must control when a location search widens. A contract must control whether a vendor delivers an audit. Discovery must reveal when an algorithm shaped an investigation. An age check must not become a lasting identity system. And a recovery key must remain outside the reach of anyone pretending to offer support.

    The common test is operational: Who can take the next step? What evidence must they provide? What does the system prevent? What does it log? Who can inspect the record, correct an error, or impose a consequence?

    A safeguard is not what a policy promises. It is what the system prevents, records, reveals, and allows someone to challenge.

  • Signals & Safeguards Issue 15: Repurposed Databases, Data Brokers, and the Search Layer

    Signals & Safeguards

    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

    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

    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.

  • Signals & Safeguards — Issue 13

    Signals & Safeguards

    Issue 13 • Wednesday, June 10, 2026

    A concise weekly scan of surveillance, privacy, cybersecurity, and the safeguards public officials should keep in view.

    At a glance

    – Section 702 is nearing another deadline, but the fight is really about searches, warrants, and control of a powerful intelligence database.

    – The Supreme Court’s FCC decision over telecom location-data fines is a reminder that metadata is sensitive data.

    – Breach victims are often notified late, after exposed data may already be circulating.

    – Facial recognition is moving toward ordinary consumer devices, from doorbells to smart glasses.

    – Age gates, Axon updates, AI-tool compromises, campus cameras, and ad-tech data all ask who can turn sensitive data into a searchable system.


    Section 702 is now a warrant fight and a governance fight

    Section 702 of the Foreign Intelligence Surveillance Act is aimed at foreign intelligence targets outside the United States. But Americans’ communications can be swept in when they communicate with those targets, and federal agencies can later search that data without a warrant.

    That is why civil-liberties groups have focused on the search stage, not only the collection stage. The Brennan Center explains the warrant fight around U.S.-person queries; the ACLU is urging Congress to require stronger protections; and Cato warns that AI could raise the stakes by helping generate or launder investigative predicates.

    As of June 9, 2026, Reuters reports that Section 702 is set to expire June 12, after multiple short-term extensions and continuing disagreement over privacy protections. The plain-English issue is simple: a foreign-intelligence database becomes more powerful later if searches are too easy, too broad, or too weakly reviewed.

    Why this matters in Bend: Federal surveillance law shapes the privacy environment local governments operate in. If broad collection, weak search limits, and after-the-fact oversight become normal federally, local officials should be careful not to import the same logic into city technology, public-safety tools, vendor contracts, or data-sharing agreements.


    Metadata is sensitive data

    The Supreme Court’s decision siding with the FCC in the wireless-carrier fine dispute is a useful reminder that location data is not harmless just because it is metadata. Reuters reports that the case involved FCC fines connected to carriers’ sharing of customer location data, including fines of $57 million for AT&T and nearly $47 million for Verizon, with additional fines for T-Mobile and Sprint.

    Location metadata can reveal where people live, work, worship, seek care, gather, travel, and protest. The same principle applies beyond telecoms: license-plate scans, ad-tech location trails, smart-device records, voter files, school logs, and vendor-access records can all become sensitive when tied to real people.

    “Metadata absolutely tells you everything about somebody’s life. If you have enough metadata, you don’t really need content.”

    — Stewart Baker, former NSA General Counsel

    Why this matters for Oregonians: Oregon privacy policy should treat metadata as sensitive data, especially when public agencies, vendors, telecoms, or data brokers can connect it to names, addresses, devices, vehicles, or places.


    Breach victims are often the last to know

    A breach is not the only harm. Delayed notice can become a second harm. Troy Hunt’s “1000 data breaches later” essay argues that disclosure lag has grown worse even as breach databases, credential stuffing, identity fraud, and public leak sites have made exposed data more immediately useful to attackers.

    The people whose data was exposed may be the last ones to know, even when the data is already searchable, traded, or used in phishing. The safeguard lesson is direct: people cannot protect themselves from exposed data they are not told about.

    Why this matters for Oregonians: A delayed breach notice can leave residents exposed while stolen data is already circulating. Public agencies and vendors should disclose what happened, what data was affected, when they knew, and what people can actually do next.


    Meta smart glasses and Ring show facial recognition moving into ordinary devices

    Facial recognition is no longer only a government-system issue. WIRED reported that Meta removed face-recognition components from its Meta AI smart-glasses companion app after WIRED found unreleased face-recognition code. WIRED reported that the system was not publicly activated. The warning is that consumer wearables are moving toward biometric capability before clear public rules are ready.

    Reuters separately reports that Amazon’s Ring has been sued in a proposed class action alleging that its “Familiar Faces” feature unlawfully collected and stored face images without consent. That claim is an allegation in a lawsuit, not a court finding. Taken together, smart glasses and doorbells show how biometric infrastructure can enter everyday life through private devices as well as public contracts.

    Why this matters in Bend: Surveillance can enter a community through private devices as well as public contracts. Doorbells, smart glasses, storefront cameras, and platform features can create biometric data trails even when City Council never votes on a camera system.


    Warning Signals

    Warning Signals

    These items point toward where surveillance systems, identity infrastructure, public-safety platforms, and data governance may be heading next.

    Age gates are becoming identity gates

    Child safety is a legitimate policy goal. But the design of age-verification systems matters. EFF warns that age gates are spreading globally and can pressure people to prove age or identity before accessing ordinary online services. The risk is not only inconvenience. Broad age verification can normalize government-ID checks, biometric scans, wallet credentials, operating-system-level age signals, or private verification vendors as the price of ordinary internet access.

    Why this matters for Oregonians: Oregon can pursue child-safety goals without turning ordinary internet access into an identity-check system. Future proposals should minimize data collection, avoid government-ID retention, protect lawful anonymous speech, limit vendor reuse, and require independent audits.


    Axon Watch: public-safety platforms keep expanding

    Axon should not be understood only as body cameras, Tasers, or ALPR. Its May 2026 release notes and June Records and Standards release notes show continuing software and records-system updates. Echodyne also announced a public-safety radar partnership with Axon on May 27, saying the partnership supports safer and more scalable drone operations across law enforcement, homeland security, and Drone as First Responder programs.

    A feature appearing in release notes or a vendor ecosystem does not mean it has been deployed locally. But it does show the direction of the platform public agencies may be buying into.

    Why this matters in Bend: Bend and Deschutes County are already making decisions inside the Axon ecosystem. Officials should distinguish between the tools being purchased today and the platform capabilities that may become available later through updates, integrations, AI features, drones, radar, records systems, or real-time operations.


    AI developer tools are becoming supply-chain targets

    TechCrunch reports that Microsoft shut down dozens of GitHub-hosted open-source projects after hackers apparently injected password-stealing malware into tools used with AI development apps, including Claude Code, Gemini CLI, and VS Code. AI development tools can have access to local files, credentials, API keys, source code, and developer workflows. A trusted tool can become a high-leverage attack path if it is compromised.


    Campus safety systems are becoming campus surveillance systems

    CBS8 reports that more than 1,300 AI-enabled cameras have been installed across San Diego State University. Times of San Diego, republishing Daily Aztec reporting, says cameras are placed in hallways, entryways, common areas, and dorm buildings. Public institutions may deploy AI-enabled surveillance under a safety rationale before students, staff, or the public fully understand scope, capabilities, retention rules, access permissions, or oversight.

    Why this matters for Oregonians: Public schools, colleges, and universities should not treat AI-enabled camera systems as ordinary safety equipment. Officials should disclose capabilities, camera-location policies, retention rules, access permissions, vendor access, audit logs, and whether footage can be searched or shared outside the institution.


    Sanctuary policy only works if data channels cannot route around it

    Immigration enforcement does not depend only on government-owned databases. WIRED reported earlier this year that ICE issued a request for information about commercial “Big Data and Ad Tech” products that could support investigations, including tools that may involve location data from advertising technology. A formal state or local policy can be weakened if enforcement agencies route around it through commercial data, shared databases, vendors, ALPR networks, or ad-tech data.

    Why this matters for Oregonians: Oregon’s sanctuary protections are only as strong as the database permissions, vendor contracts, and commercial-data channels behind them. If enforcement can route around state limits through ad-tech data, ALPR systems, shared databases, or brokers, policy protection may fail at the technical layer.


    Public memory is becoming harder to preserve

    Techdirt, citing Nieman Lab, reports that more than 340 local news sites are now limiting the Internet Archive’s ability to preserve their stories. Publisher concerns about AI scraping are real, but the public-interest cost is also real: local accountability depends on records people can find, compare, cite, and revisit after a contract, policy, meeting, or public-safety decision fades from the front page.

    For surveillance oversight, archiving is not nostalgia. It is evidence. If local reporting, meeting records, procurement pages, and public explanations disappear or become hard to retrieve, residents and officials lose the timeline needed to evaluate promises, changes, renewals, and vendor claims.


    Data-center opposition is becoming a surveillance issue

    Communities may oppose AI data centers for ordinary civic reasons: electricity, water, land use, rates, noise, transparency, and local control. The warning signal is what happens when lawful opposition is pulled into threat-intelligence, extremism, or security-monitoring frames without clear boundaries.

    Public agencies should distinguish credible threats from lawful civic participation. Protest, petitions, testimony, public-records requests, and neighborhood organizing should not become surveillance triggers merely because the underlying project is politically or economically important.


    Direction of travel

    This week’s Signals point toward one pattern: identity, access, and memory are becoming control layers. Age checks, Axon platform features, AI development tools, campus cameras, ad-tech data, smart glasses, doorbells, telecom location records, and local archives all shape who can be identified, searched, remembered, or forgotten.


    Safeguards

    Safeguards

    A safeguards page works best when it is practical: less data, cleaner boundaries, stronger access controls, and fewer shortcuts.

    Require breach notice people can act on

    Breach notice should not be vague, delayed, or written mainly to reduce institutional embarrassment. People need facts they can use: when the organization first learned of the incident; what categories of data were affected; whether data was accessed, copied, sold, posted, or merely exposed; what systems were involved; what users should do next; what the organization has already done; whether law enforcement or regulators were notified; and where the public can find updates.

    This applies to public agencies, schools, utilities, healthcare providers, nonprofits, civic groups, and vendors holding resident data.


    Patch what attackers are already exploiting

    CISA’s Known Exploited Vulnerabilities catalog exists because some vulnerabilities are not theoretical. They are already being used. CISA added one known-exploited vulnerability on June 5 and two more on June 8. Public officials should ask vendors and internal IT teams whether any systems touching public records, evidence, payments, schools, utilities, emergency services, or public-facing portals are exposed to KEV-listed vulnerabilities.

    • Are we affected?
    • When was it patched?
    • Were logs reviewed after patching?
    • Were admin accounts created, changed, or accessed?
    • Were customers or partner agencies notified?
    • What systems depend on this vendor or platform?
    • What is the backup plan if access has to be shut down?

    Protect recovery keys, backup codes, and high-risk credentials

    TechCrunch reports that hackers are targeting Signal users’ backups in a phishing campaign. The important point is not that Signal’s encryption was broken. The risk is social engineering: tricking people into surrendering backup or recovery material.

    Recovery keys, backup codes, password-manager secrets, API keys, admin tokens, and emergency access codes should be treated as high-risk secrets. Secure services should not proactively ask users to send them. Good safeguards include phishing-resistant MFA, hardware security keys for high-risk accounts, password managers with strong recovery practices, offline backup codes, and clear rules for how staff verify security requests.


    Treat school platforms as civic infrastructure

    Federal Student Aid has posted a technology-security alert for an ongoing cybersecurity incident involving Canvas, updated May 29. Reuters and AP reported in May that Instructure reached an agreement with the ShinyHunters hacking group after the Canvas incident. Instructure said affected data included names, email addresses, student ID numbers, and messages, but not passwords, birth dates, government IDs, or financial data.

    Schools should treat learning-management systems as civic infrastructure, not just classroom software. These systems can hold assignments, grades, accommodations, messages, family contacts, student IDs, staff information, and records students need during high-pressure periods.

    Why this matters for Oregonians: Districts, colleges, and universities should require incident timelines, breach-notice rules, access logs, data minimization, vendor limits, phishing-response plans, and continuity plans for assignments and records.


    Public-safety grants need technology and data guardrails

    The Justice Department announced the Model Cities Initiative on June 3, describing it as a whole-of-city approach directing nearly $300 million in federal funding toward selected cities. The safeguard is not to reject every public-safety grant. The safeguard is to read the conditions before a community accepts the money.

    Before accepting funds, officials should disclose required technology tools, data-sharing conditions, federal task-force participation, ALPR, facial-recognition, drone, AI, or real-time operations components, reporting obligations, vendor platform commitments, audit logs, retention rules, and whether data can be searched or shared outside the local agency.

    Why this matters in Bend: Public-safety funding should not quietly commit the community to surveillance tools, federal data-sharing expectations, vendor platforms, or long-term reporting obligations. Conditions should be visible before acceptance, not discovered after systems are already in motion.


    Before AI touches public systems, set the purpose limits

    EFF reports that Dr. Matthew Guariglia testified to a House Homeland Security subcommittee that governments should not adopt powerful AI technologies without strong safeguards to protect constitutional rights. For this safeguards page, the practical rule is simple: do not connect AI to records, cameras, case files, benefits systems, schools, evidence platforms, or enforcement workflows until the purpose, data access, human review, error process, logs, retention, and vendor-use limits are clear.

    “At this level the question is not how do we rein in AI, it’s how do we rein in the agencies that would unleash AI on the American public.”

    — Dr. Matthew Guariglia, Electronic Frontier Foundation


    Governance Safeguards

    Governance Safeguards

    The strongest safeguards are built before sensitive data becomes too useful to give up.

    The question is no longer whether sensitive data exists. It does. The question is whether public institutions can prove who accessed it, why, and under what enforceable limits.

    Treat metadata as sensitive data

    Metadata can describe a life without quoting a message. Location pings, plate scans, search logs, device identifiers, camera detections, call records, badge swipes, student-platform logs, and vendor access records can reveal patterns of movement, association, belief, health, work, school, and protest.

    For Oregon policymakers, the key move is to stop treating metadata as harmless simply because it is not message content. Useful safeguards include purpose limits, shorter retention, access logs, case-number requirements, warrant requirements where appropriate, vendor-use restrictions, and public reporting.

    Require audit logs before launch, renewal, or expansion

    Do not approve surveillance or sensitive-data systems that cannot answer basic questions: who searched; what they searched; why they searched; what they accessed; whether the result was shared; whether the search was tied to a case number, warrant, emergency, or documented purpose; and whether an outside reviewer can verify the answer.

    A system without usable audit logs does not merely have a technical gap. It has an accountability gap.

    Why this matters in Bend: Audit logs are the difference between oversight and reassurance. For ALPR, Axon tools, evidence systems, AI features, drones, records platforms, or vendor dashboards, officials should be able to verify who searched, why they searched, what they accessed, and whether the result was shared.

    Limit vendor, outside-agency, federal, and immigration-enforcement access by default

    Access should be narrow by default and expanded only with clear legal authority, documented purpose, logs, retention limits, and review. That means no outside-agency access unless explicitly approved; no vendor access except for documented support needs; no sales, demo, training, or product-development use without written permission; no immigration-enforcement access unless legally required; no federal or out-of-state access without a clear legal basis and logged review; and no data sharing without purpose fields, retention limits, and periodic public reporting.

    Why this matters for Oregonians: State and local privacy rules can be undermined if outside agencies, federal users, or vendors retain broad access by default. Access limits should be technical, contractual, logged, and enforceable – not merely aspirational.

    Make public reporting routine, not exceptional

    Oversight works better when public reporting is scheduled before controversy begins. Agencies should publish enough information to evaluate sensitive systems without exposing individual residents’ raw data.

    Public reporting should include: system purpose, data collected, vendor, retention period, outside-agency access, vendor access, number of searches, number of hits, false matches or complaints, policy violations, corrective action, and renewal dates.

    That is especially important for systems that can expand through software updates, new integrations, agency-to-agency sharing, or vendor platform changes. A public report should show whether a system is still doing what officials said it would do.

    Use a pre-approval checklist before sensitive systems go live

    Before launch, renewal, expansion, or feature activation, officials should be able to answer: What data is collected? Who can access it? What outside agencies can search it? What can the vendor see? How long is data retained? What requires a warrant, case number, or documented purpose? What audit logs exist? Who reviews the logs? What is reported publicly? What happens if the system is misused?

    Before approval, renewal, or feature activation, the public should be able to see the purpose, the data, the access rules, the logs, the retention period, and the consequences for misuse.

    A simple governance test for sensitive systems

    Bottom line

    The best safeguards this week are upstream safeguards: collect less, connect less, search less, retain less, and log every exception. Whether the system is Section 702, telecom location data, ALPR, Axon software, school platforms, public-safety grants, or AI, the oversight problem is the same once data becomes searchable.

    “Sensitive data should not become useful faster than oversight becomes enforceable.”

    Public trust depends on private protections.

  • What Two Weeks of Advocacy Accomplished — And What Comes Next

    What Two Weeks of Advocacy Accomplished — And What Comes Next. Bend Privacy Alliance, June 2026. Infographic summarizing campaign growth, June 3 Deschutes County BOCC outcome, and June 3 Bend City Council outcome.

    Two weeks ago, the Bend Privacy Alliance didn’t have a Facebook group, a public petition, or a community showing up to two government meetings on the same day. Today we do. Here’s what happened, what it produced, and where we go from here.

    How it started

    In mid-May, Deschutes County quietly scheduled a vote on Contract No. 2026-0327 — a five-year, $2,412,669 agreement with Axon Enterprise for body-worn cameras, Tasers, and fleet cameras for the Deschutes County Sheriff’s Office. The contract included the Axon Fleet 3, a camera with integrated license plate reader capability, along with Auto-Tagging and Auto-Transcribe software licenses. The two-page staff report said nothing about whether the ALPR capability would be activated or what policy would govern it.

    We submitted written comment. The Board deferred the item. A second meeting was scheduled for June 3.

    In the two weeks between those dates, the campaign grew beyond one person with a laptop.

    The numbers

    Combined views across Reddit and jonathanwestmoreland.com reached approximately 100,000 over the two-week period — roughly 70 percent from Reddit, 30 percent from the website. A Facebook group dedicated to the campaign reached 71 members in about a week. Someone independently built a website on the topic, unconnected to this organization — a sign the issue had taken on a life of its own.

    None of those numbers include shares from other groups, organic Facebook reach, or the petition signatures. We can’t fully measure what we started.

    June 3 — the county

    Seven people spoke at the Deschutes County BOCC meeting — four in person, three online. Written comment submitted before the meeting addressed six specific asks grounded in Oregon law and the contract itself:

    • Confirmation of whether ALPR capability would be activated
    • A published SB 1516-compliant ALPR policy before deployment
    • Board-level authorization required for ALPR activation
    • A written SB 1587 attestation from Axon
    • Production of the missing Data Processing Agreement
    • A status report on all seven recommendations from the December 2025 Internal Audit

    Of those six asks, four were addressed. The Board adopted a meaningful condition: the Fleet 3’s integrated ALPR capability may not be activated unless DCSO returns to the Board for a separate authorization vote. That condition did not exist before this campaign raised the issue.

    On SB 1587, Axon’s attorneys stated through DCSO that Axon does not meet Oregon’s definition of "data broker" — meaning the law’s attestation requirement, in their view, does not apply. That is Axon’s legal position, not a judicial or agency determination. It will be revisited.

    The audit status report was not addressed.

    The contract passed unanimously.

    One more detail worth noting: the Data Processing Agreement — the governing document for how Axon handles all footage and metadata under the contract — was not in the Board’s original packet. It was transmitted to BOCC staff at 8:07 AM the morning of the vote and handed to attendees as a printed paper document before the meeting began. The Board voted on a $2.4 million contract without having seen that document during their review period. That procedural gap is now on the record.

    June 3 — the city

    Eight people spoke in person at Bend City Council that evening, with two online. Speakers raised surveillance technology oversight broadly, called for policy before deployment, and named a surveillance ordinance as a goal. The Council committed on the record that any stationary ALPR expansion will come before them for a vote and public comment.

    The petition filed under Bend Code 1.30.005(C) requesting Council review of Police Department Policy 428 — the department’s ALPR policy — was submitted the same day and confirmed received by the City Recorder.

    Policy 428 governs ALPR use by Bend PD, which has deployed the Axon Fleet 3 in more than 70 patrol vehicles since July 2023. The petition asks the Council to review whether the policy meets the requirements of SB 1516, which took effect March 31, 2026.

    What the contract review found

    A full review of the contract packet produced findings the staff report never disclosed.

    The Axon Service Level Agreement gives Axon authority to push firmware updates to all devices — body cameras, fleet cameras, Tasers — without DCSO authorization. The same SLA defines "Axon Cloud Services" to include Fusus, Axon’s real-time crime center platform. The staff report mentioned neither.

    The privacy notice attached to the contract designates Axon as the independent Data Controller — not DCSO — for all operational metadata generated under the contract. Oregon’s own State Chief Information Security Officer confirmed in writing that Axon holds the encryption keys to all data stored on its platform, not the agency. At the meeting, DCSO cited Axon’s SOC 2 Type II certification in response. SOC 2 audits whether a vendor’s controls work as the vendor describes them — it does not require end-to-end encryption and does not address who controls access to data under a federal legal process. The CISO’s finding stands unrebutted.

    Primary source documents from this proceeding — the BOCC meeting packet, the December 2025 Internal Audit, and the Oregon State CISO letter — are in the source library at jonathanwestmoreland.com/source-library-bend-surveillance-oversight.

    What comes next

    The city fight is the longer one. Bend PD’s ALPR system has been operating in more than 70 patrol vehicles for nearly three years. The Council’s commitment to a public vote before any stationary ALPR expansion is an important line. Holding it requires the governance framework to be in place before the next technology decision arrives.

    The next steps are: understanding the full inventory of surveillance technology Bend PD currently operates, completing the surveillance ordinance and procurement framework, and bringing both before the Council.

    That work is underway.

    More to come.

  • Petition for Council Review of Police Department Policy 428 — Bend Code 1.30.005(C)

    Hello Jonathan,

    Confirming receipt of your email, 6/3/2026.

    Ashley Bontje
    CITY RECORDER
    City Manager’s Office

  • Petition for Council Review of Police Department Policy 428 — Bend Code 1.30.005(C)

    To: Bend City Council (councilall@bendoregon.gov)
    Cc: Ashley Bontje, City Recorder (abontje@bendoregon.gov); City Manager’s Office (communications@bendoregon.gov)
    Subject: Petition for Council Review of Police Department Policy 428 — Bend Code 1.30.005(C)


    To the City Council, Ms. Bontje, and the City Manager’s Office,

    Attached is a petition, submitted under Bend Code 1.30.005(C), requesting that the City Council review Bend Police Department Policy 428 (Automated License Plate Readers) at a public meeting with opportunity for public comment.

    Bend Code 1.30.005(C) provides that “the Council may review any regulation adopted by the City Manager on its own motion, or on petition of any person filed within 30 calendar days of the first public posting of the regulation.” This petition is filed within that window. Under BC 1.05.020, the 30-day period runs through Monday, June 15, 2026, whether Policy 428 was first posted on May 14 or May 15, 2026. The petition explains the basis for those dates.

    Because 1.30.005(C) does not specify a filing location, I am submitting this petition by email to the City Council, the City Recorder, and the City Manager’s Office to ensure proper receipt. A hard copy is also being delivered to City Hall / mailed to the City Recorder. If the City believes this petition should be filed in a different manner or location, I respectfully request written notice so I can promptly correct it within the time allowed.

    I would appreciate written acknowledgment of receipt, including the date of filing.

    Thank you for your consideration.

    Sincerely,
    Jonathan Westmoreland
    Resident, City of Bend, Oregon


    Attachment: Petition for City Council Review of Bend Police Department Policy 428 (BC 1.30.005(C))

  • Signals & Safeguards — Issue 12: ALPR Oversight, Access Pathways, and Practical Privacy Safeguards

    Issue 12 • Wednesday, June 3, 2026

    Signals & Safeguards newsletter masthead

    A concise weekly scan of surveillance, privacy, cybersecurity, and the safeguards public officials should keep in view.

    At a glance

    • ALPR oversight reached Congress, but the first sweeping federal restriction failed in committee.
    • EFF’s new mission-creep examples show why purpose limits need technical enforcement, not just policy language.
    • Vendor platforms are expanding after purchase, making release notes part of the oversight record.
    • New location, platform, and device-signal examples show surveillance moving through access pathways, not just cameras.

    ALPR oversight reached Congress, but the first sweeping restriction failed

    Automated license plate readers are no longer only a city-contract or police-policy issue. This month, ALPR oversight reached Congress. WIRED reported that Representatives Scott Perry and Jesús “Chuy” García introduced a bipartisan amendment to a federal highway bill that would have barred recipients of Title 23 federal highway funds from using ALPRs for any purpose other than tolling. ACLU and partner groups urged the Committee to support the amendment; EPIC joined a coalition pressing the same case. Demand Progress later reported that the committee rejected it.

    Why it matters for public officials: Congress did not settle the question. Local and state governments still have to decide what rules apply before ALPR systems are purchased, renewed, expanded, or connected to larger networks.


    Mission creep shows why purpose limits matter

    EFF’s latest ALPR analysis documents the practical reason purpose limits matter: ALPR networks have been used for school residency verification, employment background checks, and noise or loud-music complaints — uses that do not feature in most public debates over whether to deploy plate readers. Once a location database exists, more users and more purposes will try to reach it. If the rules are vague, a system’s actual use can drift far beyond the original public explanation.

    Why it matters for public officials: Purpose limits should be written before deployment and enforced technically. A policy that says “serious investigations only” is weak if the software still permits broad searches for administrative, civil, or low-level purposes.


    Bend and Oregon show why policy must match permissions

    Bend and Oregon remain useful case studies, but the lesson is broader than either jurisdiction. Earlier reporting from The Source Weekly found that ICE, CBP, and Homeland Security Investigations queried Bend Police Department Flock Safety data 279 times in the first three weeks after the cameras went live. Separately, OPB reported that a lawsuit alleges Oregon State Police allowed federal immigration authorities to query Oregonians’ data through shared law-enforcement databases for years, despite Oregon’s sanctuary laws. OSP denies wrongdoing. The Oregon Capital Chronicle reported the same allegations.

    Those examples should not be repeated as old news. They should be treated as a practical reminder: a privacy rule only works if the database permissions, access settings, and audit logs match the rule.

    Why it matters for Bend and Deschutes County: Written policy matters, but it is only one layer. Contract terms, vendor settings, sharing permissions, system configuration, audit logs, and public reports all have to point in the same direction.

    “If it is law, it will be found in our books. If it is not to be found there, it is not law.”
    — Lord Camden, Entick v. Carrington (1765)


    Policy 428 appears stronger, but oversight still needs proof

    Bend Police Department’s updated Policy 428 appears to add stronger ALPR safeguards, including shorter retention for non-investigatory plate data, search logging, audit and reporting requirements, prohibited-use language, and vendor-contract requirements. That matters. It is a real improvement over a weaker policy baseline.

    But a policy is not the whole oversight system. The next questions are whether the publicly posted version is final, whether any contract or add-on incorporates the same limits, whether system settings enforce them, and whether audit reports will be usable enough for Council and residents.

    Why it matters for public officials: A policy states the rule. A contract binds the vendor. A system configuration prevents improper access. Audit logs show what happened. Public reports let elected officials verify the result. All five layers matter — and they should align before deployment, not after.

    Shared pattern

    The strongest stories on this page point in the same direction: surveillance power expands through access pathways. A local camera, a vendor database, a federal search request, a shared records system, or a platform setting can each change who can reach sensitive data. Oversight has to follow the path the data actually takes.


    Commercial location data is a national-security problem

    Reuters reported that U.S. military personnel deployed to war zones have reportedly been targeted using commercially available location data, with lawmakers warning such data can reveal troop movements and patterns of life.

    The reminder applies at every level: data collected for advertising can become useful for intelligence, enforcement, stalking, coercion, or political pressure. Public policy should treat commercial location data as sensitive infrastructure, not a marketing issue.


    Online speech, anonymity, and age checks are becoming enforcement surfaces

    Bloomberg Law reported that the Justice Department used grand-jury subpoenas to seek identifying and financial information from Reddit and X in investigations involving anonymous criticism of ICE tactics. The Verge summarized the reporting in similar terms.

    Age verification belongs in the same warning pattern. Child safety online is a legitimate policy goal, but systems that require identity documents, facial scans, third-party verification, or persistent proof of age can reduce the ability to read, speak, browse, or associate online without creating an identity trail. EFF has warned that age-check systems can become privacy infrastructure for everyone, not only children.

    The safe framing is narrow but important: when platform records, financial information, age checks, and identity-verification vendors can all be used to identify anonymous users, data minimization and legal-process rules become free-speech safeguards. Lawmakers should separate child-safety goals from systems that normalize persistent identity checks for ordinary lawful speech.

    “The makers of our Constitution undertook to secure conditions favorable to the pursuit of happiness. They conferred, as against the Government, the right to be let alone.”
    — Justice Louis Brandeis, dissenting in Olmstead v. United States (1928)


    Warning Signals

    These items point toward where surveillance systems, vendor platforms, identity infrastructure, and data governance may be heading next.

    Warning Signals section header

    Axon Watch: release notes are part of the oversight record

    Police-technology platforms do not remain frozen after purchase. Axon RMS June 2026 release notes include Records and Standards updates involving form rollback logging, validation, access-profile configuration, and Axon DataStore notes about physical-table read access for replication accounts.

    That is not a scandal or a breach. It is a governance signal. Product updates can affect records workflows, database replication, audit visibility, search behavior, and who can reach what inside a public-safety records environment.

    Oversight question: Does the agency provide elected officials with a periodic platform change log covering major software releases, enabled features, disabled features, database-access changes, audit-log changes, AI tools, and new integrations?


    LPR systems are moving toward broader signal correlation

    Leonardo’s ELSAG SignalTrace product shows where license-plate-reader ecosystems may be heading. The company describes a system that can collect electronic signals from phones, smartwatches, fitness trackers, RFID tags, Bluetooth, Wi-Fi, and vehicle components, then correlate those patterns with LPR data. Leonardo says the tool does not decrypt device content — but movement patterns can be inferred from the devices people carry, not just the plates on their vehicles.

    Why officials should watch it: A procurement described as “license plate reader” today may sit inside a larger vendor ecosystem tomorrow. Public review should cover roadmaps, integrations, and adjacent capabilities, not only the first device installed.


    Drone-first-responder programs are becoming routine infrastructure

    Drone-first-responder programs continue moving from special-use tools toward routine 911 response. San Francisco Police Department now exceeds 600 drone flights per month, Dallas launched a drone-first-responder program tied to a larger public-safety technology platform, and Coral Springs approved an Axon-linked DFR expansion through an existing agreement. Meanwhile, Ohio is debating warrant and equipment rules.

    Why officials should watch it: Drone programs can normalize faster than governance frameworks. The pilot stage is the best moment to define launch rules, livestream access, retention, evidence use, mutual-aid sharing, audit logs, and public reporting.

    Direction of travel

    This week’s signals point to a broader pattern: public-safety technology is becoming a platform environment. Plate readers can connect to device signals. Evidence systems can connect to records, AI tools, and partner sharing. Commercial location data can become intelligence. Online speech can become legal-process data. Drones can become routine response infrastructure.

    The safeguard question is not only what the tool does on day one. It is what the system can connect to next.

    “As with GPS information, the time-stamped data provides an intimate window into a person’s life, revealing not only his particular movements, but through them his familial, political, professional, religious, and sexual associations.”
    — Chief Justice John Roberts, Carpenter v. United States (2018)


    Safeguards

    Good safeguards usually start with less data and clearer boundaries.

    Safeguards section header

    Define access before deployment, not after the first complaint

    Before any camera, database, drone program, records platform, or evidence system is approved, the governing body should be able to answer in plain language: who can search this data? Can federal agencies reach it directly or indirectly? Can outside agencies search it? Can the vendor see, export, or reuse it? Can partner agencies receive alerts or shared results? If those questions do not have documented answers, the policy is not finished.

    Troy, New York’s model — written limits on immigration and First Amendment searches, nationwide-lookup restrictions, and mandatory audits before cameras stayed live — offers a useful template.


    Make the contract match the policy — and the software match the contract

    A policy manual is not a safeguard if the vendor platform ignores it. Purpose limits should appear in account permissions, sharing settings, role-based access controls, retention configurations, vendor support restrictions, and integration rules. The practical test is simple: if the policy prohibits a use, can the system still do it with two clicks? If yes, the policy needs technical enforcement.

    Axon RMS June 2026 release notes discussing physical-table read access for replication accounts are a reminder that routine product updates can change what a vendor can reach inside a records system — which is why contract language on data access should be reviewed at renewal, not just at procurement.


    Require audit logs that elected officials can actually read

    Audit logs should not be symbolic. Useful logs capture who searched, what agency they represented, what documented purpose they gave, whether a case number or legal process existed, what result was returned, and whether the data was exported or shared. Public audit reporting should protect sensitive investigative details, but it should still give elected officials and residents enough information to evaluate whether the system is being used as promised.


    Keep identity and movement data from becoming permanent trails

    Age-verification systems, account-linking tools, location analytics, ALPR networks, and device-signal systems should minimize data by design. A system built to answer a narrow question — such as whether a user meets an age threshold or whether a vehicle is connected to a specific investigation — should not create a permanent identity or movement trail. Good safeguards include short retention, no secondary use, no vendor reuse for advertising or product development, no unnecessary biometric or government-ID retention, and independent security review.


    Before approval, renewal, or expansion, ask:

    • What data is collected, and what data is deliberately not collected?
    • How long is it retained, and who can search it?
    • Can outside agencies, federal agencies, or immigration-enforcement agencies access it directly or indirectly?
    • What can the vendor see, change, export, or use for support, training, demos, or product development?
    • Are searches logged with user, agency, purpose, case number, result, and sharing activity?
    • Are audit results published in a usable public format?
    • Do the policy, contract, and system configuration require the same safeguards?
    • Who approves new integrations, AI features, sharing settings, or platform expansions?
    • What happens if the vendor changes the product after approval?

    Bottom line: The best safeguards this week are disciplined ones: define access before deployment, make the contract match the policy, make the software enforce the contract, log every search, publish usable audit results, and collect less data than the technology makes possible. Surveillance oversight works best when restraint is built into the system before the data becomes too useful to give up.

    “What a person knowingly exposes to the public, even in his own home or office, is not a subject of Fourth Amendment protection. But what he seeks to preserve as private, even in an area accessible to the public, may be constitutionally protected.”
    — Justice Potter Stewart, Katz v. United States (1967)


    Signals and Safeguards footer

  • Written Comment: Contract No. 2026-0327 — Axon Body-Worn Cameras, Fleet Cameras, and Tasers (BOCC, June 3, 2026)

    <!DOCTYPE html>





    Written Comment — Contract No. 2026-0327 — Bend Privacy Alliance


    To: Deschutes County Board of Commissioners
    Re: Contract No. 2026-0327 — Axon Body-Worn Cameras, Fleet Cameras, and Tasers
    Date: June 3, 2026
    From: Jonathan Westmoreland, Bend Privacy Alliance

    Commissioners Chang, DeBone, and Adair:

    I write in support of accountability tools for the Deschutes County Sheriff’s Office. Body-worn cameras, governed properly, serve the public interest. This Board knows that. What I am writing about today is what governing them properly actually requires — and what this two-page staff report does not address.

    The Legal Framework Has Changed Since This Item Was First Scheduled

    When the BOCC deferred Contract No. 2026-0327 on May 27, I submitted written comment identifying the absence of an ALPR policy as a threshold concern. In the two weeks since that deferral, nothing has changed on DCSO’s end. The agency’s published policy manual — available at sheriff.deschutes.org/about/administration/policies — has not been updated since September 23, 2025. It contains no ALPR-specific policy today.

    In that same two-week window, two Oregon statutes have come into force that bear directly on this contract.

    SB 1516 (Effective March 31, 2026) — ALPR Framework

    Oregon’s ALPR law is not aspirational guidance. It is mandatory statutory law.

    Oregon SB 1516 — Section 7

    Before deploying or using an automated license plate recognition system or captured license plate data, a law enforcement agency shall establish and publish policies and procedures governing that use — including authorized uses, data retention, access controls, audit requirements, and data sharing limitations consistent with the Act.

    SB 1516 further provides that after March 31, 2026, a law enforcement agency may not enter into a new contract with an ALPR vendor unless the agency and the contract comply with the Act.

    The fleet camera in this contract is the Axon Fleet 3. The contract also includes purchased licenses for Axon Auto-Transcribe (unlimited service, 105 units) and Axon Evidence Auto-Tagging (105 units) — software services that provide AI-powered analytics on footage, including vehicle and license plate recognition functions. These are active purchased line items, not future options. The staff report does not address whether these features will be activated or restricted, and no governing policy exists.

    Compounding this: the Service Level Agreement attached to this contract provides that firmware updates to Axon devices “are pushed from Axon Cloud Services” and “customer interaction is not required.” Axon can activate or modify device capabilities — including Auto-Tagging and Auto-Transcribe — through a firmware push at any time after contract execution, without a separate authorization from DCSO or this Board. No policy governing that capability exists today.

    SB 1587 (Effective June 5, 2026 — Today) — Data Broker Prohibition

    Oregon SB 1587, Chapter 96, prohibits public bodies from disclosing personally identifiable information to a data broker unless the data broker provides a written attestation that the information will not be sold or transferred to any entity to enforce federal immigration law. This law took effect today — the same day this contract is scheduled for a vote.

    I have reviewed the complete contract, including the Axon Cloud Services Privacy Notice attached as an exhibit. No SB 1587 attestation exists anywhere in this document. The privacy notice authorizes Axon to share data with “subsidiaries, legal entities, third party service providers and other partners” for product development, analytics, and security purposes, with no restriction on federal law enforcement access beyond what applicable law requires. The County should require a written SB 1587-compliant attestation from Axon — binding on Axon and its sub-processors — as a condition of contract execution.

    Vendor-Held Encryption — A Data Sovereignty Condition the Board Should Accept on the Record

    In a February 14, 2026 letter to Senator Prozanski and the Senate Committee on Judiciary, Oregon State Chief Information Security Officer Ben Gherezgiher confirmed that while Axon’s platform is built on FedRAMP-authorized Microsoft Azure Government Cloud and meets CJIS security requirements, Axon does not employ end-to-end encryption architecture. As a SaaS provider, Axon maintains encryption keys on behalf of its law enforcement subscribers — meaning DCSO would not retain encryption keys to its own data.

    The contract confirms this in structural terms. The Axon Cloud Services Privacy Notice attached to this contract designates Axon as the Data Controller — not DCSO — for all Non-Content Data generated under the contract. This includes device logs, usage patterns, system configurations, service interaction data, and application logs. For this entire category of data, Axon independently determines the purposes and means of processing. DCSO cannot direct how Axon uses it, restrict its disclosure, or require its deletion. Meeting security standards and controlling your own data are distinct conditions. The Board should acknowledge the latter explicitly and on the record before voting, not by silence.

    Additional Contract Findings the Staff Report Does Not Address
    Finding 1 — The Data Processing Agreement Is Missing

    The Axon Cloud Services Privacy Notice attached to this contract references “the Data Processing Agreement entered into between the parties” as the governing document for Axon’s processing of DCSO footage. That document is referenced twice as controlling. It is not attached to Contract No. 2026-0327. The Board is being asked to approve a $2.4 million contract that incorporates by reference a governing privacy document that is not before them.

    Finding 2 — Axon Can Push Firmware to All Devices Without DCSO Authorization

    The Service Level Agreement provides that firmware updates to Axon devices “are pushed from Axon Cloud Services” and “customer interaction is not required.” The SLA also requires that if remote access to DCSO’s environment is restricted, “Axon mandates the setup of a jump server or any other access solution” permitting Axon remote tools to access DCSO’s servers. Axon has contractual authority to push software changes to body cameras, fleet cameras, and Tasers, and to access DCSO’s network infrastructure, without a separate Board authorization.

    Finding 3 — Fusus Is an Active Service Under This Contract

    The SLA’s definition of “Axon Cloud Services” explicitly includes “FUSUS services.” Fusus is Axon’s real-time crime center platform — it aggregates surveillance feeds from cameras, sensors, and third-party data sources into a unified dashboard. The privacy notice confirms Fusus collects motion, event, temperature, and ambient light data from device environments, as well as traffic data, location data, and logs from platform users. The staff report makes no mention of Fusus. The Board should understand what it is authorizing.

    What the County’s Own Internal Auditor Found — And What DCSO Refused

    The December 2025 audit of DCSO’s existing body-worn camera program (Audit Report A0134, published December 1, 2025) is directly relevant to this vote. The Board is being asked to nearly triple the scope and cost of a program the auditor could not fully evaluate — because DCSO refused to provide access to footage.

    Scope Impairment — Audit Report A0134

    The auditor’s primary objective was to verify that deputies were recording interactions as required by policy. DCSO denied access, citing County Legal advice that internal audit review does not constitute a “legitimate law enforcement purpose” under ORS 133.741. No supporting documentation — no memo, no case citations — was provided. The County Internal Auditor could draw no conclusion about whether DCSO deputies are actually recording interactions as required. That gap is unresolved today.

    The staff report characterizes the audit as having “identified operational, regulatory, and policy improvements which cannot be met by the current vendor” — framing it as a procurement justification. That characterization omits the scope impairment, the refused footage access, and management’s formal written disagreement with the recommendation to publish program statistics publicly. The Board deserves the full picture.

    Beyond the scope impairment, the audit identified four substantive findings:

    Quarterly reports not published, preserved, or evaluative (Recommendations 1–3). Reports are issued internally but are not public, not preserved as evidence, and not designed to evaluate program effectiveness. Sheriff Rupert’s management response formally disagrees with the recommendation to publish these reports — the only outright disagreement in the entire management response. That is a stated policy position against public transparency, in writing, six months before this Board votes to expand the program significantly.

    Supervisor review not occurring consistently (Recommendation 4). In the July–September 2025 period, 42 percent of deputies had fewer than the two supervisor reviews per quarter required by policy added in March 2025.

    Information security controls fell short of CJIS standards (Recommendations 6–7). Password requirements, session lockouts, account setup, temporary access, and inventory controls all fell short. No policies and procedures manual exists for the camera information system. Resolution is targeted for June 30, 2027 — contingent on vendor selection. The vendor being selected is the subject of today’s vote.

    Public records requests resulted in zero releases (Recommendation 5). In the auditor’s sample of ten requests, no footage was released — primarily because redaction costs ranging from $86 to $2,315 per request led requesters to abandon them. The program is functionally opaque to the public.

    This Board is being asked to expand a program whose accountability mechanisms are incomplete, whose security controls are deficient by the auditor’s own findings, and whose management has formally declined to publish program statistics publicly. The audit’s unresolved recommendations are not a reason to reject this contract — but they are a reason to condition it.

    My Asks
    1. 1
      Require on-the-record confirmation, before voting, of whether the Auto-Tagging and Auto-Transcribe licenses included in this contract encompass license plate recognition or vehicle analytics functions, and whether DCSO intends to activate those capabilities.
    2. 2
      Condition any activation of fleet camera ALPR or vehicle analytics capability on the prior adoption of a written, published, SB 1516-compliant ALPR policy. This is not a discretionary request — it is what Oregon law requires.
    3. 3
      Treat ALPR activation as a Board-level policy decision requiring separate authorization, public notice, and a policy in place before deployment — not an administrative implementation decision. Note that Axon’s SLA permits firmware-based feature activation without customer authorization; the Board should close that gap contractually.
    4. 4
      Require Axon to provide a written attestation compliant with Oregon SB 1587 (Chapter 96, 2026) before contract execution, confirming that personally identifiable information stored on the platform — including through Axon’s sub-processors — will not be transferred to any entity for federal immigration enforcement purposes.
    5. 5
      Require the missing Data Processing Agreement to be provided, reviewed by County Legal Counsel, and made available to the Board before the contract is executed. The contract references this document twice as governing DCSO’s footage — it is not attached to the packet before you today.
    6. 6
      Direct staff to provide the Board with a written status report on all seven recommendations from Audit Report A0134 — specifically which are implemented, which are in progress, and which have been declined — before the expanded contract goes live.

    The community showing up today is asking this Board to govern this technology — not just purchase it. These asks are grounded in Oregon law, the contract itself, and the County’s own audit record.

    Respectfully submitted,

    Jonathan Westmoreland
    Bend Privacy Alliance