We have to separate child protection from Internet control so that the "protect the kids" narrative loses its potency. So here's a counter-narrative: we can implement digital child protection without Internet-wide access control, and it requires just 3 simple features that can be implemented in less than a week. There's no need to introduce new laws at all. This could just be done tomorrow if there is genuine will to protect the kids.

1) If you're a platform like Discord or Gmail, give users the option to create an extra password lock for modifying their profile information (which includes age). This could also be implemented at the app level rather than at the account level. Parents can take their child's phone, set the age, and set these passwords for each of their child's apps/accounts.

2) If you're an OS developer, add a password-protected toggle in the OS settings that gates app installation/updates, like sudo on Linux. Parents can take their child's phone and set this password, so they can control what software runs on their child's phone. If we have this, then 1) isn't even strictly needed because parents can simply choose to only install apps that are suitable for their child.

3) If you're a device manufacturer, you should open-source your drivers and firmware and give device owners the ability to lock/unlock the bootloader at will with a custom password. Parents should be able to develop and install an open-source child-friendly OS. Companies like Apple and Samsung have worked against this for years by introducing all kinds of artificial roadblocks to developing an alternative OS for their hardware.

▲

tzs 12 hours ago | parent | next [-]

(This is a reply to the dead comment, which was not dead when I start writing this)

I don't know how long their specific proposal would take, but on a Unix or Unix-like system the California bill could be done in a week.

0. Make a directory somewhere, say /etc/age_check, and in that directory create four files: 0-13, 13-16, 16-18, 18+, owned by some system account with permissions 000.

1. This would be the hardest part. Modify whatever is used to interactively create new user accounts to ask for the user age if the account is a child's account, and than add an ACL entry for the appropriate /etc/age_check file that allows the child's account to read that file.

The California bill says you have to ask for and age or birthdate but the API you provide for apps to ask for age information just requires giving an age bracket, so I'm taking that as meaning I am not required to actually store the age. I only have to make the API work.

2. The API for checking age is to try to open the files in /etc/age_check. Whichever open succeeds gives you the user's age bracket.

▲

tzs 13 hours ago | parent | prev | next [-]

So basically parents set the child's age and apps rely on that if they need to know if the user is old enough?

That's pretty similar to the California bill. Parents set an age when creating a child's account. The OS provides an API to get the user's age bracket from that, which apps that need to know the age bracket of the user can call.

▲

txrx0000 13 hours ago | parent [-]

The California bill gets it backwards. Rather than Internet services taking the user's age and deciding what content to serve, the Internet service or app should broadcast the age rating of its content to the OS (if convenience is desired), like how movie ratings work. The responsibility to decide what content is suitable for a child should rest in the hands of that child's parent, not the state or the corporation.

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.

▲

cvhc 10 hours ago | parent | next [-]

That's not my understanding. This is what the bill says: Provide a developer who has requested a signal with respect to a particular user with a digital signal via a reasonably consistent real-time application programming interface that identifies [the age group].

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.

▲

txrx0000 9 hours ago | parent [-]

The California law is horrible because it forces everyone to let tech companies and governments decide what's suitable for children, rather than let parents decide. It's telling parents to give every app their child's age and trust that the apps will do the right thing. It also legitimizes personal data collection (in this case, the user's age) for every app and service on the Internet that wants to know your age.

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.

▲

cvhc 8 hours ago | parent | next [-]

You have a point. Though I suspect that average parents are either too lazy or not tech literate enough.

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.

▲

BlackFly 7 hours ago | parent | prev [-]

