AB1856 amends Civil Code §1798.501 to make operating system providers responsible for offering an accessible account-setup interface that records a user’s birthdate or age and issues a digital age‑bracket signal to applications via an API. The bill imposes limits on what information may be transmitted and prohibits sharing the signal for purposes beyond those required by the statute.
The change shifts a portion of age‑verification infrastructure toward platform operators and creates a statutory evidentiary framework for developers: apps must request the signal when downloaded and launched, and signals function as the primary indicator of a user’s age unless strong internal evidence indicates otherwise. That alters compliance practices for app makers, platform teams, and privacy officers and raises questions about accuracy, liability, and data governance.
At a Glance
What It Does
Requires operating system providers to collect age or birthdate at account setup and provide a digital age‑bracket signal to developers through a reasonably consistent real‑time API. Developers must request that signal when an application is downloaded and launched and use it to comply with applicable law.
Who It Affects
Operating system vendors and covered application stores (platforms), mobile and connected‑device app developers, privacy and compliance teams, and services that rely on age data (ad networks, content moderators). It also impacts minors and their guardians by changing how age is asserted to apps.
Why It Matters
Creates a uniform, platform‑level mechanism for age classification that reduces reliance on per‑app self‑attestation while enforcing data‑minimization limits. The bill changes legal exposure for developers by giving statutory force to platform signals and constrains secondary uses of that signal.
More articles like this one.
A weekly email with all the latest developments on this topic.
What This Bill Actually Does
The bill establishes a system where the operating system (or covered store) is the source of a simple, categorical age signal apps can rely on. At account setup the platform must present an accessible interface that asks the account holder for the birthdate or age of the device user; that input is not published as raw birthdates to apps but is converted into one of four brackets that the platform returns on request.
Platforms must provide this return through a realtime application programming interface that developers can call when the app is installed and first launched. The statute requires the API to be reasonably consistent in behavior across requests.
Developers have a duty to request the signal at download/launch and to use it to comply with the law; the bill says that receiving a platform signal gives the developer “actual knowledge” of the user’s age range across all points of access to the application, even if the developer tries to ignore it. The bill also builds an exception path: if the developer has internal, clear and convincing information that the signal is wrong, that internal information becomes the primary indicator instead.Data minimization is an express constraint.
Platforms must send only the minimum information necessary to satisfy the statute, and both platforms and developers are forbidden from sharing the signal with third parties for purposes not required by the law. Developers may not ask platforms or stores for anything beyond that minimum, and platforms must avoid using the information for unrelated commercial purposes.Practically, the statute creates both a technical and a legal workflow: platforms implement an accessible account interface and API; developers integrate an API call at first run; and decision trees in developer code will need to handle the platform signal, the narrow exception for clear and convincing internal evidence, and the limits on additional data requests or onward sharing.
The bill does not specify verification technologies (biometric checks, document validation) or set penalties in this text; it instead sets obligations and evidentiary rules about how age information is collected, transmitted, and treated.
The Five Things You Need to Know
The bill requires platforms to categorize users into one of four age brackets (under 13; 13–15; 16–17; 18 and over) and deliver that bracket via API rather than transmitting exact birthdates to apps.
Developers must request the platform’s age signal when an application is downloaded and launched; receiving the signal gives the developer 'actual knowledge' of the user’s age range across all platforms and access points.
A developer that willfully disregards clear and convincing internal information that contradicts the platform signal is not permitted to ignore that internal evidence; internal clear and convincing evidence becomes the primary indicator of age.
Both platforms and developers must limit data exchange to the minimum information necessary to comply, and neither may share the age signal with third parties for purposes not required by the statute.
Platforms must provide the signal through a 'reasonably consistent' real‑time application programming interface, creating an expectation of stable API behavior for developers integrating the check.
Section-by-Section Breakdown
Every bill we cover gets an analysis of its key sections.
Accessible account interface to collect age or birthdate
This subsection requires operating system providers to implement an accessible prompt at account setup that asks the account holder to indicate the birthdate, age, or both for the device user. The practical implication is that platform account creation flows must include an explicit, accessible field tied to age collection; platforms will need to design UI/UX, accessibility support, and privacy handling to meet that requirement.
Platform must deliver categorical age signals via API
This provision mandates that platforms provide a digital signal through a reasonably consistent real‑time API that identifies which of four statutory age categories applies to the user. That shifts the technical integration point for age checks away from individual apps toward platform APIs and creates an implementation requirement for platform engineering (API endpoints, authentication, rate limits, latency expectations).
Data minimization and limits on secondary sharing
Platforms must send only the minimum information necessary to comply with the statute and may not share the signal with third parties for purposes not required by the title. This imposes a data governance constraint: platforms must map internal data fields to the minimal statutory output, document what 'minimum' means operationally, and ensure contractual and technical controls prevent downstream parties from repurposing the signal.
Developer duty to request and legal effect of receiving a signal
Developers must request the age signal when an application is downloaded and launched. Once a developer receives a signal, the statute deems the developer to have actual knowledge of the user’s age bracket across all platforms and points of access, whether or not the developer intends to act on it. Developers are also barred from willfully disregarding clear and convincing internal information that contradicts the signal; that standard forces developers to reconcile platform data with any strong contrary evidence they possess rather than simply ignoring contradictions.
Primary indicator rule and limits on additional requests or sharing
The statute instructs developers to treat the platform signal as the primary indicator of age for compliance purposes, except where internal clear and convincing information shows otherwise. It also prevents developers from requesting more information from the platform than the statute’s minimum and forbids sharing the signal with third parties for unrelated purposes. That creates a narrow compliance model: rely on the platform bracket unless you have compelling internal proof to the contrary, and avoid augmenting the signal via additional platform queries or external disclosures.
This bill is one of many.
Codify tracks hundreds of bills on Privacy across all five countries.
Explore Privacy in Codify Search →Who Benefits and Who Bears the Cost
Every bill creates winners and losers. Here's who stands to gain and who bears the cost.
Who Benefits
- Minors and guardians — by consolidating age assertion at the platform level, the bill reduces per‑app collection of sensitive birthdate data and limits onward sharing of the age signal, shrinking surfaces for misuse or leaks.
- App developers with mature compliance teams — they receive a uniform, platform‑level age indicator and clearer evidentiary footing for enforcement and content‑restriction decisions, reducing the need to design separate age‑capture flows.
- Privacy and data governance teams — the statute’s data‑minimization requirement and prohibition on secondary uses simplify policy drafting and contractual controls with third parties, aligning a platform‑provided signal with privacy best practices.
Who Bears the Cost
- Operating system providers and covered app stores — they must build accessible account prompts, an authenticated realtime API, and data‑minimization mechanisms; engineering, UX, and privacy teams bear initial implementation costs and ongoing maintenance.
- Small app developers and indie publishers — while the signal reduces some compliance work, small developers must integrate the API at install/launch, interpret the 'actual knowledge' standard, and may face legal risk if they mishandle contradictory evidence.
- Third‑party data processors and advertising networks — the ban on sharing the signal for unrelated purposes cuts off a potential data feed, which may require reworking targeting, measurement, or verification workflows that previously relied on platform-provided age data.
Key Issues
The Core Tension
The central tension is between creating a single, privacy‑conscious source of age truth (which simplifies compliance and reduces data exposure) and the risk that a platform‑level, categorical signal will be inaccurate, insufficiently verified, or abused—shifting legal and operational burdens onto developers while leaving open hard questions about verification standards and enforcement.
The bill sets policy by defining where age information comes from, how it is transmitted, and how developers must treat it, but it leaves several operational and enforcement details unspecified. The statute requires a 'reasonably consistent' realtime API and 'minimum' information transfer but does not define metrics (uptime, latency, authentication standards) or what constitutes the minimum dataset.
Platforms and developers will need to negotiate those practical definitions in technical documentation, contracts, or guidance that the bill does not mandate.
The law imposes an evidentiary structure—platform signals create 'actual knowledge' and are the primary indicator—while allowing a high threshold (clear and convincing internal evidence) to override the signal. That creates two implementation risks: platforms may underinvest in verification because the law relies on their signals, and developers may face new liability if they fail to act on signals or misapply the clear and convincing exception.
The statute also lacks explicit enforcement mechanisms, penalties, or remedies in this text, leaving uncertainty about remedies, regulatory oversight, and civil liability pathways.
Try it yourself.
Ask a question in plain English, or pick a topic below. Results in seconds.