Jonathan

  • Signals & Safeguards: ALPR Edition

    Signals & Safeguards — ALPR Edition. Bend Privacy Alliance. Privacy, Transparency, Civil Rights.

    Published four days ahead of the National Week of Action Against ALPRs (August 16–22, 2026). Signals & Safeguards now publishes every other week; this special edition is devoted entirely to automated license plate readers.

    In anticipation of the National Week of Action Against ALPRs, running August 16–22, this special edition is devoted entirely to automated license plate readers — the small roadside cameras now creating searchable records of millions of drivers’ movements across the country. It publishes four days before the Week of Action begins. Nothing in this edition describes a vote, removal, or investigation as complete unless it had already happened at the time of writing.

    Scale, for Context

    Flock Safety’s roughly 120,000-camera network — which includes both automated license-plate readers and separate pan-tilt-zoom video cameras — now stands in every state but Alaska, under contract with about 7,000 law enforcement agencies, some 40% of all police departments in the country. The company is now valued at $8.4 billion. — The New York Times; CNN

    This Happened Here

    Bend, Oregon — June 2025–January 2026

    This isn’t a hypothetical for Bend. In June 2025, during the first three weeks of what was supposed to be a year-long Flock Safety pilot, federal immigration officials — ICE, CBP, and Homeland Security Investigations — accessed Bend Police Department’s camera data 279 times. Bend PD had not authorized any of it.

    The cause, according to police officials themselves, was a single setting: a “Lookup” function left in its factory-default “National” position rather than switched to “State” or “Local,” reportedly the result of a supervising captain’s oversight. That one unflipped toggle opened Bend’s camera data to every agency running a National Lookup query anywhere in the country. City Council turned the cameras off at its January 7, 2026 business meeting. — The Source Weekly

    The lesson generalizes directly: a policy on paper — “we don’t share with immigration enforcement” — is not the same thing as a technical setting that actually enforces it. Bend’s own experience is the clearest local proof of that gap.

    1.4 million

    Queries of Oregonians’ driver and criminal records by federal immigration authorities, alleged in a May 2026 lawsuit against Oregon State Police — including 176,576 by ICE alone and 21,363 by Homeland Security Investigations, with Customs and Border Protection and the remainder of DHS accounting for the bulk of the total.

    The lawsuit, filed May 5 by the Rural Organizing Project, alleges Oregon State Police has for years allowed federal immigration authorities to query Oregonians’ data through its Law Enforcement Data System — an average of roughly 3,835 queries a day. The complaint says OSP has held these data-sharing agreements since 2007, and that a February request from Rural Organizing Project to terminate them was declined. OSP has denied wrongdoing; a spokesperson told OPB the agency “is committed to following Oregon Sanctuary Laws and has not taken any actions that would violate those laws.” — The Source Weekly; OPB; AOL

    Section One

    How Far the Network Could Grow

    The debate over ALPRs has mostly been about fixed cameras — mounted on poles, at intersections, on toll gantries. A document obtained by 404 Media shows Flock pitched something considerably larger: a plan to partner with dashcam maker Nexar and turn roughly 350,000 rideshare and delivery drivers’ dashcams into a mobile, privately operated plate-collection network. The presentation was prepared for Georgia’s Office of the Attorney General in August 2025. Flock told 404 Media the Nexar partnership was never executed. — 404 Media

    But the presentation still documents the scale of the mobile collection network the company had pitched — and reframes the question this special edition keeps returning to: not just how many fixed cameras exist, but how much of the country’s movement a company like Flock is willing to propose capturing next.

    Section Two

    Same Capability, Different Vendor Name

    Several jurisdictions responding to Flock controversy have not stopped using ALPR technology — they’ve switched vendors. 404 Media reports that cities dropping Flock are, in some cases, immediately replacing it with Axon license plate readers, which can use existing streetlight infrastructure and blend into surroundings. — 404 Media

    Stanford ended its Flock contract and moved to Genetec, with university-controlled data storage and a stated 30-day retention policy. — Stanford News; KQED

    Douglas County, Colorado is replacing 50 Flock cameras with a nearly $23 million, 10-year Axon contract that adds 50 more cameras. Flock’s CEO publicly disputes the sheriff’s characterization of data ownership. — Axios Denver

    Pleasanton, California shows what can go wrong even when a jurisdiction intends to leave a vendor: a city memo says three Motorola/Vigilant cameras kept collecting data until July 8, 2026, months after the city believed it had terminated the contract in October 2025. The legacy system reportedly wasn’t configured to log outside-agency searches, so the city couldn’t determine whether a federal agency had queried the data without authorization. — City of Pleasanton memo

    Changing brands is not the same as changing practice. A genuine safeguard has to follow the capability — retention limits, audit logging, access verification — not the logo on the camera housing.

    Section Three

    What Departments Don’t Want Said Out Loud

    404 Media obtained a Wapello County, Iowa “standard operating procedures” document, dated November 2025, that instructs deputies: “DO NOT MENTION ALPR USAGE TO THE OCCUPANTS OF THE VEHICLE” and “DO NOT MENTION ALPR USAGE IN YOUR REPORT OR COMPLAINT UNLESS ABSOLUTELY NECESSARY.” Where a report must explain how a vehicle was located, the policy recommends language such as “using county resources.” The document does carve out one exception — it instructs deputies to tell the truth if directly asked by someone like an attorney. Sheriff Don Phillips defended the policy, saying deputies independently confirm any plate, warrant, or stolen-vehicle report before acting, and that disclosing the camera system would reveal investigative methods to people trying to evade it. The county has four Flock cameras under a contract signed in late 2024. — 404 Media

    This is a policy about concealment, not a single officer’s judgment call, and it raises real questions about parallel construction, discovery obligations, and what the public is entitled to know about how a stop began. A related 404 Media story describes an incident in which a driver’s Flock-tracked interstate travel — including a trip to a state where marijuana is legal — reportedly became part of the stated justification for a stop and search. — 404 Media

    Charlotte-Mecklenburg police released a previously undisclosed data-sharing agreement with Flock only after journalist pressure and after Officer Seth Elliott, 25, was arrested and charged with illegally accessing a government computer. Court records allege a friend facing drug charges in Watauga County asked Elliott to run a plate; Elliott is accused of using Flock and the state’s CJLEADS database to identify it as belonging to an undercover officer, then passing that identity back to the drug suspect — an allegation, not an adjudicated fact. CMPD owns no Flock cameras itself but had access through its MOU with a broader regional network. — WCNC; WBTV

    Section Four

    When Access Becomes a Tool for Personal Use

    A Washington Post national investigation gives structural shape to what might otherwise look like scattered local incidents: officers with broad camera-network access allegedly using it to track people in their personal lives, including former partners. Its value is explaining the mechanism — authorized access can be repurposed with very little friction — not adding another isolated case to a list.

    That mechanism shows up repeatedly at the local level:

    • DeKalb County, Georgia — eight metro Atlanta police officers reportedly suspended for policy violations involving Flock cameras used for personal reasons. — WSB-TV
    • Savannah, Georgia — six police employees under investigation after an internal audit flagged potential misuse. Savannah had previously appeared in Flock’s own promotional material, one of four departments WIRED found facing misuse allegations after being featured that way. — WJCL; WIRED
    • Baytown, Texas — an officer resigned while internal-affairs and criminal investigations remained open; the resignation does not end the investigation. — ABC13

    The New York Times’ national reporting adds two more data points: a Texas officer used Flock’s cameras to track a woman across state lines who was suspected of self-administering an abortion, and the paper describes officers around the country abusing camera access to track romantic partners — with some cases resulting in discipline or termination. Separately, Los Angeles and Dayton, Ohio both suspended their Flock contracts specifically to keep immigration authorities from accessing camera data; Dayton reportedly resorted to physically covering its cameras with trash bags in the interim. — The New York Times

    This is not an exhaustive incident list. The pattern is the point: a system built for one stated purpose creates access that is very easy to use for another.

    Section Five

    Does It Actually Work?

    Effectiveness evidence is mixed, deployment-specific, and should not be flattened into a single number.

    The Atlanta Community Press Collective compared FBI clearance-rate data against an eightfold increase in Atlanta’s integrated camera network — more than 28,000 cameras combining Flock, Ring, and other systems — and found major-crime clearance rates largely unchanged. A peer-reviewed evaluation of a major ALPR expansion in Atlantic City found no overall reduction in violent crime, though the authors did find associations with reduced shootings, motor-vehicle theft, and property crime; shooting clearance rates did not significantly improve in their data (one coauthor was an Atlantic City police captain). — Shjarback & Sarkos, Justice Evaluation Journal

    Accuracy is a separate question from effectiveness. Business Insider’s review of Roseville, California records found Flock incorrectly read license plates in 71% of 1,427 stolen-vehicle and felony alerts sent to police during 2023–2024 — repeated character errors, blurry images, missed vehicles. Flock attributed part of the performance to atypical camera placement and older hardware; Roseville disputed the company’s claim that performance had improved. Critically, Roseville says independent human verification caught the bad alerts before they became stops or arrests — a deployment-specific rate, not a universal one.

    A third data point: the New York Times reports that a 2024 study found Flock’s cameras increased case clearance rates by 9%, but 404 Media and others criticized the finding because Flock itself had partnered with the researchers and selected which agencies were included — a conflict-of-interest problem distinct from Atlanta’s and Atlantic City’s more independent numbers above. Boulder, Colorado offers a competing claim: the city says its 31 cameras produced a 34.5% decline in motor vehicle theft. — The New York Times

    What a false positive actually costs. Amber Newell was driving on I-94 near Brookfield, Wisconsin — a Milwaukee suburb — on August 6 when a Flock camera flagged her car as connected to a Milwaukee homicide investigation. Brookfield officers surrounded her vehicle with guns drawn; a passenger had to put his hands out the window in view of passing traffic. Milwaukee police later acknowledged the alert should have been cleared from the system days earlier — an employee had simply never removed it. This was not an isolated incident for Newell: she had already been through a nearly identical stop, guns drawn, the previous Monday. Milwaukee police were explicit that this was not a Flock technology failure but a data-entry mistake — worth sitting with, since it means the safeguard that failed was human process, not the camera hardware. Newell says her daughter is now afraid to ride in the car. — Local 12/WITI; FOX6

    Section Six

    Communities That Took Final Action

    These are completed outcomes — votes taken, contracts ended, cameras coming down — not proposals still in progress:

    • Santa Cruz, California — city council voted 6–1 in January 2026 to cancel its Flock contract after sustained resident organizing and reports of out-of-state data access; a Week-of-Action anniversary rally is planned there. — Lookout Santa Cruz
    • Lago Vista, Texas — unanimous council vote to remove Flock cameras. — KVUE
    • Stoughton, Wisconsin — council voted to terminate a two-year, $25,000 Flock agreement just seven months after signing it, paying a reported $12,500 early-termination fee; the resolution requires camera removal and deletion of collected data. Stoughton is reportedly the seventh Dane County entity not to renew a Flock contract. — Channel 3000
    • El Cerrito, California — council voted 3–2 not to renew its Flock contract, after it came to light that federal agencies — including possible ICE access — had queried data from the city’s 40 cameras without police knowledge. Cameras stopped collecting June 6 when the contract expired, with physical removal scheduled through August 18. — NBC Bay Area
    • Chandler, Arizona — the city will end access to and remove 40 fixed cameras after a routine audit found an anomaly officials could not explain. Chandler says no member of the public had their privacy compromised, and the city may later solicit a different vendor. — City of Chandler
    • Narragansett, Rhode Island — town council voted unanimously on August 3 to terminate its Flock contract immediately, becoming the second Rhode Island community to do so within eight days, after South Kingstown’s cancellation on July 27. No replacement vendor had been announced as of publication. A state bill that would have required municipal approval before installation and shortened the state’s default retention period died in the legislature this session. — WPRI; Boston Globe; UpriseRI

    Section Seven

    Communities Still in the Fight

    • Milford, Connecticut — 64 speakers and three hours of public testimony before officials delayed a moratorium vote. — CT Insider
    • Boerne, Texas (near San Antonio) — nearly 900 petition signatures gathered within days; an official who previously supported the cameras is reportedly reconsidering. — MySA
    • Conroe and League City, Texas — Flock camera questions could go before voters in both cities. — Chron
    • Salt Lake City — the council is weighing ordinance proposals covering permitted uses, access tracking, camera placement, and outside data sharing; no vendor named and no policy yet adopted. — Axios Salt Lake City
    • Newtown, Connecticut — council voted unanimous support for drafting a moratorium resolution, referred to an ordinance committee. — News-Times
    • Lake City, Florida — a useful counterpoint: the council voted 2–3 against putting a Flock camera question on the November ballot. Organizing does not guarantee a vote, let alone a win. — News4JAX

    Section Eight

    What Government Oversight Looks Like

    Connecticut’s Governor Ned Lamont has called for a 30-day review by the state’s police training board, statewide guidance, and asked municipalities to pause new ALPR installations while the review proceeds — specifically naming retention, access, sharing, and permissible-use rules as the open policy questions. — Office of Governor Ned Lamont

    West Virginia lawmakers questioned a Flock representative directly and, by the reporting available, remained unconvinced the company’s answers addressed their Fourth Amendment and privacy concerns. — West Virginia Watch

    In Congress, Republican Rep. Keith Self of Texas — a conservative former Army colonel — introduced a bill in July that would require federal law enforcement to get a warrant before accessing or querying state and local ALPR data. The Policing Project at NYU’s law school counts 13 states that now require independent audits of ALPR systems to catch officer misuse; Texas is not one of them. — The New York Times

    Oregon Sidebar

    Oregon is not starting from zero. SB 1516, which took effect March 31, 2026, already sets a 30-day retention limit, restricts use and sharing of ALPR data, and requires public policies, audits, and vendor civil liability. Central Oregon readers should understand these rules already exist here, even as gaps remain — which is exactly why a 2027 legislative concept to strengthen the law is already in progress. The gap between rules on paper and rules in practice is exactly what the Bend and OSP stories in the opening pages illustrate.

    Section Nine

    In the Courts

    • Westchester County, New York — motorists suing over roughly 1.6 billion license plate scans collected on nearly 600 readers, alleging outside data sharing and raising a constitutional challenge. — Associated Press, via LegalNews.com
    • Wichita, Kansas (Grimmett v. City of Wichita) — a state constitutional challenge to a nearly 200-reader network, seeking declaratory relief, an injunction, and deletion of historical records. These are the plaintiff’s allegations and legal theory, not court findings. — Kansas Justice Institute
    • Motorola/Vigilant — a proposed class action alleging improper collection, retention, interstate sharing, security failures, and monetization of plate data. — Legal Newsline
    • New York City — tenants suing to block NYPD access to a housing-authority camera network of nearly 20,000 cameras that reportedly also incorporates license-plate-reader data. — New York Focus
    • Norfolk, Virginia (Schmidt v. City of Norfolk) — a federal judge ruled in January 2026 that Norfolk’s roughly 172–176-camera ALPR program does not currently amount to unconstitutional “dragnet-style” surveillance, but explicitly left the door open: ALPR surveillance “could become too intrusive” at some point, and “at least in Norfolk, Virginia, the answer is: not today.” A court filing in the case found the cameras had logged plaintiff Lee Schmidt’s own vehicle 526 times in about four and a half months. Plaintiffs, represented by the Institute for Justice, plan to appeal. — WHRO; NBC News

    Section Ten

    Beyond Police Departments

    ALPR data does not stay inside one department’s database. The Brennan Center’s catalog of Department of Homeland Security surveillance tools documents more than $2.9 billion obligated since January 2021 across video, biometric, location, and data-purchase systems, and identifies widespread state and local data-sharing arrangements with DHS. In Park City, Utah, the local sheriff confirmed that cameras feeding a shared network have been queried by ICE, which has paid for access, for roughly eight years. — TownLift

    Nashville’s airport shows the same dynamic at a smaller scale: audit logs the Nashville Banner obtained show more than 75,000 searches by Tennessee police departments and sheriff’s offices, plus nearly 2,500 by airport police, this year alone — including at least one search logged as an immigration case. Flock’s standard policy deletes cloud data after 30 days, but airport policy directs staff to move each shift’s data onto internal servers for a minimum of three years.

    Spokane — manual plate collection outside any Flock system. Mother Jones, reporting on public records, found that a Spokane Police Department detective who also serves as a Homeland Security Investigations task-force officer wrote a July 2025 report describing her own and a colleague’s collection of vehicle, license-plate, and social-media information from people near Spokane’s ICE field office — including bystanders not accused of any wrongdoing. Some of that information was uploaded to Evidence.com, a digital evidence platform owned by Axon. This is not a Flock or ALPR story — no automated camera network was involved — but it illustrates that plate-and-movement surveillance happens through channels well outside the ALPR debate.

    On the commercial side, Digital Recognition Network markets more than 500 million plate scans monthly across 300-plus U.S. markets to lenders, insurers, and repossession companies — a private data-broker layer that operates independently of any police department, with hardware that reportedly rides on tow trucks scanning ordinary residential streets. A recent California Court of Appeal ruling in Mata v. Digital Recognition Network favored the company — but on narrow grounds: DRN had actually published the privacy policy state law requires, and the plaintiff couldn’t show a concrete injury beyond the fact of being scanned. A separate case, Bartholomew v. Parking Concepts, cuts the other way: it held that failing to post a required privacy policy is itself actionable harm, with damages starting at $2,500 per violation — now driving a wave of new California class actions. Posting a policy isn’t much of a privacy protection; not posting one now carries real legal exposure. — legal analysis

    Removing a police department’s Flock contract does not touch this commercial layer at all.

    What Action Looks Like

    The Week of Action is decentralized by design — no single event, but community organizing, public records requests, council testimony, and camera mapping happening in parallel across the country.

    The New Yorker followed activists conducting a public “spy hunt” in Atlanta, mapping camera locations with the DeFlock tool. The Muslim Justice League’s Massachusetts coalition work reflects a much broader statewide pattern: at least nine of the roughly 106 Massachusetts communities that had contracted with Flock have recently cut ties, including Cambridge, Framingham, and Salem. Framingham let its contract lapse in June after a 700-person resident campaign; the police chief there confirmed Flock had been used in about 200 cases over four years. — Boston Institute for Nonprofit Journalism; Boston Globe

    The New York Times profile adds a fitting example of individual-level organizing: DeFlock, the crowdsourced camera-mapping app, was created by software engineer Will Freeman after he kept noticing cameras on a cross-country drive. The app has been downloaded more than 350,000 times and has mapped some 125,000 readers nationwide. Freeman, who now lives in Boulder, requested his own camera records from Boulder police, was refused, and filed suit in May arguing the camera network amounts to an unconstitutional “warrantless surveillance dragnet.” — The New York Times

    1. Retention limits — How long is data kept, and is that limit enforced technically — not just on paper?
    2. Outside-search logging — Is every access by another agency logged in a way the public or an auditor can actually review?
    3. Contract closeout verification — When a contract ends, is deactivation confirmed independently, not just assumed? Pleasanton (Section Two) is the cautionary example.

    The ACLU’s national campaign hub and its companion guide on fighting ALPR deployment locally both go further, with model contract language and legislative approaches.


    Join Us: Surveillance in Our Community

    Surveillance in Our Community — A Community Conversation. August 19th, 5:00pm, Central Library, 61956 SE Santorini St, Bend, OR 97702. Join the conversation. Community education event during the ALPR National Week of Action.

    Wednesday, August 19 · 5:00–7:00 PM · Central Library, Bend
    61956 SE Santorini St, Bend, OR 97702

    Bend Privacy Alliance invites Central Oregon readers to join the conversation — what local technology collects, who has access, and why oversight matters. A community education event during the ALPR National Week of Action.

    Event Details & Registration


    Signals & Safeguards is the newsletter of Jonathan Westmoreland, founder of Bend Privacy Alliance · jonathanwestmoreland.com · Published August 12, 2026.
    All underlined source names in this edition are clickable links to the original reporting.

  • Age Assurance Is Becoming Internet Infrastructure

    What a global debate over child safety, privacy, digital identity, standards, and online access reveals about the future of the internet

    Legal and regulatory status checked through July 17, 2026.

    Asking a person’s age sounds like a minor change to a website.

    For most of the open internet’s history, people could read, search, watch, learn, argue, play, and join communities without first proving that they belonged to an approved age category. Age mattered at particular boundaries—buying alcohol, entering a casino, opening certain financial accounts—but it was not a routine prerequisite for participation in digital public life.

    That assumption is changing.

    On July 16, the Software Freedom Law Center, India convened a global panel titled What Age Assurance Means for the Future of Digital Rights, Online Safety, and the Internet at Large. The discussion brought together civil-liberties advocates, child-rights researchers, trust-and-safety specialists, technologists, and organizations from Australia, South Korea, Europe, Africa, India, the United Kingdom, and the United States.[1]

    Moderator Mishi Choudhary began with the tension that shaped the event. Children face real harms online: exploitative contact, harmful recommendation systems, compulsive design, sexualized and violent material, and products that can manipulate a young user’s attention or emotions.

    But once a service must know whether a user is sixteen, seventeen, or eighteen, it must decide how it will know.

    Will the user upload an identity document? Will a company estimate age from a face? Will a platform infer age from years of behavior? Will the phone, operating system, app store, bank, or government supply an age signal?

    A small interface question can become a new relationship among users, platforms, vendors, and the state.

    The question beneath the age gate

    Age assurance is not simply a way to classify children. It can determine whether every user must submit to an identity, biometric, behavioral, financial, or device-based process before accessing lawful information and services.

    The panel did not divide neatly between people who care about children and people who care about privacy. Nearly every participant accepted that harmful online systems require action. The disagreement concerned the intervention.

    Is the state addressing the product features and economic incentives that produce harm—or creating a new identity checkpoint for every user? Can age assurance provide children with safer, developmentally appropriate experiences without blocking lawful access to information and community? Can a proof disclose only an age threshold while resisting tracking, coercion, and expansion into a general digital-identity layer?

    And what happens to people who lack accepted documents, private devices, stable connectivity, or the ability to challenge an automated decision?

    Editorial illustration of a web access gate branching into identity document, face scan, behavioral analysis, device signal, and anonymous credential pathways.
    Editorial illustration of a web access gate branching into identity document, face scan, behavioral analysis, device signal, and anonymous credential pathways.

    Child safety and digital rights are not opposites

    The most useful lesson from the panel was that children’s rights include more than protection from harmful content.

    Children also possess rights to privacy, expression, association, participation, and access to information. Those interests can conflict in a particular case, but they do not disappear because a policy is described as protective.

    Protection can remove support as well as risk

    John Pane of Electronic Frontiers Australia described his country’s under-sixteen social-media regime as a blunt prohibition aimed at the visible part of the problem: children’s access. The deeper causes, in his account, include harmful design, surveillance-based data extraction, and recommendation systems engineered to maximize engagement.

    Australia’s law is no longer hypothetical. Since December 10, 2025, designated platforms have been required to take reasonable steps to prevent Australians under sixteen from creating or keeping accounts.[13] The eSafety Commissioner reported that platforms restricted access to approximately 4.7 million accounts during the first implementation period.[14] Three months later, however, the regulator identified significant compliance concerns involving Facebook, Instagram, Snapchat, TikTok, and YouTube and moved toward possible enforcement.[15]

    The account figure demonstrates large-scale implementation. It does not establish improved wellbeing. Australia has begun a two-year evaluation following more than 4,000 children and families to examine intended and unintended effects.[16]

    The distinction matters because online services can provide LGBTQ+ youth, children in unsafe homes, disabled users, and people in geographically remote communities with information and relationships unavailable nearby. A restriction may remove risk, but it can also remove agency, education, and support. Children may respond through borrowed accounts, circumvention, alternative services, or platforms with weaker protections.

    Adults encounter the gate too

    Paige Collings of the Electronic Frontier Foundation connected age assurance to both privacy and freedom of expression.

    Age restrictions do not operate only on children. Adults must also demonstrate eligibility. For young people, the effects can be particularly serious when lawful information about health, identity, abuse, politics, or community is unavailable offline. Platforms also gain another reason to place difficult or controversial material behind a gate.

    The United Kingdom’s existing Online Safety Act duties already require highly effective age assurance in several circumstances involving pornography and content harmful to children. The government then announced in June 2026 that it intends to prohibit covered social-media services from offering accounts to under-sixteens. Regulations are expected before the end of 2026, with implementation planned for spring 2027; the final service definitions and operational rules were still being developed when this article was written.[17]

    The gate must be implemented somehow. Depending on the method, users may be asked for identity records, financial information, account history, a facial image, or an operating-system signal.

    One of the recurring errors in public debate is to treat the final response—“over eighteen” or “under sixteen”—as though it were the complete data flow.

    Identity requirements can chill ordinary users more than determined wrongdoers

    Professor K.S. Park of Open Net Korea supplied a historical warning.

    South Korea’s Information and Communications Network Act once imposed a general identity-verification requirement on users of covered message boards. The official English legislative record states that the provision applying that requirement to private service providers was removed after the Constitutional Court found it unconstitutional on August 23, 2012; the statutory deletion followed in 2014.[20]

    Park argued that privacy-conscious ordinary users withdrew while people intentionally committing illegal acts found other identifiers or methods. That assessment is his interpretation of the policy’s effects, but the legal history confirms the broader lesson: identity-linked participation can deter lawful speakers without eliminating determined misconduct.

    A person seeking ordinary speech, political participation, or sensitive information may be discouraged by a record connecting identity to activity. A motivated bad actor may treat the checkpoint as another obstacle to evade.

    Digital life is part of children’s real life

    Moritz Katzner of Stop Killing Games and James Baker of Open Rights Group focused on gaming, preservation, learning, and relationships.

    A child interested in a complex game may rely on videos, forums, guides, and interaction with other players. Blocking YouTube, Reddit, or another social platform may not simply remove idle entertainment; it can remove the instructional and community structure surrounding an important hobby.

    The same applies to creative work, disability access, identity exploration, education, and friendships. Calls to move children into the “real world” often assume that online life is somehow unreal. For many children—and adults—the internet is already where meaningful parts of life occur.

    Children possess rights before adulthood

    Nicholas Williams of Index on Censorship argued that child protection is too often placed in one conceptual box while freedom of expression is placed in another.

    The UN Convention on the Rights of the Child does not treat children solely as objects of adult protection. Children have rights to expression, participation, privacy, association, and access to information. Those rights may be limited for legitimate protective purposes, but they do not suddenly appear on a person’s eighteenth birthday.

    Dr. Kim R. Sylwander of the Digital Futures for Children centre developed that point through children’s evolving capacities. Numerical age is relevant, but children of the same age do not have identical needs, maturity, or circumstances. A single hard boundary can create a cliff that is poorly suited to developmental differences.

    The stronger question is not simply whether age assurance admits or excludes a child. Where it is used, does it enable a safer and age-appropriate experience while preserving agency and access?

    That is a much more demanding standard than placing a gate in front of an unchanged and potentially harmful product.

    One label, many systems

    “Age assurance” is an umbrella category. It includes verification, estimation, inference, self-declaration, parental confirmation, financial checks, device signals, and privacy-enhancing credentials.

    Each method answers a different question with different evidence. Each creates a different balance among confidence, privacy, accessibility, cost, and resistance to circumvention.

    Comparison of age-assurance methods across evidence required, confidence, privacy risk, exclusion risk, centralization risk, and likely failure.
    Comparison of age-assurance methods across evidence required, confidence, privacy risk, exclusion risk, centralization risk, and likely failure.
    Comparison of age-assurance methods
    Method Typical evidence Main advantage Principal risk
    Self-declaration Birthday or checkbox Minimal collection Easy to evade
    Document verification Government or authoritative record High confidence Identity-rich collection and exclusion
    Facial estimation Selfie or short video Lower friction than ID Threshold errors, demographic performance, image processing
    Behavioral inference Account activity and observed behavior No new document Continuous monitoring and opaque decisions
    Parental confirmation Verified adult approval Supports family features Does not prove relationship; unsafe for some children
    Financial/database check Card, bank, carrier, or brokered record Uses existing records Hidden data chain and economic exclusion
    Device/OS signal Age band from device, account, or app store Reduces repeated disclosure Centralized gatekeeping and shared-device problems
    Anonymous credential Cryptographic threshold proof Minimizes disclosure to the website Enrollment, recovery, revocation, and institutional control

    Self-declaration: private but weak

    A birthday field or “I am over eighteen” box collects relatively little information. It is also easy to evade.

    That makes self-declaration a plausible way to tailor low-risk experiences, but a poor mechanism for enforcing a hard prohibition. ISO/IEC 27566-1 treats self-assertion alone as ineffective for deciding access to age-restricted goods, content, services, venues, or spaces. Steve Wood’s 2026 review found that eleven of the seventy examined platforms still relied on self-declaration alone even as stronger age assurance became common across the wider sample.[2]

    The weakness of self-declaration is often used to justify stronger methods. That is the point at which privacy and access costs begin to increase.

    Documents and authoritative records: confidence bundled with identity

    A passport, driver’s license, national identity card, or birth record can supply a reliable date of birth when the document is genuine and belongs to the person presenting it.

    But a document contains far more than most websites need. A service asking only whether a user is over eighteen does not inherently need the person’s name, address, document number, nationality, photograph, signature, or exact birth date.

    A verifier can separate those attributes from the final result. The relying website may receive only “over eighteen.” That is a real improvement over handing a complete document to every website.

    It does not make the evidence disappear. The verifier, document-checking provider, identity authority, fraud service, or human reviewer may still process it.

    The important privacy question is therefore not merely what the website receives. It is what the whole system collects, transmits, retains, and can later connect.

    Facial estimation and behavioral inference: less conventional identity, new forms of surveillance

    Facial age estimation predicts an age or age range from a selfie or short video. Wood found it was the most commonly identified method among the twelve forms of age assurance used across the seventy services he examined.[2]

    Its appeal is obvious. It may be faster than finding a document, and the platform may never learn the user’s name. But the method still asks a person to place their face into a technical and commercial process. Liveness detection, anti-spoofing controls, device information, and a fallback document check may be added around the estimate.

    The hardest cases occur near the legal boundary. Distinguishing a young child from a middle-aged adult is different from distinguishing a seventeen-year-old from an eighteen- or nineteen-year-old. An error can either admit someone the rule intends to exclude or deny lawful access to someone entitled to enter.

    Behavioral inference creates a different problem. A platform can estimate age from account history, searches, videos watched, language, social relationships, school references, or other signals. This can be presented as less intrusive because no new document or selfie is requested.

    But the apparent advantage depends on repurposing information collected for other reasons. A checkpoint becomes continuous monitoring.

    An adult researching schools for a child, watching youth-oriented entertainment, or sharing an account with family members may resemble a minor. A child can also produce carefully selected adult-looking signals. The user may never learn which behavior triggered the decision.

    Parents, payments, and databases: convenient assumptions that fail many users

    Parental confirmation can support family accounts and age-appropriate settings. It cannot automatically prove a child’s age or establish that the adult is a safe and legitimate guardian.

    Some children do not have an available adult who can help. Others seek information precisely because the adults around them are hostile, controlling, abusive, or unsafe.

    Financial and commercial-record checks make different assumptions. A credit-card authorization may show access to an adult-controlled payment instrument, but not that the person at the keyboard is the cardholder. Cards can be borrowed, and many lawful adults do not have them.

    Commercial databases, phone-account checks, and open banking can rely on information assembled across data brokers, financial institutions, carriers, or identity services whose role is invisible to the user.

    These methods can make age assurance dependent on the same commercial surveillance economy that child-safety policy is often supposed to constrain.

    Device and operating-system signals: fewer checks, greater central power

    A phone, app store, console, or operating system can provide an age range to an application. This may reduce repeated disclosure: a user does not upload an ID to every service, and the application receives only a limited signal.

    The privacy of an individual interaction may improve while power becomes more concentrated.

    A small number of operating-system and app-store companies could become issuers of age-related permission for ordinary digital activity. Alternative operating systems, older devices, shared tablets, public computers, and platforms outside the approved ecosystem may be unable to produce the expected signal.

    Once the device can answer one age-related question, governments and companies may ask it to enforce additional rules for games, purchases, political information, health content, AI companions, or services unrelated to the original mandate.

    Anonymous credentials: the strongest technical answer, not a complete social answer

    Cryptography can prove a limited fact without revealing the underlying identity.

    Steven Bellovin describes a system in which a trusted issuer verifies a person’s age and supplies a private credential. The holder can derive unlinkable proofs such as “over eighteen.” A website verifies the proof without learning the person’s name, exact birth date, or source document.[8]

    That is substantially more private than sending an ID or selfie to each website.

    But someone must still enter the system. An issuer must decide which records are acceptable, verify them, fund the process, secure the credential, help users recover it, and determine whether it can be revoked. People without documents, private devices, transportation, stable housing, or technical assistance may remain excluded.

    Bellovin also identifies a paradox. If a credential is useful only for age-gated content, adults may lend it to minors. Making it valuable for banking, employment, public services, or other essential functions discourages sharing—but turns it into a far more consequential identity system.

    A private proof can exist inside a coercive institution.

    Privacy-preserving is not the same as anonymity-preserving

    A website may receive only an age threshold while the issuer, device operator, verifier, or surrounding metadata still allows transactions to be linked to one another or to a person.

    From one age check to internet infrastructure

    These methods are usually evaluated one transaction at a time: what does this website learn from this check? But the larger policy question emerges when the same signals, credentials, vendors, and device systems begin operating across many services.

    Moving assurance to the device is often described as the privacy solution.

    Instead of requiring every website to perform a separate check, the operating system or app store establishes or receives an age range and sends a limited signal to applications. The relying service learns less. Users repeat the process less often.

    Those advantages are real.

    So are the structural consequences.

    One device is not one person

    Families share phones, tablets, consoles, televisions, and computers. Libraries and community centers provide public devices. Schools issue devices that may be used by more than one student.

    A device-level signal must either assume one user, require reliable multi-user profiles, or repeatedly identify the person currently present.

    The first produces wrong results. The second depends on families configuring accounts correctly. The third reintroduces friction and surveillance.

    People with the least money, time, and technical expertise are often the most likely to share devices and the least able to maintain a complex multi-user assurance system.

    Alternative systems can become second-class

    A mandate tied to approved operating systems can disadvantage:

    • de-Googled Android builds;
    • Linux distributions;
    • older devices;
    • independent app stores;
    • accessibility-specific hardware;
    • public terminals;
    • devices made for markets outside the dominant ecosystem.

    The open internet historically allowed a standards-compliant browser to reach a service regardless of who manufactured the computer. Device-level eligibility can replace that principle with a chain of approved hardware, software, accounts, and issuers.

    The gatekeeper gains policy power

    Apple, Google, Microsoft, console companies, and major app stores could become intermediaries for age-related access across thousands of services.

    They would need to decide which evidence is accepted, which age bands exist, how shared devices work, how appeals operate, whether developers receive exact or coarse results, how often signals expire, and what happens after account suspension.

    A law aimed at platform safety can therefore increase the power of the largest platform companies.

    The European model shows both the promise and the risk

    The European Commission’s age-verification blueprint became technically ready for national customization in April 2026.[21] It can operate as a standalone application or be integrated into a future European Digital Identity Wallet. The Commission says the design can prove that a user satisfies a threshold without revealing identity or exact age, and it has urged Member States to make compatible tools available by the end of 2026.[22]

    That architecture is materially different from uploading a passport to every website. It separates issuance from presentation and is intended to reduce disclosure and cross-service tracking.

    Simeon de Brouwer of European Digital Rights warned that privacy-preserving intent does not end the governance analysis. Enrollment can still require a passport, identity card, national eID, banking application, or in-person authority. Identity providers and relying services may face legal demands, implementation errors, metadata correlation, or later architectural changes.

    Perfect enforcement creates pressure for more identity

    Every method can be evaded somehow:

    • users can lie;
    • documents can be borrowed or forged;
    • adults can complete checks for minors;
    • facial systems can be spoofed;
    • accounts and credentials can be transferred;
    • behavior can be manipulated;
    • users can move to another site or jurisdiction;
    • a VPN can change apparent location.

    A government dissatisfied with those results can escalate:

    1. require a stronger method;
    2. bind the result to a device;
    3. add liveness or biometrics;
    4. repeat the check;
    5. monitor behavior for inconsistency;
    6. restrict anonymous access or VPNs;
    7. retain logs for enforcement;
    8. connect the credential to a persistent identity;
    9. penalize platforms for any successful evasion.

    The Global Network Initiative’s multistakeholder review identifies the central limit: policymakers should not demand complete resistance to circumvention when achieving it requires unacceptable privacy and rights costs.[9]

    The endpoint may not be a perfectly safe internet. It may be an internet in which every user is continuously classifiable and access can be revoked.

    Escalation ladder showing how efforts to prevent evasion can move from self-declaration toward persistent identity and behavioral monitoring.
    Escalation ladder showing how efforts to prevent evasion can move from self-declaration toward persistent identity and behavioral monitoring.

    AI companions are the next expansion point

    The panel’s closing discussion anticipated the rapid movement of age-assurance policy from social media to chatbots and AI companions.

    These systems create distinct risks:

    • emotionally dependent relationships;
    • simulated grooming or sexual conversation;
    • encouragement of self-harm;
    • manipulation;
    • hallucinated personal or medical advice;
    • collection of intimate disclosures;
    • profiling from continuous conversation.

    An age signal may help apply different safeguards. But a chatbot is not simply another social-media feed. It responds privately, adapts to the user, and may become a confidant.

    Wood found regulatory gaps around AI chatbots and warned that companies may define their own child-safety standards without clear public rules.[2] The report recommends explicit coverage, risk tiers, and obligations addressing simulated grooming and emotional dependency.

    The UK moved further while this article was in production. Its July 2026 package proposes blocking under-eighteens from AI services primarily offering sexualized content, restricting sexual role-play features on other chatbots, and considering protections such as mandatory breaks and limits on systems offering mental-health advice. These were announced proposals, not yet final operating rules.[18]

    A device-level age signal may be deployed before governments have decided what an age-appropriate AI relationship should be.

    What real deployments reveal

    That infrastructure concern is not merely hypothetical. Existing deployments show how quickly a binary age result can create concentrated intermediaries, multi-company data flows, and incentives for broader enforcement.

    The 2026 study Papers, Please: A First Look at Age Verification on the Web built technical signatures for age-assurance providers and crawled a large set of popular websites from Texas, Georgia, and New York. The researchers found more detected age-verification deployments in the two states with mandates than in the control state, showing that state law can change what users encounter online.[3]

    They also found a concentrated market. Yoti appeared on more than sixty percent of detected deployments in the mandate-state crawls. A rule applied across many websites can therefore create a small number of central intermediaries through which sensitive transactions pass.

    Apparent compliance remained low

    The researchers used the voluntary “Restricted to Adults” label as a rough proxy for sites likely to contain covered material. Only about fourteen percent of those labeled sites in Texas and Georgia had detectable age verification.

    That is not a definitive legal compliance rate. The label is voluntary, the laws differ, and the detection system can miss implementations.

    It nevertheless illustrates a basic enforcement problem: a user who refuses a check can often move to a site that does not impose one. A compliant service adds friction and loses traffic; a noncompliant competitor can absorb it.

    The result may be a two-tier internet in which well-known services implement intrusive gates or withdraw while less accountable sites gain users.

    A binary result can require a large data supply chain

    The website is often only the relying party. The user is redirected to a verifier, which may contact other services for network location, payment processing, document validation, fraud detection, database matching, or manual review.

    The researchers observed browser and device information that could contribute to fingerprinting. They also identified method-specific connections to outside services. In a card-based flow, Stripe could receive contextual information about the originating service; a bank could learn that a Yoti transaction occurred. Government-ID workflows could involve additional identity and document-validation partners.[3]

    Not every method sends every data type to every party. Precision matters. But the central lesson survives: a binary result can be produced by a much richer data chain.

    Data-flow diagram showing a user, device, website, age-assurance provider, and method-specific outside parties.
    Data-flow diagram showing a user, device, website, age-assurance provider, and method-specific outside parties.

    The correction matters

    Yoti challenged an allegation that facial images used for facial age estimation were shared with third parties. Georgia Tech and the University of California, Irvine removed that allegation after review, according to Yoti’s June 2026 update.[4]

    A responsible account must not repeat the withdrawn claim.

    The correction does not automatically resolve the study’s separate findings about device metadata, market concentration, particular outside services, retention statements, or the security test in which researchers substituted a prepared image during the browser capture process. Each claim must be evaluated on its own evidence.

    The episode is also a reminder that privacy reporting must identify the exact method, recipient, and data flow. “The vendor shares user data” is too broad to be useful. Which data? In which workflow? With whom? For what purpose? For how long?

    What responsible deployment is supposed to require

    The Digital Trust & Safety Partnership’s best-practices framework is more candid than many political descriptions of age assurance. It says no approach is one-size-fits-all and that accuracy, privacy, inclusion, circumvention resistance, and affordability can conflict.[5]

    Its principles call for:

    • assessing the actual risk to young people;
    • selecting a proportionate method;
    • treating privacy and data protection as part of design and ongoing evaluation;
    • ensuring inclusion and accessibility;
    • using layered enforcement rather than assuming one check solves every problem;
    • explaining practices publicly and reporting on effectiveness.

    The framework’s value is that it rejects the idea that the most invasive method is automatically the most responsible.

    Its limitation is equally important. It is a best-practices document, not evidence that companies follow those practices or that a deployment reduces harm. “Layered enforcement” can mean careful escalation from a low-intrusion method, but it can also become continuous monitoring followed by facial or document verification.

    ISO/IEC 27566-1 contains serious safeguards

    ISO/IEC 27566-1:2025 is the most formal effort in this source set to describe what an age-assurance system should look like. It covers functional performance, privacy, security, accessibility, complaints, and public practice statements.[6]

    The standard is more privacy-conscious than a superficial description might suggest.

    It calls for minimum necessary collection, discourages disclosure of exact age or underlying evidence when a limited result will suffice, and establishes a presumption that personal data used to create a result should be deleted afterward. Audit logs must not contain biometric images or copies and extracted data from identity documents.

    It also asks whether providers or relying parties can correlate the same person across services, whether collaborating sites can recognize a user, whether a verifier can learn where a result is used, and whether a token can be linked to an identity.

    The standard requires systems to be testable and calls for reporting of classification accuracy, false approvals, false denials, demographic error parity, completion rates, performance, and scalability.

    Complaint processes and practice statements are expected to explain how users can challenge inaccurate or incomplete information, automated decisions, and security incidents.

    These are meaningful protections.

    The standard leaves central policy questions unresolved

    The framework also permits reusable credentials, provider accounts, stored attestations, and memorized results. It does not impose complete unlinkability, one universal accuracy threshold, a mandatory independent appellate body, or an unambiguous requirement that every deployment undergo recurring third-party audit.

    Most importantly, it does not decide whether age assurance is necessary in a particular context, whether the threshold is justified, or whether the intervention will reduce the targeted harm.

    What ISO/IEC 27566-1 does

    • Defines system actors and age-related results
    • Addresses minimization, deletion, security, testability, inclusion, complaints, and transparency
    • Recognizes tracking and cross-service correlation as privacy risks
    • Supports audits, certification, and practice statements

    What it does not do

    • Prove that a gate is necessary or proportionate
    • Establish that children will be safer
    • Require complete anonymity or unlinkability
    • Guarantee an independent appeal or recurring independent audit
    • Prevent a compliant system from becoming part of broader identity infrastructure

    A technically competent gate can still be attached to an unjustified wall.

    Standards are also governance

    Technical standards increasingly function as implementing rules for public policy. Legislatures can reference them, regulators can treat them as evidence of due diligence, and companies can use conformity claims to win contracts or defend practices.

    That makes participation a question of power.

    Emma Day and Sabine Witting warn that labels such as “privacy-preserving,” “fair,” and “rights-respecting” can become rights-washing when they are defined without meaningful human-rights expertise. Standards processes demand fees, sustained staff time, technical submissions, and repeated meetings. Large companies can participate continuously; civil-society and children’s-rights organizations often cannot.[7]

    The issue is not that engineers should be excluded. It is that technical decisions embed assumptions about acceptable error, identity, anonymity, access, and enforcement. Those are legal, social, and political decisions too.

    The governance questions should include:

    • Who drafted the rule?
    • Which sectors and regions were represented?
    • Were children or organizations representing their rights included?
    • Who certifies compliance?
    • Who selects and pays the auditor?
    • Are the major results public?
    • Can regulators inspect the evidence?
    • Can users challenge a conformity claim?

    A standard can improve safety and privacy. It can also make contested infrastructure easier to procure, certify, and scale.

    What regulation has changed—and what remains unproven

    Steve Wood’s Phase II study provides the best available bridge between policy and outcome. It examined seventy social-media, video, gaming, and AI platforms and documented 108 child-safety and privacy changes between 2024 and 2026.[2]

    The findings show that regulation is having effects. They also show why counting changes is not enough.

    Regulation is producing visible activity

    Wood found new measures across Meta, Google, TikTok, Snapchat, and thirty-one other platforms. Across the wider set of services, protections enabled by default were the largest category of change, with age assurance the largest subcategory.

    Examples included:

    • private or more restricted accounts;
    • reduced geolocation;
    • limits on targeted advertising;
    • content filters;
    • restrictions on adult-to-child contact;
    • age checks for chat or adult features;
    • protective upload warnings;
    • parental time controls;
    • reporting and support tools.

    Some changes were directly linked to the UK Online Safety Act or interventions by the UK Information Commissioner’s Office.

    Major platforms shifted responsibility toward families

    Among Meta, Google, TikTok, and Snapchat, the pattern changed. Earlier regulatory pressure had produced more protections enabled by default. During 2024–2026, the greatest volume of changes shifted toward user-operated tools, especially parental controls.

    A default protection works without a child or parent finding, understanding, and activating it. A tool transfers responsibility to the user.

    That matters because families vary in time, digital literacy, language, safety, technical skill, and household relationships. A platform can announce a control that few people use and still count it as a safety measure.

    Wood found that platforms did not publish comprehensive, independently audited data on the use or performance of parental controls. Some outside research suggested limited effectiveness as a standalone response to compulsive use.[2]

    Age assurance was widespread, but transparency was weak

    Most of the seventy platforms had some form of age assurance, although the researchers could not identify it on thirteen. They found twelve types of mechanism, and most services with age assurance offered more than one option.

    Offering alternatives can reduce exclusion. A person without photo ID may use a facial estimate; someone who cannot or will not provide a face may use another method.

    But multiple choices do not guarantee rights-respecting implementation. Wood found that platform explanations often failed to identify the standards the system followed, and the study did not test whether the mechanisms were accurate or effective.

    A majority of platforms with age assurance in place relied on in-house solutions (31) rather than third-party providers (23). Some platforms used both: in-house for one method, such as behavioral inference, and a third-party vendor for another, such as facial age estimation. Yoti was the most-used third-party provider.[2]

    Ofcom’s first statutory report shows scale and displacement

    On July 15, 2026, Ofcom published its first statutory assessment of age assurance under the Online Safety Act. Thirty-two sampled services reported more than 69 million completed age checks between July and December 2025—twenty-three times the number reported in the preceding six months. Ofcom described the findings as early and warned that the sample was not representative of an entire sector.[19]

    The regulator found signs that checks were deterring some children from pornography and that the largest sites had broadly implemented gates. It also found that almost half of the pornography services visited by children had no age checks, while some noncompliant sites gained traffic as gated competitors lost it.

    Several social platforms continued to depend on proprietary behavioral inference that Ofcom did not accept as inherently capable of being highly effective.[19]

    This is the evidence ladder in action:

    Law enacted → regulator acts → system deployed → behavior changes → exposure changes → harm declines

    Most public evidence currently establishes the first three stages. Evidence becomes much thinner at exposure and actual harm.

    Ofcom itself stated that no method eliminates circumvention and called for vendor due diligence, privacy compliance, and system-wide involvement by search engines, app stores, operating systems, and device providers.[19]

    Those recommendations may improve enforcement while also accelerating the infrastructure expansion examined in this article.

    Design rules have produced some of the clearest privacy gains

    The most concrete improvements in Wood’s research came from specific design and data rules:

    • reducing precise geolocation;
    • making profiles private by default;
    • limiting personalized advertising to minors;
    • restricting contact;
    • adding protective prompts;
    • filtering certain content;
    • changing recommendation behavior.

    These interventions target the environment rather than requiring every user to prove eligibility before entering it.

    That does not make age assurance irrelevant. A service may need an age signal to apply the correct protections. But the signal should enable safer design, not substitute for it.

    The global inequality problem

    The Digital Rights Alliance Africa report covers Algeria, Botswana, Egypt, Ghana, Kenya, Nigeria, Rwanda, South Africa, Tanzania, and Uganda. It treats privacy as both a protective and enabling right: children need it not only to avoid exploitation but to learn, communicate, explore identity, and exercise expression.[10]

    The report identifies laws and policies across the region, but repeatedly returns to implementation:

    • many legal frameworks are general rather than child specific;
    • regulators and enforcement bodies lack resources;
    • digital literacy is uneven;
    • rural users may lack secure connectivity;
    • international standards are adopted slowly or incompletely;
    • parents and caregivers may lack the knowledge assumed by consent-based systems;
    • companies operate across borders that local complainants and regulators struggle to cross.

    Only a minority of African Union states had ratified the Malabo Convention at the time of the report, and the convention itself lacks detailed child-specific privacy rules. The African Union’s 2024 Child Online Safety and Empowerment Policy recognizes safety, privacy, participation, best interests, and non-discrimination, but national implementation remains uneven.[10]

    A technically neutral rule can deepen inequality

    Consider a law that permits government ID, smartphone-based facial estimation, or a mobile-network check.

    For a well-documented urban adult with a current phone, stable connectivity, and technical confidence, the process may be inconvenient.

    For a person without a recognized birth record, national ID, private device, data plan, accessible interface, nearby government office, or ability to pay, the same rule can become exclusion.

    A country with lower internet penetration may lose more from blocking lawful users because the network already reaches fewer people. A government with a history of surveillance or political repression creates additional risks when identity infrastructure becomes attached to speech and association.

    Bridgette Ndlovu’s panel remarks emphasized that identity coverage and connectivity cannot be assumed. Patricia Ainembabazi stressed that technologies adopted in African countries are often designed elsewhere, with little input from the people governed by them. Annette Opiyo centered proportionality, evidence, accountability, inclusion, and child participation.

    These are not regional side issues. They expose weaknesses in the universal model.

    Children must participate in the design

    CIPESA argues that children are not only vulnerable users but active participants in learning, play, creativity, and social life. Its work on AI governance calls for children’s experiences to shape systems from the beginning, including limits on profiling and manipulation, data minimization, independent audits, and AI literacy.[11]

    Its 2026 policy-to-practice article similarly calls for child-specific laws, funded institutions, accountable platforms, transparency, independent audits, and meaningful participation by young people.[12]

    Children should be asked:

    • Which services matter to them and why?
    • What harms do they experience?
    • Which controls help?
    • Which restrictions drive them elsewhere?
    • What happens when a parent is not safe?
    • What appeal process would they understand?
    • How do age rules affect disabled, rural, queer, migrant, low-income, or undocumented young people?
    • Which protections should apply to everyone rather than only minors?

    Participation does not mean children decide every legal question. It means policy is not designed around an imagined average child who has no voice, no agency, and a safe adult standing nearby.

    A rights-respecting test for any proposal

    Before procurement, certification, or deployment, policymakers should answer the following questions.

    Fifteen-question checklist covering necessity, data use, performance, accountability, expansion risk, and participation.
    Fifteen-question checklist covering necessity, data use, performance, accountability, expansion risk, and participation.
    1. What specific harm is being addressed? “Protect children” is an objective, not a defined problem. Pornography, grooming, compulsive use, targeted advertising, gambling, and AI companionship require different interventions.

    2. What evidence connects an age gate to that harm? Explain the causal theory and how displacement, circumvention, and unintended effects will be measured.

    3. Have less intrusive design measures been tried? Consider safer defaults, contact restrictions, advertising limits, recommendation changes, moderation, reporting, product liability, and consumer-protection enforcement.

    4. What does the service actually need to know? Identity, exact age, age range, or one temporary threshold result are not equivalent.

    5. What data are collected from the person and device? Include documents, images, biometrics, financial details, IP address, device characteristics, behavior, location, and fraud telemetry.

    6. Who receives the data? Identify the platform, verifier, operating system, app store, document validator, bank, processor, data broker, cloud provider, reviewer, and subprocessor.

    7. What is retained, and for how long? Separate original evidence, images, document data, device information, age results, credentials, transaction logs, and complaint records.

    8. Can transactions be linked? Determine whether the provider, issuer, collaborating websites, or surrounding metadata can recognize the same person across services or over time.

    9. What are the errors? Publish threshold-specific false approvals, false denials, demographic disparities, completion rates, abandonment, and accessibility failures.

    10. What alternatives exist? A lawful user should not lose access because they lack an ID, credit card, smartphone, camera, private device, safe parent, stable internet, or conventional records.

    11. What happens when the system is wrong? Require clear notice, understandable reasons, human review where appropriate, correction, restoration of access, deadlines, and independent escalation.

    12. Who tests and audits the system? Testing should occur before launch and regularly afterward. Auditors need expertise in security, privacy, accessibility, discrimination, and children’s rights.

    13. What prevents secondary use? Age-assurance evidence should not become material for advertising, general profiling, AI training, unrelated fraud models, political surveillance, or data-broker sale.

    14. What is the expansion boundary? State which services are covered, who may add categories, when legislative approval is required, how necessity is reviewed, and when the authority expires.

    15. Were children and affected communities involved? Include users of different ages, abilities, locations, incomes, identities, family circumstances, and patterns of internet access.

    The better question

    Age assurance is often presented as a contest between safety and privacy.

    That framing is too narrow.

    The policy choice affects safety, privacy, anonymity, expression, association, equality, competition, device freedom, platform power, government identity, technical standards, children’s participation, and the architecture of the internet.

    Some age-related protections will require some knowledge of age. Some systems can disclose much less than others. Standards can meaningfully reduce collection, retention, tracking, error, and exclusion.

    None of those facts establishes that a gate should exist everywhere a child might encounter risk.

    The clearest evidence in the source set is not that age assurance has solved online harm. It is that regulation is rapidly producing infrastructure: vendor markets, facial-estimation systems, reusable credentials, app-store signals, audit schemes, practice statements, and enforcement expectations.

    Infrastructure persists. It becomes interoperable. It attracts investment. It gains new uses.

    That is why the most important question must come before the technical one.

    Not: How do we verify everyone’s age?

    But: What specific protection do children need here, and can we provide it without turning identity or eligibility into the price of ordinary participation online?

    The answer will not be identical for pornography, gambling, a public encyclopedia, a multiplayer game, a support forum, an encrypted messenger, a school tool, or an AI companion.

    That is not a failure of policy.

    It is the complexity that rights-respecting policy must be willing to face.

    Related reading

    For a set of concrete, Oregon-specific illustrations of how a poorly built age-verification system could go wrong — including immigration-enforcement exposure, data breaches, and custody-dispute subpoenas — see When “Protecting Kids” Goes Wrong.


    Source notes

    1. [1] Event recording and working transcript. Software Freedom Law Center, India, What Age Assurance Means for the Future of Digital Rights, Online Safety, and the Internet at Large, July 16, 2026. Recording: https://www.youtube.com/watch?v=euSkCvhzweQ. The event discussion is based on a locally generated Whisper transcript; any exact quotation should be checked against the recording.
    2. [2] Steve Wood, Digital Futures for Children / London School of Economics and 5Rights Foundation. Impact of Regulation of Children’s Digital Lives: Phase II and Appendices A and B, May 2026. https://www.digital-futures-for-children.net/our-work/regulation-impact 1 2 3 4 5 6
    3. [3] Shreyas Minocha, Isaac Sheridan, Harry Oppenheimer, Paul Pearce, and Michael A. Specter. Papers, Please: A First Look at Age Verification on the Web, 2026. https://mikespecter.com/assets/pdf/AgeVerification.pdf 1 2
    4. [4] Yoti. An open letter to Georgia Institute of Technology and University of California, Irvine requesting retraction and correction of false statements, updated June 19, 2026. https://www.yoti.com/blog/open-letter-to-georgia-institute-of-technology-university-of-california-irvine-requesting-retraction-correction-false-statements/
    5. [5] Digital Trust & Safety Partnership. Age Assurance: Guiding Principles and Best Practices, September 2023. https://dtspartnership.org/age-assurance-guiding-principles-best-practices/
    6. [6] ISO/IEC 27566-1:2025. Information security, cybersecurity and privacy protection — Age assurance systems — Part 1: Framework. Public record: https://www.iso.org/standard/88143.html. The analysis is paraphrased from a lawfully obtained single-user copy.
    7. [7] Emma Day and Sabine Witting. Human Rights Experts Should Engage in Age Assurance Standards, Tech Policy Press, June 29, 2026. https://www.techpolicy.press/human-rights-experts-should-engage-in-age-assurance-standards/
    8. [8] Steven M. Bellovin. Privacy-Preserving Age Verification—and Its Limitations, October 2025. https://www.cs.columbia.edu/~smb/papers/age-verify.pdf
    9. [9] Hilary Ross, Global Network Initiative. Examining the Rights Implications of Age Assurance Requirements, July 6, 2026. https://globalnetworkinitiative.org/examining-the-rights-implications-of-age-assurance-requirements/
    10. [10] Digital Rights Alliance Africa. Child Protection and Safety Online in Africa: The Law, Privacy, Challenges and Solutions, June 2025. https://digitalrightsalliance.africa/download/child-protection-and-safety-online-in-africa/ 1 2
    11. [11] Patricia Ainembabazi, CIPESA. Elevating Children’s Voices and Rights in AI Design and Online Spaces in Africa, July 18, 2025. https://cipesa.org/2025/07/elevating-childrens-voices-and-rights-in-ai-design-and-online-spaces-in-africa/
    12. [12] Patricia Ainembabazi, CIPESA. Protecting Children Online in Africa Must Move from Policy to Practice, June 11, 2026. https://cipesa.org/2026/06/protecting-children-online-in-africa-must-move-from-policy-to-practice/
    13. [13] Australian Department of Infrastructure, Transport, Regional Development, Communications, Sport and the Arts. Minimum age for social media access, December 11, 2025. https://www.infrastructure.gov.au/department/media/news/minimum-age-social-media-access
    14. [14] eSafety Commissioner. Platforms restrict access to 4.7 million under-16 accounts across Australia, January 16, 2026. https://www.esafety.gov.au/newsroom/media-releases/platforms-restrict-access-to-47-million-under-16-accounts-across-australia
    15. [15] eSafety Commissioner. Five social media platforms flagged for compliance issues, March 31, 2026. https://www.esafety.gov.au/newsroom/media-releases/five-social-media-platforms-flagged-for-compliance-issues
    16. [16] eSafety Commissioner. eSafety begins evaluation of Australia’s world-first social media minimum age, February 26, 2026. https://www.esafety.gov.au/newsroom/media-releases/esafety-begins-evaluation-of-australias-world-first-social-media-minimum-age
    17. [17] UK Department for Science, Innovation and Technology. Fact sheet: New rules to protect children online, updated July 17, 2026. https://www.gov.uk/government/publications/fact-sheet-new-rules-to-protect-children-online/fact-sheet-new-rules-to-protect-children-online
    18. [18] UK Department for Science, Innovation and Technology. New social media curfews and crackdown on addictive features to better protect 16- and 17-year-olds online, July 15, 2026. https://www.gov.uk/government/news/new-social-media-curfews-and-crackdown-on-addictive-features-to-better-protect-16-and-17-year-olds-online
    19. [19] Ofcom. Use of Age Assurance Report 2026, July 15, 2026. https://www.ofcom.org.uk/online-safety/protecting-children/use-of-age-assurance-report-2026 1 2 3
    20. [20] Korea Legislation Research Institute. English statutory record for Article 44-5 of the former Act on Promotion of Information and Communications Network Utilization and Information Protection. The record states that paragraph (1) 2 was deleted in 2014 pursuant to the Constitutional Court’s August 23, 2012 unconstitutionality decision. https://elaw.klri.re.kr/eng_service/lawViewContent.do?hseq=46968
    21. [21] European Commission. The EU approach to age verification, updated May 13, 2026. https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification
    22. [22] European Commission. Commission urges Member States to rollout EU age verification app, April 29, 2026. https://digital-strategy.ec.europa.eu/en/news/commission-urges-member-states-rollout-eu-age-verification-app
  • Request to pull July 15 agenda items 4D and 4F for brief discussion

    All good questions that I believe we can answer in time. Maybe not fully before the meeting this evening but please know that Juan Olmeda, our IT Director, and I will be on hand tonight to help answer what we can. 

    Thx. 

    Sent from my iPhone

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

    Hi Mike,

    Thank you again for the thorough response. I appreciate you coordinating with IT and Engineering staff, and I also appreciate that you and staff will be available tonight if Council has additional questions.

    Your response answered many of the questions I raised and was helpful in understanding how the City is approaching these systems. Given that Council may act on these items tonight, I would appreciate any additional responses staff can provide before or during the meeting. If some of these questions require more time, it would still be helpful for Council and the public to know which items remain under review.

    On the Aclara item, you noted that Aclara retains approximately three years of meter-reading history in the cloud, while the City’s on-premises database currently retains that data indefinitely. Is there a formal retention policy for the City-held meter data, and what is the operational reason for indefinite retention?

    You also noted that access is role-based and activity is logged. Is there a periodic audit process for those logs? If so, how often are they reviewed, and by whom?

    You mentioned that meter data may be released through the public records request process. Given that hourly, address-specific water-use data can potentially reveal household routines, occupancy patterns, vacations, caregiving patterns, or other sensitive details, has the City considered whether any Oregon public-records exemptions, redaction practices, or special review procedures should apply before releasing that kind of granular utility data?

    I also noticed that WaterSmart/WaterWise does not appear to be discussed in the public agenda packet. Since staff’s response indicates that meter data is integrated with that platform, could the City clarify what data is shared with it and what privacy, retention, vendor-use, and security terms govern that relationship?

    Finally, does the Aclara agreement itself limit Aclara’s use of City or customer data, separate from the City’s own stated limits on use of the data?

    On the ProjectTeam item, your response identifies several important controls, including MFA, role-based access controls, encryption, logging, security assessments, AWS hosting, and cyber-liability insurance.

    For my understanding, has the City directly reviewed the underlying SOC 2, FedRAMP, GovRAMP, or comparable documentation as part of its security review, or is the City relying on vendor representations for some of those controls? Also, has the City reviewed a full list of subprocessors beyond AWS, and what is the contractual breach-notification timeline?

    I do not raise these questions as criticism of staff or of either procurement. My larger concern is that privacy and cybersecurity issues now appear in many routine systems, including utilities, cloud platforms, GIS tools, permitting systems, transit technology, and contractor portals.

    This exchange has been helpful because it shows how much important information may not be visible in the public packet alone. My hope is that Bend can eventually build a standard privacy and cybersecurity checklist into technology procurements and renewals, so these questions are considered consistently and early.

    Thank you again for taking the time to engage on this. I appreciate it.

    Best,

    Jonathan Westmoreland
    Bend Privacy Alliance

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

    Hi Jonathan – Thank you for reaching out.  I have connected with fellow IT and Engineering staff and have two follow up responses below for you below.  I am hoping that these address the primary concerns outlined in your earlier email.  Staff and I will plan to be at City Council meeting tonight (starts at 6pm) to help answer any additional questions regarding items 4D and 4F.

    Item 4F – Aclara

    The City’s Advanced Metering Infrastructure (AMI) system uses Aclara to collect water meter readings, including the account number, meter read, and the date and time of the reading. Customer information is uploaded daily from the City’s financial system into Aclara to support Utility Billing research and customer service activities. Regarding data retention, Aclara retains approximately three years of meter-reading history in its cloud environment, while the City’s on-premises database currently retains the data indefinitely. Access to individual household water-use histories is restricted to staff who have been provided an Aclara account based on specific job responsibilities.

    Data transmissions are encrypted, and data stored within Aclara’s cloud environment and the City’s SQL databases are also encrypted. Access is restricted based on role and activity is logged. Data may be released through the public records request process, and the City’s use of meter data is limited to billing, system maintenance, leak detection, customer-requested services, and integration with WaterSmart, a customer-facing water conservation and leak-detection platform. Aclara personnel has remote access to customer data when performing maintenance or supporting system infrastructure, such as work related to the data collection units (DCUs) that receive meter transmissions.

    • Advanced Metering Infrastructure (AMI): A system of smart water meters and communications equipment that automatically collects and transmits meter readings without requiring manual meter reading.
    • Aclara: The vendor platform used by the City to collect, store, and manage automated water meter readings.
    • Data Collection Unit (DCU): Communications equipment that collects data transmitted from smart meters and forwards it to the utility’s management systems.

    Item 4D -ProjectTeam Cloud Platform

    IT and Information Security reviewed the vendor’s controls and confirmed that several key security requirements have been met. The vendor verified that multifactor authentication (MFA) will be required for all City employees, contractors, and vendor accounts. The application further provides Role-Based Access Controls (RBAC) for granular user authentication and enforcement of least-privilege access. In addition, the vendor confirmed that all City data and backups are encrypted both in transit and at rest, helping protect sensitive information throughout its lifecycle. The review also found that the vendor has undergone recognized security assessments and maintains GovRAMP and FedRAMP compliance (please see below for more information), while its hosting provider, AWS, maintains SOC 2 Type II and SOC 3 compliance.

    The review further confirmed that least-privilege access controls are enforced for all internal and external users and that user activity, including access events, is logged. The vendor identified AWS as the hosting provider responsible for storing and maintaining City data, satisfying the requirement to disclose and review entities that may possess City information. The vendor confirmed that they maintain appropriate cyber-liability insurance.

    FedRAMP (Federal Risk and Authorization Management Program) is the U.S. federal government’s standardized framework for assessing, authorizing, and continuously monitoring the security of cloud services used by federal agencies.

    • GovRAMP (Government Risk and Authorization Management Program) is a similar security validation program designed for state and local governments. It evaluates cloud providers against established cybersecurity controls and provides an independent assessment of their security posture.

    The vendor’s compliance with both FedRAMP and GovRAMP indicates that it has undergone rigorous third-party security reviews and maintains cybersecurity controls that align with government-sector standards.

    Reach out if we need to connect this afternoon.  Otherwise, I am happy to connect before or during tonight’s meeting.

    Thank you!

    Mike Buettner

    PUBLIC WORKS DIRECTOR

    Public Works

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

    Mayor Kebler,

    Thank you, I appreciate the quick response.

    I understand that any Councilor may choose to pull an item from the consent agenda during the meeting. I would also appreciate staff responses when they are available.

    Because these items are scheduled for possible approval tomorrow night, I hope at least the key privacy and cybersecurity questions can be addressed before or during the meeting, so Council and the public have that information before action is taken.

    Thank you again.

    Jonathan Westmoreland
    Bend Privacy Alliance

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

    Hi Jonathan,

    Thanks for your questions. If a Councilor wishes to pull an item from the consent agenda item tomorrow night, they can certainly do so. I will also ask staff respond when they are able to your questions via email so you have the information.

    Thanks,
    Melanie

  • Signals & Safeguards Issue 14: Age Verification, ALPR Accountability, and Searchable Systems

    Signals & Safeguards

    Issue 14 • Wednesday, June 17, 2026

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

    At a glance

    • Section 702 expired legislatively, but the warrant fight did not end.
    • ALPR accountability is no longer hypothetical: misuse, tracking claims, private-camera sharing, and audit-log gaps are now concrete governance problems.
    • Cyber patch windows are shrinking as exploited vulnerabilities, AI-assisted attacks, and research-sector targeting accelerate.
    • Identity checks are spreading into phones, age verification, platform access, and encrypted communications.

    Section 702 expired on paper, but the warrant fight did not

    Congress allowed Section 702 to lapse after a short-term extension failed, but the practical surveillance fight is not over. Reuters explains that Section 702 allows warrantless collection targeting foreigners abroad, while also sweeping in communications involving Americans. The Guardian, AP, and the Brennan Center all point to the same unresolved question: when U.S. person communications are searched, should the government need a warrant?

    The important nuance is that “expired” does not necessarily mean “stopped.” Existing certifications may allow surveillance activity to continue for a period even after the statutory deadline. That makes the public-facing safeguard question sharper, not weaker. The debate is no longer only about whether Section 702 exists on paper. It is about whether searches involving Americans’ communications should require clear legal authority before they happen.

    The warrant issue also became entangled with unrelated politics. Reuters reported that Trump opposed renewal unless it was paired with proof-of-citizenship voting legislation. That does not change the civil-liberties question. A surveillance law that can reach Americans’ communications should not depend on unrelated legislative leverage.

    Why it matters for Bend: Section 702 is a federal intelligence law, not a city camera program. But the governance lesson travels. Broad search authority, weak front-end limits, secret interpretations, and after-the-fact review can become normalized unless public institutions insist on clear authority, narrow access, and usable oversight before sensitive searches occur.


    ALPR accountability is no longer hypothetical

    Automated license plate reader oversight is now an evidence problem, not a theory problem. Recent reporting shows officer misuse, private-camera networks, retail deployments, vendor-access questions, leaked search metadata, event-surveillance buildouts, and disagreement over whether systems “track people” or simply record vehicles.

    InvestigateTV / WRDW reported that Flock says its cameras do not track people, while training material describes following vehicles or suspects from “location to location.” 404 Media reported on police officers arrested or accused after allegedly using Flock systems to stalk or monitor people. AP reported on a Westchester County lawsuit involving a large ALPR system with 1.6 billion scans, nearly 600 cameras, and access by more than 50 outside agencies.

    The same issue is spreading beyond police-owned cameras. Retail parking-lot ALPR systems can still become public-safety data sources if their databases are shared, searched, or made available to law enforcement. Dayton Daily News and other reporting on retailers using Flock cameras show why “private” does not always mean “outside public surveillance.”

    The safeguard question is not only whether a camera reads plates. It is who can search the resulting record, how long the data is kept, whether outside agencies can query it, whether private databases can become police tools, whether vendor employees can access the system, and whether every search can be audited later.

    Why it matters for Bend: Bend already learned that access rules matter before systems go live. Any ALPR proposal should be judged by the audit trail it creates, not only by the problem it promises to solve. A system that cannot answer who searched, why they searched, what they saw, and whether the result was shared is not just missing a technical feature. It is missing the oversight system.


    Patch windows are shrinking because exploitation is getting faster

    Cybersecurity is becoming a timing problem. Reuters reported that U.S. officials shortened the remediation window for certain exploited vulnerabilities to three days as AI-assisted threats rise. CISA also continued adding known exploited vulnerabilities to its catalog, reinforcing the same practical lesson: once a flaw is being actively exploited, public agencies may not have weeks to decide what to do.

    The current-week examples cut across sectors. Reuters reported that Chinese-linked hackers targeted U.S. and Canadian research facilities over the past year, including academic, medical, military, AI, unmanned-vehicle, cyber-warfare, and medical-research targets. Reuters also reported cyber incidents involving iRhythm and an attempted extortion claim involving Novo Nordisk.

    The lesson for public institutions is not simply “patch faster.” It is to know which systems are exposed, who owns the fix, whether the vendor has patched, whether logs were reviewed, whether credentials or accounts changed, and whether dependent systems are affected. Cybersecurity is no longer only an IT department issue. It is public infrastructure governance.

    Why it matters for Bend: Cities, counties, schools, clinics, libraries, utilities, and vendors all depend on systems that can become public-sector risk points. Officials do not need to understand every exploit. They do need clear answers about exposure, patch timing, vendor proof, log review, and continuity plans.


    Shared pattern: searchability is the power

    The strongest stories this week point in the same direction: searchable systems need visible safeguards. Section 702 raises the question of who can search communications and under what authority. ALPR systems raise the question of who can search movement records and whether misuse can be proven. Cyber incidents expose the risk of large stores of sensitive data. Identity systems decide who must prove themselves before ordinary access. Police-tech platforms determine what becomes searchable next.

    The safeguard question is the same across all of them: who can search, why can they search, what legal authority applies, how long data is kept, whether vendors can access it, and whether misuse can be detected after the fact.


    Warning Signals

    Warning Signals

    These items point toward where search power, identity checks, platform access, vendor systems, and data governance may be heading next.

    Private cameras can still become public surveillance systems

    Retail ALPR systems are a reminder that “private” cameras can still become public-safety infrastructure. Dayton Daily News reported on Flock cameras used by retailers and shopping centers, while other reporting has pointed to Lowe’s, Home Depot, and similar parking-lot deployments.

    The privacy issue is not only who owns the pole or camera. It is who can search the plate data, whether police can access the database, how long records are retained, whether shoppers are meaningfully notified, and whether vendor sharing settings turn private parking lots into law-enforcement search points.


    Phone numbers may become identity checkpoints

    The FCC’s proposed “know your customer” proceeding would push phone providers toward stronger identity collection for subscribers. The stated goals include fraud reduction, robocall enforcement, and accountability. But the design matters.

    A phone number is often the gateway to work, housing, banking, medical care, two-factor authentication, family communication, and public services. If ordinary phone access requires more identity documentation, policymakers should ask who is excluded, what information is stored, how long it is retained, whether it can be shared with law enforcement, and whether anonymous or low-documentation options remain available.


    Age checks are becoming identity infrastructure

    France’s age-check fight shows how online child-safety rules are becoming identity-infrastructure debates. Reuters reported that an EU court said France can enforce age checks against porn sites based in other EU countries. At the same time, the UK is debating under-16 social-media restrictions, U.S. lawmakers are advancing kids’ online-safety proposals, and state age-verification laws continue to spread.

    Child safety is a legitimate policy goal. The safeguard question is whether the law protects children without forcing everyone else to prove identity, weaken anonymity, turn private vendors into access gatekeepers, or create reusable records of lawful online activity.


    Lawful-access bills can become encryption-access bills

    Canada’s Bill C-22 debate is a useful warning signal for other democracies. Reporting from iPhone in Canada and legal commentary around the bill say Apple and Google warned that lawful-access language could pressure companies to break or weaken end-to-end encryption, limit disclosure to users, or create new government-access obligations.

    The details are Canadian, but the pattern is broader. When governments seek faster access to digital evidence, the line between lawful process and infrastructure redesign can become blurry. Encryption policy should be debated directly, not buried inside broad access powers.


    AI chats can become legal records

    A New York judge blocked a subpoena seeking ChatGPT records in a lender lawsuit, according to Reuters. The ruling protected the records in that case, but the subpoena itself is the signal.

    AI prompts, chats, drafts, uploaded files, and account logs may become discoverable records, depending on context. Public agencies, advocacy groups, businesses, and lawyers should treat AI tools as record-creating systems, not just brainstorming spaces. Sensitive legal, personnel, constituent, or strategy work should not be pasted into tools without clear rules for retention, access, privilege, and disclosure.


    AI support bots should not control the keys

    The reported Meta AI / Instagram account-recovery incident shows why AI systems need hard permission boundaries. If an AI support system can grant account access, change recovery information, override verification, or alter enforcement status, then the AI is not just answering questions. It is controlling access.

    The safeguard is simple: AI should not hold the keys by itself. Account recovery, permissions, identity verification, enforcement decisions, and high-impact changes need strong verification, human escalation, audit logs, and rollback plans.


    Security features should not disappear quietly

    Reports that AMD removed or disabled a memory-encryption feature from some consumer Ryzen systems are a useful security-governance warning. The technical details matter less than the policy lesson: security features can be enabled, disabled, tiered, or moved behind enterprise product lines in ways ordinary users may not notice.

    Public agencies and institutions should ask vendors what security features are actually enabled, which features require higher-priced products, whether firmware or licensing changes can disable protections, and how customers will be notified if a security feature is removed or downgraded.


    Axon Watch: police-tech contracts are becoming platform commitments

    Axon’s June Records and Standards release notes are a reminder that public-safety technology keeps expanding after the original purchase. Recent release notes include report redaction with audit-log tracking, search tools tied to people and vehicles, saved searches, Evidence ID search, analytics privilege copying, site-attribute restrictions, and more precise audit-log timestamps.

    That is why Axon should be reviewed as a platform vendor, not only a device vendor. A body-camera, Taser, RMS, ALPR, drone, redaction, or AI feature may be introduced through a contract, amendment, release note, configuration setting, or bundled subscription. Public officials should ask not only what is being bought today, but what future searches, integrations, retention rules, vendor access, and audit logs the platform will make possible tomorrow.


    Surveillance pricing is becoming a consumer-protection issue

    Surveillance pricing is moving from theory to statutes and lawsuits. EPIC reports that Connecticut became the second state to enact a surveillance-pricing ban, while EFF is backing a California bill to restrict personalized pricing based on personal data. Courthouse News also reported on a class-action lawsuit over an alleged surveillance-pricing scheme.

    The policy issue is simple: data collected to identify, predict, or profile people can also become data used to set the price they see. Privacy law and consumer-protection law are starting to converge.


    Direction of travel

    This week’s Signals point toward one pattern: identity and access are becoming control layers. Phone numbers, age gates, encrypted services, AI accounts, retail ALPRs, security features, and police-tech platforms all decide who can enter, who can search, who can verify, and who can be watched. The safeguard challenge is to protect people without making ordinary life depend on persistent identity trails and invisible vendor systems.


    Safeguards

    Safeguards

    A safeguards page works best when it turns broad concerns into practical questions public officials can ask before systems are purchased, connected, searched, expanded, or renewed.

    Require authority before sensitive searches

    Sensitive searches should require clear authority before they happen, not only after-the-fact review. That authority might be a warrant, court order, statute, documented case need, or narrowly defined emergency exception. But the rule should be written before the system becomes routine.

    This applies across systems: communications searches, ALPR searches, biometric searches, law-enforcement databases, immigration-enforcement access, geofence-style searches, public-benefits records, school records, and sensitive civic data. If a search can reveal where someone has been, who they communicate with, what they believe, what services they use, or whether they may be flagged by government, the threshold should be higher than convenience.

    The practical question is simple: before a person searches sensitive data, what must they document, who reviews it, and how can misuse be proven later?

    Treat ALPR audit logs as the oversight system

    ALPR oversight should not depend on trust alone. It should depend on records that can be reviewed.

    A useful ALPR audit log should show who searched, what they searched, when they searched, why they searched, whether the search was tied to a case number or documented purpose, whether a hit was acted on, whether the result was shared, and whether an outside agency or vendor employee accessed the system.

    That does not mean exposing everyone’s raw location history to the public. It means protecting individual plate data while making the governance system visible. Public officials should be able to see scan counts, hit rates, false-hit procedures, retention rules, sharing settings, outside-agency access, vendor-access logs, misuse investigations, and policy exceptions.

    A system that cannot answer who searched, why, and what happened next is not just missing a technical feature. It is missing the oversight system.

    Make vendor access visible before approval

    Vendor access is part of surveillance oversight. Contracts should not leave it vague.

    Before approving or renewing a system, public officials should know whether vendor employees can access live feeds, stored footage, plate data, case files, audit logs, search tools, support dashboards, training environments, or analytics systems. They should also know whether vendor access is logged, whether customers are notified, whether data can be used for product development, sales demonstrations, AI training, quality review, or troubleshooting, and whether access can be disabled by default.

    The safest rule is narrow access by design: no vendor access except for documented support needs, no sales or demo use without written permission, no product-development reuse without explicit approval, and no silent access to public-agency data.

    Patch quickly, then verify what happened

    When a vulnerability is already being exploited, the first question is not whether an agency plans to patch. It is whether the exposed system has already been identified, assigned, fixed, and reviewed.

    Public agencies should ask vendors and internal teams the same basic questions: Are we affected? Which systems are exposed? When was the patch applied? Who verified it? Were logs reviewed? Were accounts created, changed, or abused? Were credentials rotated? Were dependent systems affected? Were backups tested? Were users or partner agencies notified?

    Fast patching matters, but patching alone is not the whole safeguard. A patched system may still have compromised accounts, altered settings, copied data, or persistence mechanisms left behind. The fix should include proof, log review, and a short written record of what changed.

    Delete old sensitive data before it becomes breach fuel

    The best breach response starts before the breach. Collect less data, keep it for less time, separate sensitive records, and delete what no longer serves a clear public purpose.

    Old records become dangerous when they remain searchable after their original purpose has passed. A school platform, police system, vendor database, health app, personnel file, grant system, or public-records archive can become a breach problem years later if sensitive data is kept by default.

    Retention limits should be treated as security controls. If data is no longer needed, no longer legally required, and no longer serving the public purpose for which it was collected, deletion is not a loss. It is a safeguard.

    “The Government’s position fails to contend with the seismic shifts in digital technology that made possible the tracking of not only Carpenter’s location but also everyone else’s, not for a short period but for years and years.”

    — Chief Justice John G. Roberts Jr., majority opinion, Carpenter v. United States (2018)

    Governance Safeguards

    Governance Safeguards

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

    Keep AI away from the keys

    AI systems should not be allowed to control account recovery, permissions, identity verification, enforcement decisions, or high-impact access changes without hard limits.

    A support bot that can grant account access is not just a chatbot. It is an access-control system. An AI tool that can change permissions, summarize evidence, draft reports, flag people, alter workflows, or trigger decisions needs more than a prompt box and a terms-of-service page.

    Useful safeguards include human review for high-impact actions, least-privilege access, separate logs for AI actions, rollback plans, prompt-injection testing, escalation rules, and clear bans on using AI outputs as the sole basis for account recovery, discipline, arrest, eligibility, denial of service, or enforcement action.

    Do not make identity the price of ordinary access

    Age checks, phone-ID rules, Real ID requirements, social-media restrictions, account verification systems, and anti-fraud tools can all serve legitimate goals. But they can also make ordinary life depend on persistent identity trails.

    Policymakers should ask whether a system verifies what it actually needs to know, or whether it collects more identity than necessary. A service may need to know that a person is old enough, eligible, or authorized. It may not need to store a copy of a government ID, keep a reusable identity profile, or link lawful activity across platforms.

    Good identity policy should include privacy-preserving alternatives, data minimization, short retention, vendor limits, appeal rights, and options for people without stable documents, stable addresses, safe disclosure conditions, or conventional ID access.

    Ask what security features are actually enabled

    Security should not depend on assumptions. If a product advertises encryption, isolation, logging, retention controls, access limits, or audit tools, public agencies should ask whether those protections are actually enabled in the version they are buying.

    Officials should also ask whether features depend on a higher-priced tier, firmware setting, license term, subscription level, cloud configuration, or optional module. If a vendor removes, disables, downgrades, or paywalls a security feature, customers should receive clear notice before they rely on a protection that may no longer exist.

    The practical question is not “does this product have security?” It is: which protections are active, who controls them, what changes can disable them, and how will we know?

    Make public reporting routine, not exceptional

    Oversight works better when public reporting is scheduled before controversy begins. The La Pine data-center transparency petition is a local example: large data infrastructure raises questions about power, water, generators, noise, and public accountability even when it is not a surveillance system by itself.

    The same reporting habit should apply to sensitive technology systems: publish enough information to evaluate system purpose, data collected, vendor access, retention period, outside-agency access, number of searches, number of hits, false matches, corrective actions, policy violations, and renewal dates.

    Use a pre-approval checklist before systems go live

    Before launch, renewal, expansion, or feature activation, officials should be able to answer basic questions: 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?

    A checklist is not bureaucracy for its own sake. It is a way to keep small procurement decisions from quietly becoming large public-governance decisions after data is already flowing.

    Bottom line

    The strongest safeguard this week is visible control over search power.

    Whether the system is Section 702, ALPR, cyber incident response, identity verification, AI account recovery, surveillance pricing, or a police-tech platform, the public needs the same basic answers: who can search, why they can search, what authority applies, how long data is kept, whether vendors can access it, whether identity checks are truly necessary, and whether misuse can be proven after the fact.

    Collect less. Connect less. Search less. Retain less. Log every exception. Make vendor access visible. Require authority before sensitive searches. Build privacy into the system before the data becomes too useful to give up.

  • Bend Verkada Explainer

    Bend’s Verkada Security-Camera System

    What the public record shows — and what it doesn’t

    City of Bend, Oregon · Public-Records Review · Updated 2026

    Where things standThe City of Bend has standardized on Verkada’s cloud-based security-camera platform since 2020 and continued purchasing Verkada-related installation services and hardware in 2023 and 2024. The documents reviewed so far do not prove that Bend PD has direct access to the system. They do show that key governance details — camera locations, retention settings, analytics settings, police-access rules, public-sharing rules, vendor-access limits, signage practices, and post-breach risk review — are not in the public record.

    This explainer is for Bend residents who want to understand what the City has built, what’s confirmed in writing, and what questions remain unanswered. It draws from the City’s own Council issue summaries, contracts, meeting minutes, and Verkada’s own incident report. Sources are linked at the end. Use this to inform yourself, ask better questions, or write to Council.

    01What the City Has Built

    The Bend system is not a single project but a layered platform that has been expanded through several contracts. Here’s what the public record confirms.

    A cloud-based “video-surveillance-as-a-service” platform.

    In 2020, the City adopted Verkada’s platform through a competitive bid. Unlike traditional on-site security cameras, Verkada’s system streams and stores footage in the cloud (Amazon Web Services), managed through Verkada’s “Command” platform.

    Two more authorizations in 2023 and 2024.

    In June 2023, Council authorized up to $165,000 for installation services with LTT Partners LLC, a licensed Verkada reseller and installer. In June 2024, Council authorized up to $150,000 to purchase additional Verkada-compatible cameras and hardware. Both were approved on the consent agenda.

    Integration into new City buildings.

    Verkada cameras and integrated access control are being designed into the new Public Works Campus, including the headquarters, fleet, and warm-vehicle-storage buildings.

    Cameras around the Lighthouse Navigation Center.

    The City’s January 2026 Council Goals Status Report notes that security cameras are being installed around the Lighthouse Navigation Center as part of a public-safety effort. The report does not specify whether those cameras are part of the Verkada system.

    Employee privacy protections (only).

    The City’s collective bargaining agreement with COBEA (the employees’ union) includes rules: cameras may not be placed where employees have a reasonable expectation of personal privacy, the City may not randomly review footage for discipline, and no employee can be disciplined solely on video evidence absent misconduct. These protections cover employees — not the general public.

    Worth stating plainly Security cameras at City facilities — loading docks, cash-handling areas, building entries — are a normal and reasonable thing for a city to operate. The question this explainer raises is not whether cameras should exist, but whether a cloud-based, expandable, analytics-capable surveillance platform should be operated without published rules governing how it’s used.

    02What the Public Record Doesn’t Show

    These are the governance questions the documents don’t answer. Each is something a resident might reasonably expect to be on file for a system of this kind.

    Gap 01

    Where the cameras are, and how many there are.

    The installation contract says cameras are installed “at multiple City of Bend sites on an on-call basis,” with each installation initiated by a purchase order. There is no public inventory of camera locations, counts, types, or fields of view. Because each installation is administrative — not a Council vote — individual deployments don’t return for public review.

    What this meansThe public cannot know whether a given sidewalk, alley, park, or street near a City facility is under camera coverage.

    Gap 02

    A public-facing surveillance use policy.

    Employee privacy is partially protected by union contract. There is no parallel public policy governing who within the City may view live footage, whether viewer access is audit-logged, standards for reviewing footage of community members, prohibited uses (e.g., monitoring of First Amendment activity), discipline for misuse, or annual reporting to Council.

    What this meansThe rules that govern how this system is used in practice are not visible to the public it surveils.

    Gap 03

    How long footage is kept.

    The contracts and issue summaries do not specify a retention period. Verkada cameras can be configured to retain footage anywhere from roughly 30 days up to a year, depending on model and settings. The retention setting is the single biggest factor determining how much historical movement data the system holds.

    What this meansA 30-day setting limits exposure. A 365-day setting creates a year-long behavioral record of everyone who walks past a camera.

    Gap 04

    Whether and how police access the system.

    The installation contract requires LTT Partners’ installers to be CJIS-certified (Criminal Justice Information Services) within six weeks of award. CJIS certification of installers is a meaningful clue that some work touches public-safety-sensitive environments, but it does not by itself prove Bend PD has direct, standing access to the Verkada platform, or that Verkada footage is treated as CJIS data. None of this is spelled out publicly.

    What this means“Security cameras to protect public property” and “a feed integrated into police operations” are very different programs. The record doesn’t say which one Bend has.

    Gap 05

    Which Verkada features are enabled.

    Verkada’s documentation confirms its platform supports — when enabled by a customer — People Analytics, face search across cameras, license plate recognition and plate-of-interest alerts, vehicle search by attribute, audio recording and audio analytics, and integration with access control to correlate badge swipes with video. Which of these features the City of Bend has turned on or off is not documented in the public record.

    What this meansA camera that records video is one thing. A camera plus a searchable face database across City facilities is a substantially different capability.

    Gap 06

    Community engagement before approval.

    Both the 2023 and 2024 issue summaries list “Community Outreach Process and Potential Impacts: N/A.” Both authorizations went through the consent agenda — the 2024 purchase appears grouped with routine items like fuel purchases and meter-box upgrades. No public hearing, impact analysis, or community engagement process appears in the record.

    What this meansThe expansion of a surveillance-capable platform was treated as routine procurement, not as a matter the public might want to weigh in on.

    Gap 07

    Whether the vendor was re-evaluated after a major 2021 breach.

    In March 2021, attackers compromised Verkada’s platform by exploiting a misconfigured customer-support server. They accessed live and archived video for 97 customer organizations, across approximately 4,500 cameras. Eight customers also had access-control product data accessed, including badge credentials. The breach was vendor-side, meaning customer security depended heavily on Verkada’s internal controls. The City standardized on Verkada in 2020 — before the breach — and re-authorized two more Verkada-tied contracts in 2023 and 2024, after the breach. No document in the public record shows the City re-evaluated Verkada’s security posture before those re-authorizations. In August 2024, the FTC announced a settlement requiring Verkada to implement a comprehensive information-security program with biennial third-party assessments; a separate $2.95 million civil penalty was imposed for CAN-SPAM email-marketing violations (FTC Matter 2123068; stipulated order entered Sept. 4, 2024, N.D. Cal.).

    What this meansVendor risk doesn’t disappear after a breach. A buyer that doesn’t document re-evaluation is making an implicit bet that isn’t in the record.

    Gap 08

    Public notice and signage.

    Oregon does not have a general statute requiring video-surveillance signage in public areas, though federal law restricts audio recording without notice in most contexts. Whether camera locations carry visible signage — and what those signs say about the purpose, retention period, records-request process, and complaint process — is not addressed in the project record.

    What this meansNotice is the floor of meaningful consent. It deters the conduct the City says it’s trying to deter, and it signals accountability to the people walking past.

    03Questions Worth Asking

    Whether you’re writing to Council, filing a public-records request, or just trying to understand your city better, these are reasonable, specific questions that the existing public record does not answer:

    • Where are City surveillance cameras located, and how many are there?
    • How long is footage retained on each camera?
    • Which Verkada features are enabled — face search, license plate recognition, audio, People Analytics?
    • Who can view live and recorded footage, and is that access audit-logged?
    • What policy governs sharing footage with law enforcement, outside agencies, or the public?
    • What review did the City conduct of Verkada’s security posture after the 2021 breach and 2024 FTC action?
    • What signage notifies the public that an area is under City surveillance?
    • What process exists for residents to file complaints or request specific footage?

    04Context: How Other Cities Handle This

    Several cities — including Seattle, San Francisco, Oakland, Cambridge MA, Berkeley, and the Bay Area Rapid Transit (BART) system — have adopted surveillance-technology review processes that require public documentation, hearings, or annual reporting before a surveillance technology is acquired or expanded. These ordinances typically require a written impact report covering the technology’s capabilities, retention rules, access policies, and civil-liberties risks; a public hearing before procurement; and annual use audits.

    Bend’s 2023 and 2024 Verkada-related authorizations went through the consent agenda with no documented community outreach.

    05Sources

    City of Bend documents

    · Council Issue Summary, 2023 installation contract authorization (5G): 5G_LTT_Partners_IS.pdf
    · Installation contract with LTT Partners LLC: 5G_LTT_Installation_Contract.pdf
    · Council Issue Summary, 2024 hardware purchase (5D): 5D_Issue_Summary.pdf · 5D_Issue_Summary-1.pdf
    · Hardware purchase contract: 5D_Contract.pdf
    · Council meeting minutes: Minutes-2-4.pdf
    · Public Works Campus GMP-3 amendment (Verkada integration): 8_Public_Works_Campus_KNCC_Proposed_Amendment_No._6_GMP_3.pdf
    · Council Goals Status Report, January 2026: Council_Goals_Status_Report.pdf
    · COBEA Collective Bargaining Agreement 2022–2025: 9_COBEA_2022-2025_Collective_Bargaining_Agreement.pdf
    · Update on Downtown Safety Projects: Update_on_Downtown_Safety_Projects.pdf

    Verkada and federal sources

    · Verkada Security Incident Report (March 2021 breach): Security_Incident_Report_Version1.2.pdf
    · FTC press release: “FTC Takes Action Against Security Camera Firm Verkada” (Aug. 30, 2024): ftc.gov
    · FTC case file: United States v. Verkada Inc., FTC Matter 2123068, Civil Action 3:24-cv-06153 (N.D. Cal., stipulated order entered Sept. 4, 2024): ftc.gov/legal-library

    Bend Privacy Alliance

    Protecting privacy, transparency, and civil rights in Bend.

    Share freely · No copyright claimed · Verify before you act