It seems all at once, everywhere that many groups that have a vested interest in forcing precedent and compliance of non-anonymous access across the computer world. It smacks of something less-than-organic.
It seems all at once, everywhere that many groups that have a vested interest in forcing precedent and compliance of non-anonymous access across the computer world. It smacks of something less-than-organic.
Reading the first analysis PDF:
> This bill, sponsored by the International Centre for Missing and Exploited Children and Children Now, seeks to require device and operating systems manufacturers to develop an age assurance signal that will be sent to application developers informing them of the age-bracket of the user who is downloading their application or entering their website. Depending on the age range of the user, a parent or guardian will have to consent prior to the user being allowed access to the platform. The bill presents a potentially elegant solution to a vexing problem underpinning many efforts to protect children online. However, there are several details to be worked out on the bill to ensure technical feasibility and that it strikes the appropriate balance between parental control and the autonomy of children, particularly older teens. The bill is supported by several parents’ organizations, including Parents for School Options, Protect our Kids, and Parents Support for Online Learning. In addition, the TransLatin Coalition and The Source LGBT+ Center are in support. The bill is opposed by Oakland Privacy, TechNet, and Chamber of Progress.
1. When you set up your account and it asks for your birthdate, make up any date you want that is at least far enough in the past to indicate an age older that what any site you might use that checks age requires.
2. Access things the way you've always done. All that has changed is that things that care about age checks find out you claim to be old enough.
The only people it actually materially affects on your new computer are people who cannot set up their own accounts, such as children if you have set up permissions so they have to get you to make their accounts.
Then if you want you can enter a birthdate that gives an age that says non-adult, so sites that check age will block them.
From a privacy and anonymity perspective this is essentially equivalent to sites that ask "Are you 18+?" and let you in if you click "yes" and block you if you click "no". It is just doing the asking locally and caching the result.
This puts the responsibility back on parents to do the bare minimum required in moderating their child’s activities.
Possibly it could be further mandated that the OS collect relevant rating information for each account and provide APIs with which browsers and other software could implement filtering.
And possibly it could be further mandated that web browsers adopt support for this filtering standard.
And if you want a really crazy idea you could pass a law mandating that parents configure parental controls on devices of children under (say) 12 and attach civil penalties for repeated failure to do so.
There's never any need for information about the user to be sent off to third parties, nor should we adopt schemes that will inevitably provide ammo for those advocating attested digital platforms.
Sending all the "bad" data to the client and hoping the client does the right thing outs a lot of complexity on the client. A lot easier to know things are working if the bad data doesn't ever get sent to the client - it can't display what it didn't get.
When you click on a search result, you load a new page on a different website. The new page would once again come with a header indicating the content rating. This header would be attached to all pages by law. It would be sent every time you load any page.
Assuming that the actual problem here is the difficulty of implementing reliable content filtering (ala parental controls) then the minimally invasive solution is to institute an open standard that enables any piece of software to easily implement the desired functionality. You can then further pass legislation requiring (for example) that certain classes of website (ex social media) include an indication of this as part of the header.
Concretely, an example header might look like "X-Content-Filter: 13,social-media". If it were legally mandated that all websites send such it would become trivially easy to implement filtering on device since you could simply block any site that failed to send it.
> A lot easier to know things are working if ...
Which is followed by wanting an attested OS (to make sure the value is reliably reported), followed by a process for a third party to verify a government issued ID (since the user might have lied), followed by ...
It's entirely the wrong mentality. It isn't necessary for solving the actual problem, it mandates the leaking of personal data, and it opens an entire can of worms regarding verification of reported fact.
If you imagine a world where you have a header, Accepts-Adult-Content, which takes a boolean value: you essentially have three possibilities: ?0, ?1, and absent.
How useful of a tracking signal those three options provide depends on what else is being sent —
For example, if someone is stuffing a huge amount of fingerprinting data into the User-Agent string, then this header probably doesn’t actually change anything of the posture.
As another example, if you’re in a regular browser with much of the UA string frozen, and ignoring all other headers for now, then it depends on how likely the users with that UA string to have each option: if all users of that browser always send ?0 (if they indicate themselves to be a minor) or ?1 (if they indicate themselves to be an adult or decline to indicate anything), then a request with that UA and it absent is significantly more noteworthy — because the browser wouldn’t send it — and more likely to be meaningful fingerprinting surface.
That said, adding any of this as passive fingerprinting surface seems like an idea unlikely to be worthwhile.
If you want even a weak signal, it would be much better to require user interaction for it.
https://leginfo.legislature.ca.gov/faces/billTextClient.xhtm...
Your toaster is not impacted. You’re turning a law that, yes, has some open questions around implementation, into a way bigger scare and conspiracy.
> operating system provider, as defined, to provide an accessible interface at account setup that requires an account holder, as defined, to indicate the birth date, age, or both, of the user of that device for the purpose of providing a signal regarding the user’s age bracket to applications available in a covered application store and to provide a developer, as defined, who has requested a signal with respect to a particular user with a digital signal via a reasonably consistent real-time application programming interface regarding whether a user is in any of several age brackets, as prescribed. The bill would require a developer to request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.
Let’s be honest here. 99% of general purpose computing devices targeted at consumers make an “account” when you setup for the first time. Even Linux if just to name a home directory. It’s pretty obvious what an account is. Especially when it only applies to bundled app stores. What App Store has no account anyways?
It allows the operating system to define the interface. No patent or proprietary system. No surveillance. The law says user interface. Not graphical interface. Do with that as you will. A OS producer who has an App Store probably has a graphical interface, but if not they surely figured out how to interface with users already.
It actually requires operating systems and developers to not abuse this data or use it for anticompetitive purposes.
There is no attestation. It’s entirely self reported and unverified.
Their definition of "app store" is a mile wide: "(e) (1) “Covered application store” means a publicly available internet website, software application, online service, or platform that distributes and facilitates the download of applications from third-party developers to users of a computer, a mobile device, or any other general purpose computing that can access a covered application store or can download an application."
Grats, github is an appstore. apt-get is an app store. You posting software on your own website is an app store.
Apt… yes is an App Store run by an operating system organization (Debian org). That feels pretty unsurprising. Debian’s parent organization (headquartered in the US) probably needs to comply with this.
And that right there is exactly the fucking problem. A zero profit collective “store” that publishes zero profit hobbyist “apps” is now going to have to invest in some kind of harebrained compliance scheme that will only grow from here.
In a couple of years is my “app” in Debian’s store going to require some goddamn TPS report and certification to tell California that everything is above board? It’s incredibly likely! By itself this law does nothing but lay the groundwork for regulation of “apps”, which by itself might be acceptable, but including FOSS distribution channels and hobby apps in the scope of this law is nothing short of evil. It’s laying the groundwork for a frontal assault on FOSS, and if you don’t see that then I don’t know what to tell you.
My guess is that Linux wasn’t extensively considered in the writing of this law, but when the next stage comes along and people start complaining, legislators will shrug and say “oh well, they need to comply”—and lobbyists for the big 3 proprietary software firms will back that position up. This is setting up a killshot for consumer Linux.
From the bill:
> (3) (A) Except as provided in subparagraph (B), a developer shall treat a signal received pursuant to this title as the primary indicator of a user’s age range for purposes of determining the user’s age.
> (B) If a developer has internal clear and convincing information that a user’s age is different than the age indicated by a signal received pursuant to this title, the developer shall use that information as the primary indicator of the user’s age.
It's not enough to just accept the age signal, you can still be liable if you have reason to believe someone is underage based on other information.
The cheapest and easiest way to minimize that liability is with face scans and ID checks. That way you, as a developer, know that your users won't bankrupt you.
If websites accept this as age verification it could provide a very easy way to bypass it.
In fact, looking at it again, point B specifically says if the "developer" has information rather than the "system" has information. So really sounds like if the developer isn't collecting logs that they can access themselves this wouldn't apply to them.
I think you’ve nailed it here. How many of these people campaigned on this issue? Where were the grassroots to push this? Where did this even come from?
Somebody, somewhere - with a heck of a lot of money - wants to see this happen. And I don’t think they have good intentions with it.
Of course they are copying the play everywhere.
TLDR: Evil people be doxxed internally not everyone.
If server side, you already have the heavyweight stuff going on, and yes there is no need to do all the bypassable shenanigans.
These days the name "LLM" refers more to the architecture & usage patterns than it does to the size of model (though to be fair, even the "tiny" LLMs are huge compared to any models from 10+ years ago, so it's all relative).
And when the idiots do, the proposed system locks the fire door for them. That's just dangerous. We'd want them with bunch of confusing options and better illuminated de-escalation paths.