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