The California law is the closest thing to what we do in the physical world but better. We already decided as a society to limit the purchase of pornography, gambling, alcohol, tobacco, prostitution, drugs, via age gates and require the merchant to be liable for that. We already find this reasonable as a society. The California law recognizes the tracking problems of requiring a verifiable id online and instead recognizes that parental self-assertion at the point of account creation is enough.

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.

	▲	txrx0000 5 hours ago \| parent [-]
		We have decided as a society to age-gate the purchase of a very small selection of goods and services, but this did not require a law that says all merchants have the right to know your age. And in this case, it's not even just all merchants, but anyone that serves you any kind of information. The real world equivalent of this California bill would be more like: anyone you've ever talked to has the right to know your age. A more reasonable approach would be for parents to keep tabs on (or for stricter parents, control) who their child is associating with and where they're going, and advise their child on who/what to stay away from if they're out alone. And of course that takes parenting effort. The digital equivalent of this are things like password-gating app installation in the OS and website-blocking in the WiFi router. But I will say, I don't think these kinds of analogies are good because the Internet is too different from the physical world. And let's not underestimate the tracking power of a legally mandated data point: the age contains about 6 bits of information that can be used to identify your user account on the Internet across apps and websites, even if your inputted age is fake.

▲

gzread 12 hours ago | parent | prev | next [-]

Would the content rating be per HTML element and the browser would delete the elements with bad ratings from the DOM, or how would it work?

▲

txrx0000 12 hours ago | parent [-]

I'd imagine it works like movie ratings. You don't filter movies from scene to scene. There's just one rating for an entire site or app.

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.

	▲	gzread 12 hours ago \| parent [-]
		If a chronological social media feed contains both R and G rated elements how would you implement that?

▲

mindslight 11 hours ago | parent | prev [-]

> the API requires every service to implement it and that's not happening

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.

▲

txrx0000 9 hours ago | parent [-]

I shouldn't have defended the API or age rating solution. It's just a trap in hindsight. That kind of solution must be rejected altogether even if it's the OS checking the app/website's age rating header, because we'd be giving the OS oligopoly (Apple, Google, Microsoft) way too much leverage, and in the long term they're going to make it so that you can only run their approved apps because unapproved apps didn't implement their age rating API. And there is no competing OS to fix that situation if those same companies keep the bootloader on their hardware locked. That still puts authority over children in the hands of governments and corporations rather than parents.

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.

▲

mindslight 9 hours ago | parent [-]

You can still get hardware that you can install your own OS on. But you have to be deliberate about picking it out before a purchase, rather than hoping to unlock a random carrier phone down the line. For example my phone is a Pixel running Graphene. It has a locked down bootloader that could only be unlocked with the online consent of Google. While this most certainly chafes me (and if I could snap my fingers and make such schemes blink out of existence I would), I do have to admit that it really isn't that debilitating.

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.

	▲	txrx0000 7 hours ago \| parent [-]
		I don't think it's a market failure. The reality that password-gating software installation at the OS level can be done on most desktops but not most phones is the opposite sign of a market failure. Mobile OSes have increasingly stripped down capabilities in recent years precisely because of anti-competitive practices. The reason standard desktops have not evolved even better parental control features is not because they're not doing better than phones under a free market. They are already doing better in spite of the fact that most kids use desktops a lot less than they use phones. It's just that the absolute level of demand for parental control features has been low until recent years, and even this recent wave of demand is somewhat manufactured.

▲

panzi 13 hours ago | parent | prev | next [-]

1) Could be simpler for a start if 2) ensures that no web sites that send a special "over 18" server header are displayed. The header could be more detailed and the parent could select what things are allowed, but for a start make it simple.

▲

txrx0000 13 hours ago | parent [-]

Yes, that's even better. Make apps and websites provide an API that broadcasts the age rating of its content, then let the OS attest the apps and websites, not the other way around.

edit: on second thought, there is a trap here. If hardware manufacturers lock down the bootloader, then we're basically still handing over parental authority to governments and companies in the long run. So I think for a start, we just implement a app-install password lock like sudo. It will be easier to implement than the API. The convenience API can come later when hardware manufacturers are banned from locking bootloaders.

	▲	gzread 12 hours ago \| parent [-]
		How would you make a website that can be over 18 or not, such as a social media feed? Would it become over 18 as soon as your following list contains a porn star (who may not have been one at the time you followed them), and then if you're under 18 you can't unfollow them because you can't load the page?

▲

renewiltord 13 hours ago | parent | prev [-]

[flagged]