When “Protecting Kids” Goes Wrong

Oregon lawmakers are considering legislation that would require apps, websites, and devices to verify users’ ages — with the goal of protecting children online. The goal is legitimate. But how that verification gets built matters enormously.

Oregon is a sanctuary state. We have chosen, as a matter of law and values, to limit how state and local resources are used in federal immigration enforcement. Age-verification legislation — if built carelessly — can create new data pipelines that undercut those protections without anyone in the Legislature intending it. The first two scenarios on this page start there.

Every scenario is fictional. The names and families are invented. But every technical mechanism — how apps share data, how devices track age, how companies store information — is drawn from real platform documentation and enacted laws. Citations at the end of each scenario point to the underlying sources.

These aren’t predictions. They’re illustrations of what becomes possible when an age-verification system is built without the right guardrails. Read them, share them, bring them to your legislators.

How to read the scenarios Each scenario ends with a WHAT WOULD PREVENT THIS section listing the specific law or rule that would have stopped the harm. Those are the asks you can bring to your legislator.
Track 1 of 3

Your Phone Knows Your Age

Several states are considering laws that would require your phone’s operating system — Apple iOS or Android — to collect your age at setup and broadcast it to apps on demand. Here is what that system can do that lawmakers may not have considered.

Scenario 1

The Immigration Enforcement Use No One Planned For

Mateo is 17 and lives with his grandmother in Salem. Both are undocumented. Under Oregon’s new OS age-signal law, Mateo’s phone account has declared his minor status, and his grandmother is listed as his supervising adult — a parent-child link created automatically by the child-safety feature. Following a federal enforcement action, a request goes to a major phone platform for account records tied to certain phone numbers. The platform produces the records. Included is the family-account link connecting Mateo to his grandmother. Neither was the original target. The relationship that exposed them was created by a child-safety law.

Both Apple Family Sharing and Google Family Link create a documented relationship between a minor’s account and their supervising adult. That relationship is a data record — and data records are subject to legal requests. Oregon has no law limiting what federal agencies can do with age-signal data, and no warrant requirement applies to civil immigration process. A feature designed to protect children became the record that identified a family.

  • A purpose-limitation clause: age data may only be used to determine whether someone is a minor under this specific Oregon law — and for nothing else, ever.
  • An explicit ban on immigration-enforcement use of any data generated by the age-verification process.
  • A warrant or court order requirement for all government access to age-signal data — including civil process, not just criminal investigations.
  • The parent-child relationship field must never leave the platform that holds it.
Source: Apple Family Sharing documentation; Google Family Link documentation; Technical analysis, Parts 3 and 8.
Scenario 2

The Breach That Exposed 80,000 Oregon Minors

A compliance vendor sells Oregon app developers a convenient service: instead of separately integrating with Apple’s and Google’s age systems, developers pay this vendor to aggregate both signals into one unified check — covering phones, tablets, and browsers. The vendor is certified under Oregon’s compliance framework. In 2028, the vendor’s database is breached. Exposed records include age brackets, account identifiers, and parental-consent timestamps for 340,000 Oregon residents, including 80,000 minors. For each minor, the breach reveals their minor status, their age bracket, and a cross-platform ID linking their activity across every app and website they used.

This kind of aggregation service — a vendor that combines age signals from multiple platforms into one check — is already a real market. It solves a genuine headache for developers, but it creates a new concentration of sensitive data that no single platform’s privacy promises cover. Oregon’s law imposed protections on Apple, Google, and app developers. The vendor sitting between them fell through a gap.

  • The Oregon law must explicitly cover age-signal aggregators and compliance vendors — not just the platforms and app developers.
  • No vendor may build a centralized database of age data across platforms without meeting the same security and minimization requirements as the platforms themselves.
  • A breach involving minor-status data must trigger notification to the Oregon Attorney General and affected individuals within 72 hours — far faster than Oregon’s standard 45-day window.
