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.
(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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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?
Code-writing speed is not a bottleneck when the stakes are high. Sometimes, it's better to slow down, plan ahead, and consider the consequences because the cost of a failed iteration is too great.
Take the way AI is being developed as an example. People rush to build giant agents in giant datacenters that are aligned to giant corporations and governments. They're building the agentic organism equivalent of machiavellian organizations, even though they'd be better off building digital humans that are aligned to individual humans that run on people's gaming PCs at home. They will find out that the former is the wrong architecture, but the cost of that failed iteration is the future of human civilization, and nobody gets a second try.
Of course, this is an extreme example on one end of the scale. On the other end, it wouldn't matter at all if you're building a small game for yourself as a weekend project with no users to please or societal impacts to consider.
This seems fine as a short-term solution, but human-only is no good as a long-term rule. The AIs will soon surpass human capability. Even in the present, I think some AI comments are already decent quality. It's just most of them aren't high quality yet.
And I'm worried banning AIs altogether will eventually lead to some form of prove-you-are-human verification to use the site, which will reduce anonymity. Even something seemingly benign like verifying email would mean many unverified accounts like my own will disappear.
And there is a legitimate use for LLM rewrite to counter identification by stylometry, so rewrite shouldn't be banned. I think we'll have to allow the AI stuff at some point, and make a system that incentivizes quality posts regardless of where they come from or how they're written.
> I'm worried banning AIs altogether will eventually lead to some form of prove-you-are-human verification to use the site, which will reduce anonymity.
Of all the sites on the Web to worry about this happening, HN is low risk. Oppose that change if it comes, not this one.
> And there is a legitimate use for LLM rewrite to counter identification by stylometry
Source for comment-level stylometry ever actually being someone's downfall, despite availing themselves to every other much more standard defense measure? Regardless, if your experimental means of deanonymizing yourself comes at the expense of the site's quality, it is probably not welcome.
Glad to see more of these efforts. But here's what it will really take to decentralize social media and E2EE messengers:
We need something like Discord, except each server is an actual self-hosted server like a Minecraft server. DMs between two users should be handled by a mutual server. Account credentials should be handled by a Nostr-like protocol, which also gives you global tweeting capabilities as a bonus.
Run the whole thing on Yggdrasil Network or something similar so that it's not tied down to IPv4v6 and DNS and all existing hardware infra, but can still take advantage of them. And add reciprocal inter-server onion routing to make it difficult to geolocate servers. Also take a page from SoftEther VPN's book and wrap all traffic in HTTPS and perform automatic NAT traversal, so that people can host servers from behind ISP firewalls.
Anything short of that and we lose to big tech and govs in the long run. But once we've achieved the above, the decentralized web can truly take off: we will get WiFi routers running open-source firmware to make a mesh network to act as alternative physical layer infra for the new web. We can still take advantage of the existing Internet's bandwidth as long as there's an unblockable path to send a little bit of data to discover and coordinate nodes.
> Anything short of that and we lose to big tech and govs in the long run.
This is not a software issue, it doesn't matter how good the tech is, the masses will always aggregate to big tech networks because decentralized networks will never have billion dollar marketing budgets.
I don't think that's true. If there really was a good enough open-source Discord alternative, many would already switched. A big part of the problem is there isn't one. Matrix, Stoat, Telegram, etc are all missing something. That's why new ones are being built.
Non big tech solutions don't need billion dollar's worth of marketing. In fact I don't recall ever seeing an ad for tiktok and yet it is humongous.
Non big tech solutions need solid UI and UX that does not assume your average user can balance a binary tree, know what is a private key and how to safely back it up (other comments brought up this exact issue) or even knows what a "static website" means. Non big tech solutions need to give non technical users (read: the overwhelming majority of humanity) a good onboarding experience that does not involve learning ten new jargons and acronyms. Non big tech solutions need to know they have a limited strangeness budget [1] and should only spend it on places it matters. Non big tech solutions need to start actually cater to the unwashed masses before being befuddled by them choosing to stay on mark zuckerberg's platforms instead.
> In fact I don't recall ever seeing an ad for tiktok and yet it is humongous
Then maybe you're not the target audience, or you're just not noticing the ads, because TikTok is particularly notable for their aggressive marketing efforts during their growth phase.
> Non big tech solutions need solid UI and UX that does not assume your average user can balance a binary tree
Non big tech platforms don't need anything. They can never compete with billion dollar budgets and they shouldn't set that as a goal. Everyone enjoys a well designed UX, but billion dollar marketing budgets will always eclipse the alternatives.
I guess I’d rather have something approaching bittorrent, edonkey/kad, ipfs, blockchain, webarchives.
You have named networks that are federated together, and people can publish to the networks they are invited to or sign up for. The networks survive even with individual servers go down. Data is cached all over at the edges.
Your version is just way too susceptible to rot, unless you see that as a feature. I see it as most of the good content falling into the ether sooner rather than later.
The problem with distributed storage is they place too high of a requirement on edge nodes, which people have to host, and they synchronize too slowly for real time messenging. If I upload a 1GB video to my server's chat, that storage load should not be replicated on many other nodes. Who pays for that disk space? The federated model is a lot more robust in this regard.
As far as archiving is concerned, many archiving orgs will pop up if their discussion servers and public facing websites can't be traced or easily shutdown. The protocol itself can't archive things, but it protects the people doing the archiving work and gives a place for websites like Annas Archive to live without relying on IP and DNS. The idea is to amass enough uncensorable social power so that such efforts can't be banned or shutdown, then you can use existing protocols like BitTorrent all you want.
Each device (cellphone/laptop) is a server. They connect to preferred server stations that are used for discovering other peers. There are things like common chat rooms on the station servers but personal messages are completely p2p using webrtc.
There are other apps there, for example to host own websites or blogs and other things you'd expect from modern usage. Mesh is done today using cheap ESP32 devices (3 euros each).
It is a work in progress, the main point is that it can exchange data even outside the internet and use radio connections.
Nice project. P2P is not the way to go for DMs though. Both users and servers have to stay anonymous if we want to defeat surveillance and censorship long-term.
Ideally, nobody except a single server node of your choice (which is probably the one you self-host) is able to match your Nostr identity to your real IP address. Instead, IP-like-identifiers (like in Yggdrasil Network) should replace IP addresses when interfacing with other nodes. Server hosts would not share their traditional IP when inviting new people to connect to it, only their IP-like-identifier. The invited person can pick/host their own trusted server node as well, and that trusted server would relay that user's connection to your server, which they don't trust. Everyone has a trusted server that represents them.
The trusted server and the untrusted server should not have eachother's IPs during this relay process, either. Instead, the data should be bounced through some other server first, who may bounce it again, and again. The actual underlying path the data travels between the two servers which represent the two users should involve many onion-routed bounces that is not fully known to any server or user. The only situation where a device needs to know another device's IP is when two server nodes establish a reciprocal routing agreement and exchange IPs over an encrypted tunnel ("if I bounce X amount of traffic for you, you will bounce X amount of traffic for me in the future", it's a bandwidth transaction). Such negotiations should be made by querying random addresses or established manually (early on, when the network is small and sparse). This is where offline meshes can help. An ESP32 mesh doesn't have nearly enough capacity to handle all the messages and multimedia flying around, but they can be an alternative pathway to negotiate routing agreements. When the network is dense enough, it will be difficult to pin down your IP, even for state-level actors. And they certainly won't be able to surveil many people at once because even honeypotting one would be incredibly expensive.
Also consider encapsulating all of the Internet-routed traffic in HTTPS using only port 443 (like this: https://www.softether.org/1-features/1._Ultimate_Powerful_VP...). It needs to blend in with traditional web traffic so that no infra operator can identify/block/throttle it.
Also make sure to stay anonymous while developing this so you can't be sued or prosecuted.
unfortunately though i think self-hosting is one of the problems. one of the features of discord is how easy it is to create your own server.
from that list i am checking out commet now, which seems to promise a better experience on top of matrix. that would at least solve the self-hosting issue, as i'll be able to use it on any existing matrix server. matrix has the technical features needed to work like discord, but not the interface.
> If you want a better proposal bring technical expertise to the discussion instead of ideology fundamentalism.
Fine. All we need is a password-protected toggle in each app that enables child mode, and another toggle in the phone settings that locks app installation/uninstallation. Remote verification schemes are completely unnecessary. For details see:
The way people are reacting is not extremist at all. Remember, the government protects child predators if they're rich or powerful enough. What more evidence do you need that they aren't doing this for the children? We should call it out for what it is.
Don't give them an inch. The US defense budget is $1T. They can't spend it all on surveillance, but let's say the tech companies and the government spends that much every year combined. Our victory condition is to increase the cost of surveillance and deanonymization to >$10K per person per year, which is very doable. Every little habit and precaution you take against online tracking will raise the cost, probably a lot more than you think. Spreading the word multiplies that. Every open-source program and protocol spec that aims to decentralize and anonymize is like an incinerator for the surveillance dollars. And if you're more competent than that, you may consider following in the footsteps of Daniel Bernstein or Edward Snowden and make some trillion-dollar dents.
Anonymous and uncensored information exchange can prevent the vast majority of violent conflicts and shorten the necessary ones. Most violence in human history could have been prevented if every human being had 1) the ability to telepathically communicate with anyone else in the world without being eavesdropped, and 2) the ability to broadcast information anonymously to all of humanity in real-time. I will leave the details of why for you to deduce. These things are within reach right now for the first time in history. So we can and should build the decentralized web, and democratize the entire computing supply chain all the way down to chip fabbing and electricity generation. It is the greatest unrealized potential of the Internet, and we mustn't cede ground to ensure the path to that future remains open.
Rather than age verification, this is what we should be doing instead:
Don't let phone manufacturers lock the bootloader on phones. Let the device owner lock it with a password if they decide to. Someone will make a child-friendly OS if there is demand. Tech-savvy parents should be able to install that on their kid's phone and then lock the bootloader.
What about non-tech-savvy parents?
There should be a toggle in the phone's settings to enable/disable app installation with a password, like sudo. This will let parents control what apps get installed/uninstalled on their kid's device.
But what about apps or online services that adults also use?
Apps and online services can add a password-protected toggle in their user account settings that enables child mode. Parents can take their child's phone, enable it, and set the password.
----
All it takes is some password-protected toggles. They will work better than every remote verification scheme.
The only problem with this solution is that it does not help certain governments build their global mass surveillence and propaganda apparatus, and tech companies can't collect more of your personal info to sell, and they can't make your devices obsolete whenever they want.
We all demand Windows but without ads, but that doesn't cause the market to spit one out. The OS market isn't a healthy market, and government is stepping in here in part because of that market failure to provide a satisfactory solution here.
The smartphone OS market is not healthy precisely because manufacturers lock their bootloaders (among other anti-competitive tricks, like a proprietary IMS stack), which stifles market competition. The desktop OS market does not have this problem. There are many Linux distros and they're getting better everyday, they'll eventually replace Windows as Windows slowly enshittifies.
This approach makes sense to me, though I'd expand password to be a broader term because people might prefer different authentication methods or approving a request to install software from their own device or so
The idea is to let parents decide which apps are suitable for their child, for each child. Password-gating app installation (just like sudo on Linux) is not only easier to implement and use, but also much more flexible and powerful than a fixed age-based rating system.
It also prevents the legitimization of app store monopolies because no centralized authority is needed to create or enforce a rating system. And there will always be apps that don't comply with a rating system out of privacy concerns (it leaks the user's age, which is just an extra data point to track you with), and then they'll eventually try to ban non-compliant apps from running on the device completely. That's what enforcing an age-based standard would take. And even then it would still not fulfill its (claimed) purpose that well.
Principle-wise, parenting should be the responsibility of parents, not governments or corporations. Those large organizations have their own agendas which are somewhat misaligned with the individual human being.
If the goal was to protect the children, there are much simpler solutions. But for whatever reason, companies and governments are avoiding the simple solutions like the plague.
Let me explain the simple solutions:
Don't let phone manufacturers lock the bootloader on phones. Let the device owner lock it themselves with a password if they want to. Someone will make a kid-friendly OS if there is market demand and tech-savvy parents can install that and lock the bootloader.
What about the non-tech-savvy parents?
Don't restrict people from sideloading apps. Let the user set a password-based app installation lock if they want to. It should be a toggle in the phone's settings. Someone will make kid-friendly apps if there is demand. This lets average parents control what apps get installed or uninstalled on their kid's phone.
But what about apps or online services that adults also use?
Apps and online services can add a password-protected toggle in their user account settings that enables child mode. Let the user set the password and toggle it themselves. Parents can take their child's phone and toggle this.
----
Notice how easy these things are to implement? All of these features could be implemented in less than a week. But instead of doing this, they want to implement much more complicated schemes where the gov and corps control all the toggles, and you control none. Why is it like that? Surely there are no ulterior motives, right?
Profit does not drive all. There are other valuable things besides money. A healthy society must regulate shortsighted profit-seeking and power-seeking. That's what these conversations are for.
Glad to see efforts like yours. I will give my two cents:
Decentralizing everything doesn't scale well. Instead of doing that, look at how Minecraft does it. Decentralize at the server level, not client device level. Each node should be someone's Linux computer plugged in beside their router, not someone's phone.
Minecraft is successfully decentralized, except for the identity service. When you buy Minecraft, you're actually buying the right to register an account. You could just copy what Minecraft does, but add a decentralized identity service plus some anti-censorship measures. Don't touch cryptocurrencies at all, it has a bad reputation due to scams and you will lose to mainstream competitors just because of that. Take ideas from Nostr but stay away from Bitcoin. I like the idea behind crypto but it should be a separate project, not embedded in the messenger.
Give it a polished cross-platform app UI/UX on par with Discord. Do the development entirely anonymously so that you can't be sued. Open-source both the client and server. Make your binaries reproducible so that people can verify there's no backdoor.
And to combat censorship, wrap all traffic in HTTPS and add NAT traversal like SoftEther VPN. Use a decentralized compact routing scheme like Yggdrasil Network to replace IPv4/v6, and add onion routing between servers. That will make it nearly impossible to geolocate servers and the traffic will permeate everywhere as if all firewalls don't exist.
The result is an app like Discord, where people can host their own servers like Minecraft but better because there's no need to port-forward (and each server is an actual Linux server/computer/VM), that is impossible to censor even for nation states. And if you add a Nostr-like protocol for passing global messages between servers, it could replace Twitter/X as well.
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.
reply