State Push: OS Level Age Signals for App Age Checks (CA CO NY)

California, Colorado and New York have pushed a radical idea into lawmaking: move age checks out of websites and apps and into the operating system itself, forcing device vendors and OS maintainers to collect users’ ages at setup and broadcast a persistent “age signal” to apps and stores — a change that is already prompting patchwork responses from commercial vendors and existential decisions from open‑source projects.

Background​

The logic driving these bills is straightforward on the surface: online services already perform age gating to shield minors from adult content and to comply with a maze of state and national rules. Legislators in several U.S. states concluded that pushing the verification responsibility down to the device would standardize signals, reduce repeated identity prompts across services, and make compliance easier to audit. The problem is practical, technical and constitutional: mandating that an operating system collect, store and expose age data changes the architecture of platforms — and collides with the distribution, licensing and privacy models of the open‑source ecosystem.
The bills to watch right now are:

• California Assembly Bill AB 1043 — often called the Digital Age Assurance Act — which was enacted during the 2025‑26 session and sets up device‑level age signaling with specific age brackets and obligations for "covered manufacturers" and app stores. It takes effect January 1, 2027.
• Colorado Senate Bill SB26‑051, "Age Attestation on Computing Devices," which would require operating systems to collect user birthdate or age range at setup and transmit an age signal to apps and stores; the bill carried serious fines for developers who ignore the signal. The measure has moved through the legislature and has been under active consideration in early March 2026.
• New York Senate Bill S8102A, which goes further by requiring manufacturers of internet‑enabled devices to conduct “age assurance” and provide a real‑time API signal to any website, service or app on a user's device.

These laws are not mere policy suggestions; they define obligations for operating system providers, app stores and — in some instances — application developers who must rely on the OS‑supplied age signal in order to avoid liability. That legal shift is the core of the controversy.

---

What the bills actually require​

California (AB 1043) — age brackets and mandatory signals​

AB 1043 requires covered operating system providers and application stores to present an accessible interface during account or device setup that asks the account holder to indicate the user’s birth date, age, or both. Once collected, the OS must be able to provide a digital age signal to developers via a reasonably consistent, real‑time API, indicating the user's age bracket (for example, under 5, 5–9, 10–12, 13–15, 16–17, or 18 and older, in some drafts). The bill establishes a presumption that a developer relying on that manufacturer‑supplied signal is in compliance with state age‑verification rules unless the developer knows the signal is incorrect.
Key technical obligations (as drafted) include:

• Presenting an accessible age‑entry UI at setup.
• Storing age or date‑of‑birth associated with the device account.
• Exposing an API for requesting an age signal to eligible apps and app stores.
• App developers are generally required to rely on that signal unless they have actual knowledge it is wrong.

Colorado (SB26‑051) — attestations and fines​

Colorado’s SB26‑051 similarly assigns the collection obligation to the operating system provider: the OS must collect either explicit birthdate or select an age bracket and transmit the attestation to covered apps and developers. The bill includes explicit penalties for developers who fail to comply with the OSS‑provided signal: negligent noncompliance carries fines (for example, $2,500) and intentional violations higher fines (the bill text includes graduated monetary sanctions). The bill also contains applicability windows and provisions for devices already in consumer hands.

New York (S8102A) — device‑level assurance and broader scope​

New York’s S8102A mandates “commercially reasonable age assurance” by device manufacturers and requires the manufacturer to supply a real‑time API signal to any website, application or online service on the device. New York’s draft emphasizes API interoperability and imposes obligations on manufacturers to ensure the signal is made available to third parties running on the device. That language is arguably the broadest: it contemplates manufacturers actively providing an assurance to all apps and stores that run on the hardware.

---

Why this is a problem for FOSS and small vendors​

The commercial vendor case is messy, but solvable: companies like Apple and Microsoft already demand account sign‑ins and maintain payment methods tied to accounts, and they have centralized services that can implement age checks and API endpoints under company control. The real tension is with Free and Open Source Software (FOSS) — projects and distributions that:

• are distributed with permissive or copyleft licenses that bar usage restrictions (a copyright license that says "not for California residents" would violate the Open Source Definition),
• depend on volunteers and donors rather than legal teams, and
• are distributed globally without a single “manufacturer” who can centralize compliance.