Source: Technical analysis, Part 5 (cross-platform aggregation middleware); Oregon data breach notification law (ORS 646A.604).
Scenario 3

The Parent’s Phone, the Child’s Risk

David is 11 years old. His family shares one smartphone — it belongs to his mother, Elena, whose account is registered as an adult. When David uses his mom’s phone to open a social app, the app asks the phone: “How old is this user?” The phone answers based on Elena’s account: adult, 18 or older. Under a new Oregon law, the app is legally treated as having confirmed the user is an adult. It applies adult settings. David’s actual age never enters the picture.

The age-signal system Apple and Google are building reads the account signed into the phone — not the person holding it. In a household where a child uses a parent’s device, the system reads the parent’s age and transmits that. The law would treat this as the app having “actual knowledge” that the user is an adult. This is the most common real-world sharing scenario — and it produces the opposite of the intended result.

  • Before passing any OS age-signal law, the Legislature should require a study: what share of Oregon minors regularly use a parent’s or guardian’s device or account?
  • A law should not allow “actual knowledge” of adult status to be established from a shared account alone. Where the account holder and the current user could be different people, the signal is unreliable as a legal trigger.
Source: Google Play Age Signals API documentation (accessed June 2026); California AB 1043, Civil Code §§ 1798.500 et seq.; Technical analysis, Part 6.
Scenario 4

The Age Signal Becomes an Ad-Targeting Signal

Nadia is 15 with an Android phone. Under a new Oregon law, her Google account includes her age bracket — “ages 13 to 15” — which apps can request. She downloads a lifestyle app that contains three invisible software tools embedded by the developer: one for crash reports, one for analytics, and one that serves ads. The developer stores Nadia’s age bracket in the app’s local data alongside a permanent ID tied to her specific install. The advertising tool, running silently inside the same app, can read what the developer stored. Soon Nadia is seeing ads targeted at teenagers across every app that uses the same ad network.

When Google delivers an age bracket to an app, it also delivers a permanent “install ID” that developers are instructed to save. Google’s rules say the age data cannot be used for advertising — but those are contract rules, not technical locks. An advertising tool embedded inside an app runs in the same environment as the app itself and can read anything the developer stored locally. A child-safety feature becomes, in practice, a tool for targeting teenagers.

  • A state law — not just platform terms of service — must ban using age data for advertising, analytics, or user profiling. Platform rules are enforced by audits; laws are enforced by courts.
  • Age brackets must not be stored anywhere a third-party advertising or analytics tool can read them.
  • Any app subject to the law must disclose every embedded third-party software tool and disable any tool that could process age or minor-status data.
Source: Google Play Age Signals API documentation (accessed June 2026); Technical analysis, Parts 4 and 5.
Scenario 5

The Data Ends Up in a Custody Hearing

Priya is 16 and uses an iPhone. Under a new Oregon law, her Apple account holds her age bracket and timestamps of when her parents approved or changed her account settings. Her parents are in a contentious custody dispute. Her father’s attorney subpoenas three apps — a messaging app, a journaling app, and a social platform — for any records related to Priya’s account. Two of the three kept the age bracket and parental-approval timestamps on their servers, following Apple’s guidance to save consent records. Those logs now show exactly when each parent last changed Priya’s account permissions — a timeline that becomes evidence in the custody case.

Apple advises developers to save parental consent records to their own servers so they can enforce parental decisions consistently. That’s reasonable for child safety — but it means the data lives on a third-party server, subject to ordinary legal subpoenas. Oregon has no law requiring a court order before age or parental-consent data is handed over in civil proceedings.

  • A check-and-delete rule: when an app checks a user’s age to make an access decision, it should check, decide, and delete the age data — not retain it.
  • A court order requirement for any access to age or parental-consent data — including civil cases like custody disputes, not just criminal investigations.
  • If retention is necessary for a specific operational reason, it must be time-limited and narrowed to the minimum data required.
