Published on
Updated on
A recent hot topic in the digital world is California's AB 1043, the Digital Age Assurance Act which is scheduled to become operative on January 1, 2027. It requires an operating system provider to present an interface during account setup where the account holder indicates the user's birth date, age, or both. The applications can then request this information. Among users and security researchers there are already many debates and concerns about the implications, especially for free and open source operating systems.
What is this law about?
As stated, California's AB 1043, the Digital Age Assurance Act requires an operating system provider to present an interface during account setup where the account holder indicates the user's birth date, age, or both, and then provide the applications an age bracket info:
- Under 13
- 13 - 15
- 16 - 17
- 18+
Existing devices must get a way to provide that information before July 1, 2027. Developers must request that info when an application is downloaded and launched. Violations can cause civil penalties.
The law is supposed to protect children's safety on the internet. More specifically, the law is meant to create a device-level way to tell apps whether the main user is a minor, so apps can apply age-appropriate rules instead of every app trying to guess a user's age on its own.
The "good", or specifically, what could be worse
Let's start with the good. The only thing I think I can appreciate is that it tries to avoid the worst version of age verification. The OS provides age brackets instead of full birthdate to applications. It does not require things like uploading government ID or biometrics. This is relatively less privacy-hostile.
The bad and the ugly
Now let's get to the main point. The law has numerous shortcomings, in terms of implementation, coherence and impact. This is a consequence of politicians lacking a basic understanding of how software and hardware work.
Not very strong verification
This is the first big flaw. As written, the law requires the user to indicate the birth date, age, or both. It does not itself require a proof like an ID check. This means it works well only when the parents properly configure the child's device and account. It doesn't work well when the child uses the parent's account or the child is a power user who is able to find ways to bypass things or even install an OS. And this is very common.
No mention about the implementation specifics for websites and browsers
The law says nothing about the implementation specifics for websites and browsers, it mainly talks about locally installed applications. So, how will this verification mechanism be implemented for websites and browsers, especially considering that the bulk of the unsafe content is actually on the internet? Yes, browsers are locally installed applications, but what they display is the website content. How can they distinguish between safe and unsafe content or how can the websites collaborate? No answers.
Older / unsupported devices / apps
A serious problem. For devices whose account setup happened before January 1, 2027, the OS provider is supposed to add an accessible interface by July 1, 2027 so the account holder can enter the age information. The law does not clearly say what happens to permanently unpatchable devices.
A similar problem exists for apps. Some apps are old or are no longer maintained. By the law's logic such apps are illegal, right?
The compliance burden on developers
The law requires every covered app developer to request the age at download and launch. The info becomes the primary age indicator unless the developer has clear and convincing internal information showing otherwise. Legal analysis of the act notes this could affect apps far beyond social media, including ordinary productivity, weather, or news apps, because once the signal is received it can trigger other obligations under laws like the CCPA and COPPA.
One serious related problem is that a company may decide it is easier to block, restrict features, or avoid younger users rather than build age specific experiences or parental permissions. That doesn't mean the law demands it, but it means that the safest way is to be more restrictive than lawmakers probably imagine.
The implications for open source OSes and apps
Open source software becomes an accidental victim of such awful laws. The burden is heavier for open source than for Apple, Google or Microsoft. Additionally, it is a burden, to some extent due to the free and open source philosophy. As for implementation, for a community Linux distro, that is not one small patch, it can mean changing installer flows, account services, desktop environments, software centers, and maybe package management infrastructure that were never designed for centralized identity. That is especially rough for volunteer open source software, because it involves people with the fewest resources. This is even worse for apps developers who want to target proprietary app stores, such as Google Play, Apple Store.
Luckily, some smaller independent projects might have a better chance to ignore or geofence without major consequences. For example, MidnightBSD will block California users from downloading the OS. But, unfortunately, for bigger players, such as Canonical (Ubuntu), Red Hat, and Valve (Steam OS) it's probably not a very viable option, especially considering the large population (40M) and the economic significance of California.
The implications for privacy and freedom
As stated earlier, while it's not that terrible for privacy (especially at first glance), it is still bad and has some subtle consequences:
- It will make much easier to target certain age groups by phishing, scams, grooming attempts, or social engineering.
- There is an accuracy problem. As stated earlier, multiple people can share the same account or people can lie about their age, thus make targeting errors more likely.
- And finally, the law may become far more intrusive later. Right now the model is largely self reported. If self reporting is easy to bypass, the government may come up with even more insane verifications, such as IDs, biometrics or third party services!
What can we do about this?
As you can see, the law does more harm than good. On the one hand, end users might easily bypass, on the other hand, it's a significant toll on software companies and developers. This is particularly harmful to free and open source software. Unfortunately, there is no simple off switch now. This has already been signed into law and becomes operative on January 1, 2027. The best we can hope for is to repeal or amend it in the Legislature before 2027, get a court to block it, or run a new ballot measure.
If you are in California, the most useful thing is to pressure state lawmakers now.
If you are elsewhere in the US, a practical way is supporting a court challenge, helping affected projects document the compliance burden, and watching for any California DOJ rule making or public comment process.
If you are not a US citizen, you can still support advocacy groups, sign open letters, help fund or coordinate litigation, write technical submissions explaining why the law is unworkable for open source or decentralized software, and submit comments if a public rule making opens. That matters because the law is written broadly enough to reach operating system providers, app stores, and developers, including projects outside California that still distribute software into California.
The last thing is a hope that this law will work so poorly that it will be repealed. But it's a hope...
Not the most satisfying ending, but it is what it is. See you later.