Some projects have already reacted publicly. The MidnightBSD project — a small FreeBSD derivative — updated its license to include a clause excluding California residents from desktop use effective January 1, 2027, citing AB 1043’s compliance burden. That reaction is a canary in the coal mine: excluding Californian users solves the immediate legal exposure for the project, but it also violates key open‑source principles and would render the distribution non‑free by OSI criteria.
Other small vendors have taken similar stances: a scientific calculator app (DB48X) reportedly added state exclusions in its license for California and Colorado, and threads within Ubuntu, Fedora and Linux Mint communities show anxious discussions and calls for legal advice. Canonical’s VP of Engineering has publicly said the company is reviewing the legislation with counsel; community distributions and independent projects are far less equipped.

---

Technical and privacy analysis — what an “age signal” means in practice​

At first blush an age signal sounds simple: the OS says "user is 16–17" and apps enforce appropriate restrictions. But the technical and privacy realities make this far less benign.

• Data storage and retention: Collecting a date of birth (DOB) or age bracket creates a persistent, attributable data point tied to a device account. That data must be stored securely, protected under data‑protection rules (for example, CCPA/CPRA in California) and handled with retention and deletion policies. The bills require storage plus API exposure; they do not mandate a detailed privacy design. That absence matters.
• Attack surface and concentrated targets: Centralized age attestation systems and device APIs create high‑value targets. Outsourced age checks have gone disastrously wrong before: services that collect government IDs and verification images have suffered breaches, and a single credential store for DOBs and verified identities would be an attractive target for attackers. The broader lesson is that centralizing sensitive metadata increases systemic risk.
• OS‑to‑app API design: The bills envision a “reasonably consistent real‑time API.” The design choices matter:
• A raw DOB or age in the clear is the worst option for privacy.
• Age brackets are better but still sensitive.
• Privacy‑preserving tokens (for example, zero‑knowledge age tokens, signed attestations that assert “age ≥ 18” without revealing DOB) are a superior technical pattern referenced in policy discussions in Europe where the DSA's age‑protection guidance favors minimal disclosure and privacy‑by‑design. The EU even plans an open‑source age verification kit tied to its digital identity work. Implementing tokenized attestations would require shared standards and cryptographic infrastructure that currently do not exist at scale in the U.S. legislative drafts.
• Local vs. cloud verification: Vendors can implement device‑level age estimation locally (self‑declared DOB) or call out to government or third‑party verification to obtain validation. Third‑party verification solves authenticity but also centralizes PII: exactly the opposite of a privacy‑preserving design. Local self‑attestation is privacy‑friendlier but trivially spoofable. The bills’ legal weight — developers must rely on the manufacturer signal — effectively forces apps to accept whichever method the OS provides, pushing platform choices on the app ecosystem.

---

Policy, legal and licensing fallout​

Two intersecting legal dilemmas stand out.
First, the open‑source licensing conflict. If a project excludes users by geography or use case to avoid compliance obligations (for example, adding “California residents not authorized” language), that clause violates the Open Source Initiative’s definitions of a free license and undermines community norms. Several analysts have flagged this as a crisis for the open‑source commons: projects that attempt to opt‑out become non‑free and lose contributor trust.
Second, enforcement and extraterritoriality. How will state authorities enforce a rule that targets software distributed globally? Practical enforcement likely targets distributors (app stores, commercial hardware sellers) and entities with presence in the state. Small FOSS projects operating without a legal headquarters are hard to pin down; some may attempt to avoid liability by restricting downloads or adding license clauses that carve out residents of specific states. That approach is legally fraught and practically brittle.
Finally, whether these laws will survive constitutional or preemption challenges is an open question. States are experimenting with device‑level privacy mandates that could intersect with federal Commerce Clause considerations or conflict with other federal privacy rules, and the open‑source community may challenge state enforcement if it effectively requires code changes that conflict with license terms.

---

Why these designs will be circumvented — and what that means​

One consistent technical reality: determined users will circumvent weak or intrusive checks. System76’s CEO argues the bills are too loosely specified, technically brittle, and practically circumventable by minors who can:

• Enter fake DOBs or use throwaway accounts.
• Boot alternate OS builds, live USBs or containerized environments that skip setup flows.
• Use devices provisioned outside a jurisdiction or use encrypted VPNs and proxies to reach services.