Source: Apple Declared Age Range API documentation (accessed June 2026); Technical analysis, Parts 5 and 7.
Scenario 6

The “Narrow” Law That Grew

Oregon passes an OS age-signal law in 2027 covering apps on Apple and Android phones. Supporters call it narrow: apps only, not the whole internet. In 2029, a follow-on bill extends the same system to web browsers and websites. Sponsors note the infrastructure already exists — the phone already knows the user’s age — so extending it is a small step. It passes with limited debate. Oregonians now have their age transmitted not just when they open an app, but every time they visit a website.

This is not hypothetical — it is already happening in California. California passed AB 1043 in 2025, applying OS age signals to apps. A follow-on bill, AB 1856, would extend the same system to browsers and websites. The Electronic Frontier Foundation called it “one step forward, two steps back.” Once the age-signal infrastructure exists and is normalized, each expansion becomes the path of least resistance.

  • A scope-lock clause in the original Oregon bill: the age-signal system applies to apps only and cannot be extended to browsers or websites without a new bill, a public hearing, and a recorded legislative vote.
  • A three-year sunset: the Legislature must affirmatively vote to continue the law — building in a public review moment before passive expansion occurs.
Source: California AB 1043 (effective Jan. 1, 2027); California AB 1856 (in progress, June 2026); EFF, “One Step Forward, Two Steps Back” (May 2026).
Track 2 of 3

App Stores

Some proposals would require Apple and Google to verify users’ ages before allowing them to download apps — with parental approval required for minors. Here are two ways that can backfire.

Scenario 7

The Crisis App a Teen Couldn’t Download

Tyler is 16 and lives in Eugene. Under a new Oregon law, his parents must approve each app he downloads. Tyler wants to install a crisis text-line app and a mental health journaling app. He is not ready to tell his parents why. When he makes the request, his parents’ phones receive a notification naming the specific apps. His parents — not out of malice, but because the notification offers no context — decline. Tyler doesn’t get the apps.

Parental-consent flows in Apple and Google’s family-account systems notify parents of exactly which app their child is requesting. There is no mechanism for a teen to make a confidential request for a health or safety app. A law modeled on Texas’s SB 2420 requires parental consent before a minor downloads any app — with no exception for crisis intervention, mental health, or harm-reduction tools.

  • A health and safety carve-out: apps classified as mental health, crisis intervention, reproductive health, or harm-reduction must be exempt from parental-consent requirements.
  • A confidential minor access pathway — modeled on Oregon’s existing minor-consent health care laws — allowing teens above a certain age to access health-relevant apps without parental notification.
Source: Texas SB 2420 (89th Leg.); Oregon minor consent statutes (ORS 109.640 et seq.).
Scenario 8

The Law That Never Took Effect

Oregon passes an app-store accountability law in the 2027 session. Within 60 days, a coalition of developers files suit in federal court, arguing the law violates the First Amendment by restricting minors’ access to protected speech. The district court issues a preliminary injunction, citing a nearly identical ruling against Texas. The law never takes effect. Three years later, the constitutional question is still unresolved. The children the law was meant to protect are three years older.

App-store age-verification laws face a genuine constitutional challenge. Texas’s SB 2420 was blocked by a federal court in December 2025. The Fifth Circuit issued a stay that allowed it to take effect on June 4, 2026 — but the underlying First Amendment question remains unresolved. Oregon would be legislating into that uncertainty.

  • A pre-passage constitutional review — not a post-passage legal defense budget. Legislators should see a realistic litigation-risk assessment before the vote.
  • Legislative findings that directly address whether the law is the least restrictive means of achieving its goal — the question courts will require an answer to.
  • A sunset clause so a permanently enjoined law doesn’t remain on the books indefinitely.
Source: Texas SB 2420 (enjoined Dec. 2025; Fifth Circuit stay; effective June 4, 2026); Brown v. Entertainment Merchants Ass’n, 564 U.S. 786 (2011); Reno v. ACLU, 521 U.S. 844 (1997).
Track 3 of 3

