Proposed amendments to California’s Digital Age Assurance Act (DAAA) to remove open source operating systems from its scope are welcome. The original drafting inadvertently captured a range of open source projects that have little practical ability to implement the legislation’s obligations. Excluding them is a sensible correction that allows policymakers to focus on the commercial operating systems that are the true target of the law.
But the amendment does not address the more fundamental issue. The DAAA is a parental control framework, not an age assurance framework:
- it does not establish that the person currently accessing a service is the age claimed,
- it does not tell a relying platform anything about the level of age assurance behind the signal it receives, and;
- it does not require Apple or Google to independently verify a single age declaration before transmitting an age signal downstream.
What the law actually requires
The DAAA requires operating system providers to determine a user’s age category and transmit a bracketed signal (under 13, 13-15, 16-17, or 18 and over) to app stores, developers, browser providers and website operators. In practice, the most likely implementation is that the signal will be derived from age information supplied during account or device setup. What the law does not require is independent verification of that information. There is no mandatory document check, no third party verification and no minimum technical standard for accuracy, integrity or resistance to circumvention. The DAAA therefore creates a legal presumption that platforms possess actual knowledge of a user’s age category. However, the underlying signal may originate from an unverified self-declaration made months or years earlier. The law elevates the legal significance of the signal without imposing corresponding requirements on how that signal is generated.
The signal pipeline also operates very differently depending on how a user accesses a service. Passing an age signal from an operating system to a native app via an internal API is technically straightforward. Passing that same signal from a web browser to an independent website is an entirely different proposition. It requires a new, globally adopted web standard — such as the W3C Digital Credentials API, which remains in early development — to be implemented consistently across browsers and websites worldwide. Without that standard reaching universal adoption, websites will receive no signal at all. In practice this means the DAAA’s browser-to-website pipeline is unlikely to function at meaningful scale by the time the law takes effect in January 2027, leaving the open web largely outside the framework’s reach.
How easily can it be circumvented?
Consider how a 15-year-old often acquires a smartphone today in the United States. They can purchase a handset outright with cash from any electronics retailer or carrier store where no age check is required or customary. They can activate it using a prepaid SIM card bought over the counter at a supermarket or pharmacy with no identity check. Next, they can create an Apple ID or Google account by entering a date of birth of their choosing. Neither Apple nor Google is required by this legislation to perform independent age verification when a user creates an account. If a user claims to be over 18, that declaration becomes the foundation of every subsequent age signal generated by the operating system.
And the fact that a parent pays the monthly carrier bill provides no protection. The carrier relationship and the operating system account are entirely separate systems with no linkage between them. A parent can be the named account holder on a family plan at Verizon or AT&T and that fact is invisible to Apple and Google. The child’s account declaration stands alone.
Even where a parent has correctly configured a device using a child’s real age, circumvention risks remain. A child can create a new account with a different birthdate and switch to it on the device. On Android this takes minutes. On iOS it requires access to the existing account credentials, but in households where parents share passwords — which is common — there is no meaningful barrier. A newly purchased or factory reset device presents no obstacle at all.
The same vulnerabilities that allow a minor to obtain an adult signal also allow an adult to obtain a child signal. An adult who simply creates an account declaring a minor’s date of birth, or who gains access to a device configured with a child’s age, will generate a signal identifying them as a minor. A platform relying on that signal as its primary indicator of age has no means of detecting the discrepancy. This creates a direct avenue for adults seeking to access child-oriented spaces, groom minors or engage in sextortion by presenting themselves as peers. The risk is not hypothetical – law enforcement agencies have documented extensively how predators adopt false juvenile personas on platforms where they believe their targets congregate. An age signalling framework that can be configured to produce any desired output provides no protection against this threat and may actively facilitate it by giving bad actors a compliant-looking signal to which they can point.
The California legislation contains no requirements governing how any of these circumvention risks must be addressed. It does not establish minimum standards for account integrity, parental controls, age verification or tamper resistance. Those decisions are left entirely to the operating system providers. A more robust implementation could involve stronger device-level controls, independent age assurance, cryptographically protected parental assertions or other technical safeguards. The DAAA does not require any of them.
The safe harbour asymmetry
The legislation creates a striking and risky asymmetry. The entities responsible for generating the age signal receive liability protection. The entities expected to rely upon it continue to carry the regulatory risk.
Operating system providers, browser providers and app stores that make a good faith effort to comply with the DAAA receive substantial liability protection under section 1798.503(b), including for erroneous signals and for certain downstream conduct by platforms that receive them. Developers and website operators receive no equivalent protection. They are deemed to have actual knowledge based on a signal whose integrity is not guaranteed, yet they remain responsible for complying with COPPA, state privacy laws and a growing range of other age restrictions that California may follow other states in adopting e.g. age restrictions or parental consent requirements for AI, companion chatbots, social media and pornography.
This means Apple and Google receive the greatest legal certainty under the framework while the platforms depending on the resulting signals continue to carry significant compliance risk. The Act effectively turns independent developers into underwriters of an age indication system whose primary sources bear no liability regardless of how it performs. Platforms are legally required to act on age signals they had no role in generating and no means of verifying, while the entities responsible for generating those signals are substantially insulated from the consequences of getting them wrong. There is consequently limited commercial incentive for operating system providers to go beyond the statutory minimum in order to maximise assurance levels or reduce circumvention risks.
What this means for platforms
Platforms should not assume that receiving and acting on a DAAA signal satisfies their obligations under COPPA, applicable state privacy laws or any future legislation requiring reliable age determination. The DAAA does not provide them with a blanket safe harbour in relation to those obligations. Importantly, while the law generally treats the operating system signal as constituting actual knowledge of a user’s age category, that presumption does not apply where the platform possesses clear and convincing information indicating otherwise. The DAAA signal is not the final word.
This creates a practical challenge for platforms. If a service receives an “18 and over” signal from the operating system but its own telemetry, user behaviour, parental reports, account history or other evidence strongly suggests that the user is in fact a child, the platform cannot ignore that information and simply rely on the operating system signal. This creates a troubling structural incentive.
This problem runs deeper still. A platform that invests in robust internal safety analytics – tracking behavioural signals, monitoring for grooming patterns or identifying users whose conduct is inconsistent with their declared age – will inevitably accumulate the kind of evidence that constitutes clear and convincing information under the Act. In doing so it loses the protection of the OS signal and assumes greater legal exposure than a platform that chose not to look. The law therefore risks creating a commercial incentive for wilful blindness, penalising the platforms that try hardest to protect children and rewarding those that do not.
Where a law requires a platform to know, verify or reliably determine a user’s age, independent age assurance will still be required regardless of any operating system signal. Platforms that treat the DAAA signal as a blind fallback and do nothing further may find themselves exposed precisely when it matters most – when a determined minor has circumvented the OS-level control and the platform had information suggesting that this had occurred.
The broader policy point
The AVPA supports measures that help parents manage children’s online experiences. Device-level age signals and parental controls can form part of a broader child safety ecosystem and may serve as useful inputs into a platform’s age assurance process. They are not, however, a substitute for independent age assurance for medium and high risk use-cases.
Where legislators want reliable age determination — not just a declared age passed through a pipeline — they should require publisher-level age assurance conducted against recognised technical standards such as ISO/IEC 27566-1 and IEEE 2089.1. These frameworks establish what a sufficient assurance level looks like and provide the kind of accountability that device-level attestation cannot.
Our primary concern is that, by creating deemed actual knowledge without specifying how that knowledge must be established, the DAAA risks encouraging reliance on age signals whose legal significance exceeds their technical reliability. As legislators around the world consider similar proposals, the key question should not be whether an operating system can transmit an age signal. Another key question is whether that signal provides sufficient confidence in a user’s age for the purpose for which it is being relied upon, and by removing the liability for accuracy from those who are responsible for creating this age signal, what motivation is left to get it right?