edit: on second thought, realistically, the API solution is too brittle regardless of which way it goes. Because the API requires every service to implement it and that's not happening, whereas an app installation lock only requires one child-friendly OS to implement it, then parents can choose that OS.
So the app requests a signal (like, calling an API), and the OS returns the signal (returning the age group).
Regarding API vs installation lock, TBH I don't think the law concerns that level of details. An OS or app-store installation lock that checks app ratings can be considered as a valid implementation.
The password-based app installation lock I proposed in my original comment doesn't require any kind of age checking at all, so it naturally doesn't fit the California law. The device owner (in this case, the parent who buys the device for their child) gets to decide what apps can be installed on their child's phone on an app-by-app basis using a password set by the parent. The app store doesn't need to know, and the apps don't need to know.
I do want to note that this California law alone doesn't say anything about content restriction. I won't be surprised if there was/will be another bill to assign the responsibility (which may be more controversial). But the current law is only about the age gating mechanism. And on the positive side it removes the need for actual age verification (like using ID) which other regions still insist on.
Since tracking children is generally illegal, you can also voluntarily lie and label yourself as a child when you don't want to access such content.
But yeah I get the point, API based solutions are complicated and brittle because they require all services to implement it properly. In contrast a user-set app installation password in the OS settings is more effective and easier to implement.
No it doesn't. A browser/appinstaller with parental/age controls enabled would fail as unavailable if there was no age rating on the website/app. This is exactly the solution we should be aiming for, as it keeps the incentives lined up instead of turning them upside down.
One big problem with the laws currently being pushed is that it leaves the decision for what sites are "appropriate" for kids completely in the lands of corporate attorneys. For example, Facebook will happily make an "under 18" site that uses LLMs to censor posts, but still contains all of the same dopamine drip mechanics. Whereas keeping the decision process of appropriate under the control of the end-device means parents could straightforwardly go beyond what corporate attorneys decide, and block Facebook regardless of the age rating.
I'm responding to another comment of yours here since HN loves the rate limit. In that comment you were talking about locked down bootloaders. But bootloaders are already thoroughly locked down, and most devices are still essentially usable. The current looming threat is remote attestation, which makes it so that websites (and other services) are able to prevent you from running software of your choice when interacting with them! The backwards legislation being currently pushed is all but guaranteed to end up in more demands for remote attestation, whereas the correct direction of information flow (sites/apps publish headers saying they're suitable for <18 etc) would not necessitate remote attestation.
I stand by my original comment. No new laws are needed. All of the features outlined in 1), 2), and 3) should be user-controlled, and there's no need to send info over the air.
The unlocking process zaps the userdata partition. This security model would totally suffice for locking down a child's phone. If the child zaps their phone and erases everything on it, then the parent can handle that out of band.
For the general problem, I would say that there has been a longstanding market failure here, in that parental control software isn't widespread or straightforwardly usable across different websites. Your 3 points don't really address that. (2) has been doable on standard desktops forever, and (3) just pushes mobile devices back towards the capability of desktops (which on its own is laudable!). But standard desktops have had these capabilities for decades and still haven't evolved the kind of straightforward parental controls that most parents are demanding.
