OS Age Verification, Explained: What Oregonians Should Know

A plain-language guide to operating-system age verification — how it works, why the “device layer” matters, and the questions Oregon should ask before adopting it. Part of the Bend Privacy Alliance public education series.

Protecting minors online is a serious and legitimate goal, and Oregon already pursues it through several laws. The question on the horizon for the 2027 legislative session is how the state should go further — and one approach now circulating, often called “operating-system age verification,” deserves a close look before it is adopted.

This page explains what that means in plain language. The goal is not to oppose child safety. The goal is to make sure that if Oregon builds an age-checking system, it is narrow, privacy-preserving, and answerable to public rules — not a reusable “age layer” that quietly expands over time.

---

The simple version

An operating-system age-signal law would not necessarily require anyone to upload an ID or scan their face. Instead, the device or account system would ask for an age or birth date, turn that into a general age group, and let apps request that age group when the law says they need it.

That sounds simple, but it changes where age information lives. Instead of one website asking your age, the age layer moves closer to the root of your digital life: the phone, tablet, computer, or account you use to reach many different services.

One way to picture it: an OS age signal is like putting an age label at the entrance to the device, and then letting apps ask to see the label. That may sound harmless — but the real privacy question is who gets to ask, what they keep, and whether the label later follows you into more places than lawmakers intended.

---

How it works, step by step

Person enters age or birth date → the phone or account turns it into a general age group (like “13–15” or “18+”) → an app asks for that age group → the app receives the signal → under an AB 1043-style law, the app may be treated as knowing the user’s age group → the app changes what protections, limits, or features apply.

The important part is what happens after the first step: once the device or account can produce an age group, it can be asked for again and again — by more apps, and potentially, in a later law, by browsers and websites too.

---

Why this matters

The question is not only whether children are protected. They should be — and Oregon already has several laws aimed at student data, minors’ commercial data, AI chatbots, and school-device use. The bigger question is whether Oregon would create a reusable age layer that can later expand from apps to browsers, websites, schools, and other services. A system built to send age signals to apps can quietly become general-purpose infrastructure for knowing — and acting on — everyone’s age.

California is the live example. It enacted age signals for apps (AB 1043), and it is now considering a follow-on bill (AB 1856) that would extend the same signal to browsers and websites. An Oregon law should be read as a first step in that direction unless it includes clear limits that prevent expansion.

---

What could go wrong

An age signal assumes that one account belongs to one known-age person on one device. Real life is messier:

• A child uses a parent’s phone — and the device may tell apps the user is an adult.
• A parent uses a child’s tablet — and apps may wrongly restrict a legitimate adult.
• A student uses a school-managed device — and the school district can become the age authority, creating new exposure of student data.
• A foster youth or emancipated minor does not fit a normal parent-consent model.
• A public-library computer has no stable personal account, so the signal is meaningless or simply wrong.
• An app contains advertising or analytics code that sits right next to the age signal — which can turn a child-safety feature into a tracking tool.

These are not rare corner cases. They are exactly the situations where the system either blocks a legitimate adult or mislabels a child — and where a “safety” signal can leak into uses no one intended.

---

What safeguards Oregon should require

If Oregon adopts any age-signal system, these should be the floor:

• No sharing of exact birth dates — a general age group, at most.
• No mandate for government ID or face scans.
• No central state age database.
• No use of age signals for advertising, profiling, school discipline, or immigration enforcement.
• Law-enforcement access only by warrant or court order.
• No expansion from apps to browsers or websites without separate legislation, public hearings, and a recorded legislative vote.
• Real protections for school-managed devices, open-source systems, and accessibility tools — and prompt deletion of any underlying age proof.

---

Questions to ask your legislator

1. Which model is this — school technology, app-store accountability, an operating-system age signal, or privacy-preserving proof-of-age? (They are very different.)
2. What specific harm does it address that Oregon’s existing privacy laws don’t already reach?
3. Must the operating system collect age, or only relay a signal if age is already known?
4. Who may request the signal — only covered services, or also browsers, websites, and in-app advertising or analytics code?
5. Does the bill prevent expansion to browsers and websites without new legislation?
6. Are advertising, profiling, discipline, and immigration uses prohibited, and is law-enforcement access gated behind a warrant?
7. How does it interact with school-managed devices and existing student-privacy law?
8. Will there be a privacy impact assessment and an independent technical review before drafting?

---

A short glossary

• Operating-system age signal — an age label created by the device or account.
• Age bracket — a general age group, like 13–15 or 18+.
• API — a software doorway that lets an app ask for information.
• SDK — outside code placed inside an app, often used for ads, analytics, or tracking.
• Persistent identifier — a recurring tag that can help recognize the same user or app install over time.
• Actual knowledge — the law treating an app as if it knows the user’s age.
• Scope creep — a system built for one purpose expanding into more uses later.

---

Where this fits

This is the lead explainer in a Bend Privacy Alliance series on age verification and youth online safety. The companion pieces are now available: Four Bills, One Label (the four different bills often lumped together as “age verification”), Already on the Books (Oregon’s existing youth-privacy laws), Under the Hood (the technical details of how these systems actually work), and When “Protecting Kids” Goes Wrong (nine scenarios showing what poorly built age-verification legislation could do to real Oregonians — and the guardrails that would prevent it).

A fuller research archive and a technical analysis — with primary-source citations for every claim on this page — are available to download just below. To follow the work, read the Signals & Safeguards newsletter — you can subscribe through the contact form — or see how to get involved.

---

Supporting documents

Every claim on this page is backed by source-checked documents. Download whichever is useful — a plain-language handout, the briefing slide deck, or the full technical and research archive.

Prefer Word format? Download the full set of documents (PDF and Word) as a single ZIP archive.

---

The basic principle

Oregon can protect minors online without building a reusable age-surveillance layer. Those goals are not opposites. They belong together.

If a system can collect, store, request, or act on a person’s age across their digital life, it is powerful enough to deserve clear public rules.

Prepared by the Bend Privacy Alliance. The platform tools and laws described here are new and changing; this page reflects the picture as of June 2026, and current status should be checked before relying on any specific detail.