The California law only stipulates that there's an "accessible interface at account setup" to set the birthday or age at account setup, and an interface to query the age bracket. Plus the crap for "application stores"
I don't think it's a very well thought-out law. But realistically this will end up as setting some env variable for your docker containers to assure them that you are 99 years old. And yes, maybe transmitting a header to docker hub that you are 99 years old. Probably configured via an env variable for the docker cli to use. It's stupid, but nothing a couple env variables wouldn't comply with
The real issue is when the law inevitably gets expanded to get some real teeth, and all the easy workarounds stop being legal
This is a neat attack (in that it is obvious and a big flaw but also it makes sense that the lawmakers wouldn’t have thought of it), but it would only affect users who have an age-bucket transition while your application is running, right?
Edit: as folks have pointed out, the attacking application doesn’t actually have to be running while the age-transition takes place. The attacker just has to have logs from before and after the age transition, and then they can narrow the birth-date down.
Not necessarily, depending on how the application is logging it just means the resolution to which you know a birth date is limited by how often the application is run. If i check my email every morning at 8am, and my email app logs my "age bucket", then it can know to a resolution of one day. If i only check my email on Monday mornings, it knows to a resolution of one week, etc...
The size of the age bracket also puts practical limitations on it. There is only one mandated bracket for everyone who's at least 18, preventing that attack on anyone who starts using your software after their 18th birthday. And if a 13 year old signs up it takes three years for you to observe the switch to the >=16,<18 bucket
> And if a 13 year old signs up it takes three years for you to observe the switch to the >=16,<18 bucket
I think this is the big vulnerability in the scheme. This information is easy to track and log, so it is basically equivalent in the giving away the DOB of everybody who is currently under 18 (at least, everybody who uses the system as intended). In the long run that’s everybody.
We could have a discussion about whether or not it would be fine for services to know every user’s DOB, but it is clearly giving away more information than the law intended.
> There is only one mandated bracket for everyone who's at least 18, preventing that attack on anyone who starts using your software after their 18th birthday.
I don’t think that fully recognizes the size of the problem, “using your software” is fuzzy. Companies get bought, identities get correlated, ad services collect and log more information than needed. I think it is better to assume the attacker will have logs of these queries from the start date of a person’s first account.
Then you store the user age every time it's run and check for changes on start. Maybe that only gives you a 7 day range for birthdays, but you can narrow that over time and it's still good enough for targeting.
I agree, sorry, I think my original comment was a little imprecise. My point was that the app can get the “exact” age only for users who undergo an age-bucket transition in an era that the app has logs for.
I mean, the app can query on a weekly basis, and then if you go from “under 18” to “over 18” it knows the week that you were born in. But, if the user was already an adult when the logging started, there isn’t a transition to go off.
The UI can be implemented using the user's date of birth, but it can also be implemented by selecting an age bracket and then all it tells you is that the user changed the age bracket setting.
is there any mention of granularity? so if the user sets their age bracket, then there's no DoB stored. if the user is old enough to fall into some other age bracket they can set that if they want. (and then somehow making this a bit more data driven - ie "verifying" - is a different matter altogether.)
IIRC the age buckets were defined in the California law. They were something along the lines of age ranges that would intuitively map to adults, teenagers, and kids, I forget the exact borders.
I think the intent was for the OS to know the user age, but only provide an age range, so it could automatically upgrade people as they aged (but I could be wrong about that).
this is not going to just be a little file stored locally. The law says the operating system PROVIDER sends that signal to app devs.
Think like they do and linux doesn't exist. You create an account for your phone already, whether Google or Apple. Just add the bday is a required field. Now it's across all your devices tied to that account. It cannot be changed once set. The idea is that parents buy the devices for their kids and will be asked to set the age for the child.
Linux distros have no way to comply with this
Yeah, I think the idea of the law is fine. If you imagine "Operating System" to mean "things like Windows and iOS, or Desktop install of Fedora", "Application Store" to mean "Microsoft Store or AppStore or the like" and "Application" to mean "Word and Doom and stuff like that" then it's fine. Especially if you keep in mind that there isn't any actual verification of the age, it's simply set by whoever sets up the account
Most of the issues only arise because in the bill "operating system", "covered application store" and "application"/"developer" have very loose definitions that match lots of things where the law doesn't make sense.
Laws get made by whomever takes Gavin to the most dinners at the French Laundry. Don’t like this law? Good luck - reservations are booked out 6 months in advance.
I don't think it's a very well thought-out law. But realistically this will end up as setting some env variable for your docker containers to assure them that you are 99 years old. And yes, maybe transmitting a header to docker hub that you are 99 years old. Probably configured via an env variable for the docker cli to use. It's stupid, but nothing a couple env variables wouldn't comply with
The real issue is when the law inevitably gets expanded to get some real teeth, and all the easy workarounds stop being legal