The result: the laws will likely push responsible users to adopt privacy‑preserving measures and push the problem into contested territory — while still increasing the exposure of everyday users who rely on mainstream devices and app stores. In short, the laws raise privacy and security risk without guaranteeing the intended protection.

---

Practical recommendations for stakeholders​

For OS vendors, app developers, and policymakers there are concrete steps to reduce harms and increase feasibility:

• OS vendors should:
• Adopt a privacy‑first API design that transmits only minimal assertions (e.g., cryptographically signed “age ≥ X” tokens) instead of raw DOBs.
• Implement robust data governance (access control, retention limits, encryption at rest and in transit, audit logs).
• Publish a transparent developer specification for age signals and provide open reference implementations to help smaller projects comply without exposing PII.
• Offer offline setup and local parental control features for citizens who prefer not to create cloud accounts but still want to comply with local law.
• App developers should:
• Prepare to rely on the OS signal if operating in jurisdictions with obligations.
• Implement a secondary verification or manual review only where the OS signal is absent or suspected fraudulent.
• Minimize collection — do not ask for DOB if the OS indicates an age bracket.
• Seek legal counsel to understand liability under evolving state regimes.
• Policymakers and civil society must:
• Insist on privacy‑by‑design, including strong limitations on retention and secondary usage of age data.
• Fund open standards work so the age signal is interoperable and privacy‑preserving, avoiding a splintered, proprietary approach.
• Avoid one‑size‑fits‑all mandates that ignore the operational differences between commercial device ecosystems and volunteer‑driven open‑source projects.

---

International context — this is not only a U.S. story​

The European Union’s Digital Services Act and accompanying guidance on minors emphasize age‑appropriate design and limiting personal data collection — including recommending privacy‑preserving age verification methods and even preparing an open‑source toolkit for age verification in the EU context. Those guidelines reject simplistic raw‑data sharing as a privacy solution and prefer technical approaches that reveal the minimum required about a user’s age. The EU’s approach demonstrates there are better technical models than transmitting DOBs to every app, but adopting those models at scale requires investment in cryptographic attestation schemes and interoperable standards.
Some commentators have suggested Norway’s regulators and advocates have been more cautious and technically savvy in approaching child protection online; European regulators emphasize safety‑by‑design and strengthening children’s rights alongside privacy protections. The U.S. state‑by‑state approach risks producing a patchwork of incompatible technical requirements.

---

What’s likely to happen next​

Expect a period of intense fragmentation and experimentation over the next 12–24 months:

• Large platform vendors (Apple, Google, Microsoft) will likely implement OS‑level flows that meet state minimums while trying to minimize disclosure of raw PII. Their leverage over hardware and app distribution gives them compliance routes that FOSS projects lack.
• FOSS projects will splinter: some will adopt license clauses or distribution restrictions to avoid exposure (which risks being non‑free); others will try to implement privacy‑preserving local mechanisms or partner with third‑party attestors. Expect legal fights and public debates within major distributions’ communities.
• Policy responses may follow: either legislative clarification to exempt open‑source projects, or federal action to create a harmonized approach (the latter is politically ambitious but technically sensible). Without federal harmonization, the ecosystem risks a messy outcome where proprietary platforms absorb compliance burdens while volunteer projects retreat.

---

Conclusion — tradeoffs, not silver bullets​

The recent spate of state bills that move age verification into the operating system represents a policy turn with real tradeoffs. The goals — protecting minors — are legitimate. But the proposed technical path carries significant privacy and security costs, puts heavy burdens on small and open‑source projects, and may fail to deliver the promised protections because motivated users will find workarounds. The better path is to insist on standards and designs that limit personal data exposure:

• favor attestations over raw DOBs,
• require rigorous data minimization and retention limits, and
• invest in interoperable, open, privacy‑preserving protocols so smaller projects can comply without abandoning core licensing principles.

If policymakers truly want to protect children online, the technological design must be informed by security and privacy engineering — and by the realities of how software is developed and distributed today. The clock is ticking: California’s requirements take effect January 1, 2027; Colorado and New York measures are active and moving through the legislative process. The next year will determine whether this becomes a case study in careful modernization of child safety online — or an object lesson in how well‑intentioned laws can inadvertently undermine privacy, security and the open‑source commons.

---

Source: theregister.com US state laws push age checks into the operating system