Proving Your Age to a Third Party

Some proposals let websites satisfy age-verification requirements through a certified third-party service — you show your ID to the vendor, the vendor tells the website you’re old enough. This is the most privacy-protective model when built correctly. Here is what happens when it isn’t.

Scenario 9

The Vendor That Kept Your ID

A certified Oregon age-assurance vendor offers a clean service: upload your driver’s license, they confirm you’re 18 or older, and they tell the website — without passing along your name or ID number. The website gets only a yes or no. But the vendor’s terms say they retain the ID image and your birth date “for audit purposes and to prevent re-enrollment fraud.” In 2029, the vendor is acquired. The acquiring company’s terms include data-sharing with affiliated identity-services partners. Oregonians who used the service in 2027 now have their government IDs and birth dates in the hands of a commercial identity broker they’ve never heard of.

A proof-of-age system is only as protective as its deletion policy. The right model — used in some European approaches — is simple: verify, generate a yes/no answer, delete the underlying document immediately. But many vendors retain the ID for reasons that seem operationally legitimate, and retention creates a data asset that travels with the company when it is sold.

  • A prompt deletion mandate: the ID image and birth date must be deleted immediately after the yes/no answer is generated. No retention for any purpose.
  • Certified vendors may not share, sell, or use any data collected during verification for any purpose other than generating the credential.
  • Any acquisition or merger of a certified vendor triggers re-certification, and users must be notified and given a deletion right.
Source: FTC COPPA Age Verification Enforcement Policy Statement, Feb. 25, 2026; Levy memo, §7 (minimum safeguards).

10 Guardrails Every Oregon Age-Verification Bill Needs

Every scenario above points to the same recurring gaps. Here are the specific protections to ask your legislator about — by name.

1
No birth dates or government IDs traveling downstream

Only an age bracket (“under 18” or “18 or older”) should leave the verification step. The underlying proof must never reach any app or platform.

2
No centralized age database — by any entity

Neither the state nor a private vendor may build a master list of Oregonians’ age-verification records. Data minimization must be in the statute, not left to platform policies.

3
Prompt deletion after verification

Once the age check is complete and the decision is made, the underlying data must be deleted — not retained for audits, not kept to prevent re-enrollment, not transferred.

4
No advertising or profiling use — by statute

Platform terms of service are not enough. A state law must explicitly ban using age data for advertising, analytics, or profiling — including by third-party tools embedded inside apps.

5
No permanent tracking IDs linked to age data

An age bracket may not be stored alongside any stable device, account, or install identifier that can follow a person across sessions, apps, or years.

6
Warrant or court order for all government access

Any government agency — including civil immigration enforcement — must obtain a warrant or court order before accessing age-verification data. A routine legal request is not enough.

7
A scope-lock clause

A law covering apps cannot be extended to browsers or websites without a new bill, a public hearing, and a recorded vote. Expansion must require active permission — not passive drift.

8
Edge-case protections built in

The law must explicitly address: shared devices, foster youth, emancipated minors, students on school-managed devices, public library computers, and users without a qualifying account.

9
Third-party software tool disclosure and segregation

Any app subject to the law must disclose every embedded third-party tool and disable any tool that could process age or minor-status data — unless separately certified for child-safety purposes.

10
Independent technical review before rulemaking

Before regulations are finalized, an independent technical panel must review the architecture for the failure modes described in this document and confirm the guardrails actually work.

A note on sources All scenarios are fictional composites — no real person is described. All technical mechanisms are drawn from real platform documentation, enacted legislation, and documented research. The litigation status of Texas SB 2420 is moving quickly; confirm current docket status before formal use. Full primary-source citations are available in the companion research document. Prepared by Jonathan Westmoreland, Bend Privacy Alliance, June 2026.

Bend Privacy Alliance · Bend, Oregon

All scenarios are fictional. All technical mechanisms are documented in primary sources.