I think in this context, scaffolds are generally the harness that surrounds the actual model. For example, any tools, ways to lay out tasks, or auto-critiquing methods.
I think there's quite a bit of variance in model performance depending on the scaffold so comparisons are always a bit murky.
Except none of these bills (California or the one in question) as currently written require an ID to actually be verified, merely that the user provide an age. This seems intentional as it's seems to solve the user journey where a parent is able to set a reasonable default by simply setting up an associated account age at account creation. It's effectively just standardizing parental controls.
I think this is a reasonable balance without being invasive as there's now a defined path to do reasonable parenting without being a sysadmin and operators cannot claim ignorance because the user input a random birthday. The information leaked is also fairly minimal so even assuming ads are using that as signal, it doesn't add too many bits to tracking compared to everything else. I think the California bill needs a bit of work to clarify what exactly this applies to (e.g. exclude servers) but I also think this is a reasonable framework to satisfy this debate.
I've seen the argument that this could lead to actual age verification but I think that's a line that's clearly definable and could be fought separately.
Kids aren't stupid. They'll just create another account when they're old enough to figure it out. They'll tell their friends how to do it and the rest of us will be stuck with these stupid prompts forever like it's a cookie banner.
Actually given boot chain protection, this will probably get harder as time goes on but even assuming some kids are able to, this is clearly definable as a user error: the fault lies with the kid and as a parent you need to think about your threat model.
Right now, it's not even clear how to create parental controls at a reasonable level so there's no clear path for what to do or how to respond.
Maybe we can agree that if you're mature enough to hack your own phone, you're mature enough to see a nipple. Why am I rate limited though? Dang must hate this opinion.
I don't think "real" age verification with ids is immune to this either. (kids paying an adult to get an id for it or fooling an ai classifier, whatever).
Basically unsolveable, so why worry about that edge case? Kids will always get through to some adult content somewhere. A token system will make parents feel better in the meantime.
From a parent's perspective, that's the great part about bubbling it up to the OS user account level.
Its trivially easy to see if the user (child) has indeed created multiple OS level user accounts with different permission levels if you want to spot check the computer.
You'll see it on first startup and then you can have "a chat". With Guest account access disabled, spawning a new account on a computer takes 2-3 minutes, will send emails and dashboard notices to the parent.
Its very much near impossible to verify that the child is not just going to Facebook etc. and using separate accounts and just logging out religiously.
That said I wish Apple/Microsoft/Google had more aggressively advertised their Parental Control features for Mac/Windows/ChromeOS as a key differentiator to avoid Ubuntu/Open Source distros from having to implement them.
> You'll see it on first startup and then you can have "a chat". With Guest account access disabled, spawning a new account on a computer takes 2-3 minutes, will send emails and dashboard notices to the parent.
On what OS? Microslop Windows? On my computer no one is notified when an account is created. And the account list isn't visible when I log in. I log in to the TTY.
Now, granted, I am not the norm. But my OS falls under these regulations. So what is my OS vendor supposed to do? For that matter, who is the vendor? What if I were using LFS? Who even would be the vendor for LFS? It's not even a distro!
Yes it doesn't show up probably because you were able to pretty easily mindlessly click through the part where you were asked if this is being provisioned as a child's computer.
When you provision a Windows, Mac or Chromebook these days as a child's device using your parental account, it will require a parental account to enable new user accounts and/or re-enable guest user on the device.
Like I said - my preference would have been for Microsoft, Apple, Google and Meta and TikTok to have made an industry effort to educate parents about the existence of such tools a priori of any legislation, we could have avoided Linux etc. getting sucked in.
It's pointless. Kids who want an uncensored internet will use a VPN or proxy the same way they've been getting around the restrictions and filers put on the computers and networks at schools. These laws will do nothing to protect children but will instead enable them to be targeted.
I don't think its quite so easy anymore that I can tell, with parental tools today - on a properly provisioned device you can require parental permission for app installs such as VPN, etc.
So you're advocating for stronger and more invasive controls?...
I think this is a sensible compromise. It gives parents more control than before without relying on shady third-party software or without turning every platform into a cop. Yeah, it also aligns with Meta's interests, but so what?
The age attestation solutions pursued by the EU are far more invasive in this respect, even though they notionally protect identity. They mean that the "default" internet experience is going to be nerfed until you can present a cryptographic proof that you're worthy.
> I think this is a sensible compromise. It gives parents more control than before without relying on shady third-party software or without turning every platform into a cop.
It doesn't give parents any control whatsoever. It just forces the OS to tell every website your child goes to how old they are. It doesn't require those websites to hide certain content for certain age groups. It doesn't define what types of content are appropriate for which age groups, it just makes sure that every advertiser bidding on your child's eyes knows what age range they fall into to.
If anything this takes control away from parents because even the cases where a website does their best to restrict content based on which age the OS tells them your kid is, it's the website setting the rules and not the parents. You might think that your 16 year old can read an article about STDs, but if the website your kid visits doesn't think so you as the parent don't get any choice.
With 3rd party software parents are controlling what software is used, they have the ability to decide which kinds of content are appropriate for their children and can be allowed and which types of content should be blocked. They can black/whitelist as they see fit. All of the power is in the parent's hands. This law gives parents one choice only: "Do I honestly tell my OS how old my child is". That's the end of the parent's involvement and the end of their power.
I mean on a UNIX OS you could make it yet another group the user needs to be part of. Like the group for access to optical media or for changing network credentials. Whether the child gets root access is on the parent, but that is like with anything else. A child can get around this, but it means finding and exploiting a 0-day on the OS. If they are able to pull this of I would congratulate them.
There is a huge attack surface for this. For example, kid manages to buy an old phone. Resets the phone and creates an account. Kid buys something like a Pi 3 manages to get a regular phone to become an access point. Etc. If a laptop is not completely locked down, a kid might boot a live USB stick.
The problem is that these laws tend to escalate. Once a government starts regulating, it doesn't stop.
It is also the wrong model. Instead of creating child-safe devices, just like there is a difference between toys and power tools, this regulation pretends that all devices are child safe and parents have to figure out which ones really aren't.
I don’t care if it’s part of the user setup, but make it an App Store dotfile. Don’t issue fines to Debian for offering a Docker image without a user setup script.
Except how is this done on GNU/Linux or FreeBSD or Haiku? Who's going to implement it, who's going to ensure it can't be bypassed and who's going to be responsible if it's not?
I agree. There is a real drive to catastrophize here but so far, none of the bills actually take any steps to prevent users from lying about their age.
Some of these are also just like really weak? One of them for example seems to be some random employee at FB donating ~$1k to a politician and calling that a link. The entire "Proven Findings" is all over the place and provides no coherence. I don't think it's a particular secret that Meta would prefer age verification be done at the OS level so I'm not really sure what the added claim here is.
> A Meta employee (Jake Levine, Product Manager) contributed $1,175 to ASAA sponsor Matt Ball's campaign apparatus on June 2, 2025. Source: Colorado TRACER bulk data.
> No direct Meta PAC contributions to any ASAA sponsor across Utah, Louisiana, Texas, or Colorado. Source: FollowTheMoney.org multi-state search.
While it is true that Meta has funded groups that advocate for age verification, a lot of them also appear to have other actors so it's not like this is some pure Meta thing as some of the other commenters are suggesting.
Depending on the implementation, I could see that having rate limiting effects. There're only finitely many IDs so scaling sockpuppeting will saturate these IDs quickly but it's quite easy to spin up a new anonymous account. For example, I think the EU ID system has an upcoming way to create pseudo anonymous identifiers that can identify a user per website.
This presents the problem of governments being able to gatekeep speech which I am quite uncomfortable with but maybe there's some safeguard within the eIDAS proposal that makes this idea incorrect?
The internet is for the free exchange of ideas! Why would we want to limit it because some random gov somewhere is writing comments? Allow your citizens to think!
I'm assuming this is satire but I'm wondering why include names of seemingly random people? Why not leave it empty or make it signed by high level known executives.
The standard includes a hardware attestation path.
That’s the backdoor allowing the eventual takeover of your OS.
First people use passkeys, and they become standard.
Then they become required for important accounts for security.
Then the important accounts require the attestation bit.
At that point, you cannot run web browsers on open source operating systems.
This is all boring and predictable. It is exactly what they did with Android, and exactly the same organizations are pushing passkeys.
Note: If they had good intentions, the operating system would manage any attestation, and not allow websites to query for or require attestation support.
The attestation actually has nothing to do with the browser, only the holder of the passkey's key material. You can satisfy the attestation by having a passkey on your Android device and doing the normal Bluetooth flow with your Firefox browser on your Framework laptop. So this mechanism is totally useless for enacting this plan.
The operating system doesn't manage attestation because that's totally useless for the stated goal of the attestation system. Enterprises don't want their SaaS vendors to accept passkeys from some random employee's BitWarden, instead of the hardware keys they issued the employee. If the OS manages attestation and doesn't send anything to the relying party, then it doesn't solve anybody's problem at all.
It seems like it will only be a matter of time before consumer sites start requiring a patched OS with an attestation bit set in the key.
Also, as I understand it, sites can whitelist credential hardware.
If not, then the attestation is security theater. I (or an attacker on your machine), can just make a sw emulator of a hw attestation device, and use that to protect my choice of OS, (and skim your credentials).
If a whitelist exists, then my “hijack your OS” plan works: Require the builtin macos/windows/signed chrome on signed os password managers. That’s 90% of the market (and dropping) right now.
As I said, the attestation structurally does NOT attest to your OS or your browser that are displaying the website performing the authentication. It attests to the device that holds the passkey's key material, which is usually not your desktop computer.
Yes, but the attestation does not tell the RP anything about the browser. The whole point of the nightmare scenario above was for Google to sneak browser attestation in via passkey attestation. The browser being able to see the attestation doesn’t matter for that.
That's a matter of implementing an open standard. Google hasn't done anything to prevent open source browsers and OSes from implementing it, and nothing in the spec makes it difficult for Firefox/Linux specifically AFAICT.
An open standard that has attestation in it which allows sites to block all open implementations. FIDO Alliance spec writers have even threatened that apps like KeepPassXC could be blocked in the future because they allow you to export your keys.
The export is end to end encrypted, so you do not have ownership of the data, and the provider (Apple in this case) has full control over who you are allowed to export your keys to. (Notice how there are no options to move your keys to a self-hosted service.)
> The standard includes a hardware attestation path.
Yes, and iOS and Android's Passkey implementation does not support it, since doing so would be lying about a given credential being hardware-backend when it's actually not (due to being cloud-synced and often recoverable via some process).
Attestation is only for hardware authenticators, either dedicated ones like Yubikeys or non-synchronized Android WebAuthN credentials. (iOS only supports them in MDM contexts anymore, I believe.)
I think there's quite a bit of variance in model performance depending on the scaffold so comparisons are always a bit murky.
reply