4 ms·

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 imp

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.

renewiltord 7mo ago
[flagged]
tzs 7mo ago
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 7mo ago
  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.
  - gzread 7mo ago
    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 7mo ago
      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 7mo ago
        If a chronological social media feed contains both R and G rated elements how would you implement that?
  - mindslight 7mo ago
    > 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.
panzi 7mo ago
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 7mo ago
  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 7mo ago
    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?
    - panzi 7mo ago
      More and more countries want to make social media >18, or at least >16 or something. :/
tzs 7mo ago
(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.

renewiltord 7mo ago

[flagged]

tzs 7mo ago

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 7mo ago
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.
- gzread 7mo ago
  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 7mo ago
    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 7mo ago
      If a chronological social media feed contains both R and G rated elements how would you implement that?
- mindslight 7mo ago
  > 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.

panzi 7mo ago

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 7mo ago
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 7mo ago
  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?
  - panzi 7mo ago
    More and more countries want to make social media >18, or at least >16 or something. :/

tzs 7mo ago

(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.