[bee_rider]

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.

[bigfishrunning]

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

[wongarsu]

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

[bee_rider]

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

[AlotOfReading]

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.

[bee_rider]

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.

[gzread]

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.

[LtWorf]

Age brackets cannot update themselves.

[pas]

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

[bee_rider]

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