One of a Bend Privacy Alliance series on age verification and youth online safety. The policy debate over operating-system age signals turns on technical details most summaries skip. This page explains how the machinery actually works — using the real platform tools shipping now.
An operating-system age signal sounds abstract until you look at what the device actually does. Apple and Google have both shipped the plumbing, and the way it works shapes every privacy question a law would need to answer. Here is the mechanism, step by step, and where the risks live.
The signal, step by step
At a high level, every OS age-signal system follows the same five steps:
- Collection — at device or account setup, the user (or a parent) enters an age or birth date.
- Derivation — the operating system or app store turns that into a coarse age bracket, not an exact birthday.
- Request — when an app wants to know, it calls a platform API at runtime and asks for the signal.
- Delivery — the platform returns an age range, and sometimes a status such as “verified” or “supervised.”
- Response — the app adapts: it gates content, applies protections, or unlocks features.
Under an AB 1043-style law, an app that receives the signal is treated as having “actual knowledge” of the user’s age range — which is what turns a technical signal into a legal duty.
An API, not a database
A key point is what the app does and does not get. It does not receive a birth date, and it does not query a central government database. It calls a function on the device and receives a narrow answer — an age band such as 13–15 or 18+. That narrowness is the design’s privacy strength. The privacy questions come from everything around it: who may call the API, what else travels with the answer, and what the platform keeps behind the scenes.
On Apple devices (iOS)
Apple’s tool is the Declared Age Range API (the DeclaredAgeRange framework), introduced in 2025 and available starting in iOS 26, with the age-eligibility flag requiring iOS 26.2. An app requests an age range — for example, 13+, 16+, or 18+ — without ever asking for a birth date. Sharing requires the user’s agreement, or a parent or guardian’s for a child account. The app must hold a special entitlement to call the API, and the response also includes a signal about how the age was established. On devices older than iOS 26.2, the signal simply is not available, and the app gets nothing.
On Android and Google Play
Google’s tool is the Play Age Signals API, currently in beta. An Android app calls it at runtime and receives a user status — verified, supervised (a Family Link child), or declared (self-stated) — along with an age range across default bands of 0–12, 13–15, 16–17, and 18+, which developers can customize. A “verified” status can come from a government ID, a credit card, or facial age estimation. Two details matter for privacy. First, the response includes an installID — a Play-generated identifier tied to the app install. Second, Google’s policy, effective January 1, 2026, prohibits using the age data for advertising, profiling, or analytics. The API only returns data where Play is legally required to provide it.
Where SDKs come in
Most apps are not built only from the developer’s own code. They embed third-party SDKs — outside code for advertising, analytics, crash reporting, and more — that run inside the same app. That is the adjacency risk: the age signal arrives in an app that may also contain ad or analytics code, and once age is known inside the app, nothing technical stops it from being combined with other data unless a rule forbids it. Google’s explicit ban on using the signal for advertising, profiling, or analytics is a direct response to exactly this risk — but it is a policy rule, and the open question is always enforcement, not whether the data flow is possible.
Persistent identifiers: what travels with the signal
Age by itself is not very identifying. Age attached to a stable identifier is a different matter. The Android signal ships with an installID; on any platform, the age band is requested by an app that already sees device and account identifiers. If an age band becomes one more attribute attached to a durable identifier, it can feed a longer-lived profile. The privacy of an age-signal system depends heavily on whether the bracket is kept unlinkable — or quietly becomes another field in a record that already knows who you are.
Where the signal breaks down
- Old devices: the signal only exists on supported OS versions; older phones return nothing.
- Shared devices: the signal reflects the account holder’s declared age, not whoever is actually holding the phone — so a child on a parent’s device can read as an adult, and an adult on a child’s device can be wrongly restricted.
- Self-declared vs. verified: a “declared” age is just what someone typed; accuracy varies, and stronger verification (ID, credit card, facial age estimation) trades privacy for confidence.
- Jurisdiction-gated: the platforms return signals only where a law requires it, so coverage is uneven by design.
What this means for an Oregon law
The mechanics make the safeguards concrete. If Oregon ever adopts an age-signal law, the technical details above are exactly what the text should pin down: which callers may request the signal, whether any identifier may travel with it, an explicit ban on advertising, profiling, and analytics uses (as Google has already built into policy), prompt deletion of any underlying age proof and verification method, and real handling for the older, shared, and school-managed devices the signal serves poorly. Our hub explainer lists the full set of safeguards; this page is why each one is needed.
Further reading
- OS Age Verification, Explained: What Oregonians Should Know — the plain-language hub, with the full list of safeguards.
- Four Bills, One Label — the four very different policies people call “age verification.”
- Already on the Books — what Oregon already does to protect kids online.
- Technical analysis (PDF) — the longer source-checked version of this material. The primary sources are also gathered in section 15 of the source library.
The basic principle
An OS age signal is, at heart, a small piece of data with a large reach: a coarse age band, produced on request, that can touch many services. Its privacy depends entirely on the rules around it — who can ask, what rides along with the answer, and what the platform keeps.
The narrowness of the signal is a feature; keeping it narrow — unlinked, single-purpose, and short-lived — is the whole job.
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.