[OutOfHere]

I think that malicious compliance all the way might have been the better option here. If a birth date is all that is needed, let the user enter a random one. If actual biometric verification is needed alongside, let the user also paste the code to a fake biometric validator that always returns valid.

It is the same philosophy as with an app that forcibly wants an invasive permission to the detriment of the user. Let the app have the permission while in a sandbox so it sees nothing.

[HybridStatAnim8]

Giving in in any capacity is unacceptable. The GrapheneOS foundation is based in Canada and is not obligated to record this information, so they wont. They have no reason to comply, be it malicious or otherwise.

[iugtmkbdfil834]

Agreed. This is one of those moments you might as well simply say no. For practical reasons too, your users do have options and tend to be the kind that will drop a distribution if it goes rogue.

[Polizeiposaune]

Asking the device owner for the user's birth date is precisely what the (California) law requires.

Biometrics are not required.

The concept appears to be that a parent or guardian could enter the birth date before turning the device over to a child.

Malicious compliance would be providing this age bracket API:

boolean is_user_over_18() { sleep (18 * 365.25 * 86400); return true; }

This is a real-time interface (as required by the law) that takes 18 years to complete. (Remember: "Real-time" does not mean "fast").

[ErroneousBosh]

> Asking the device owner for the user's birth date is precisely what the (California) law requires.

Why would anybody bother to implement that?

[OutOfHere]

The New York bill specifies a biometric requirement.

[WhyNotHugo]

You'd need to closely read the law and have a lawyer advise you, but a neat attempt might be to just ask for the date of birth, send that "in real time" to the App Store program, and then have that program simply discard it?

I don't think current iterations of the law require that this be sent off-device in any way.

[Polizeiposaune]

The second requirement of the California law is that there be an API available to all apps that returns the age band a user is in -- one of:

age < 13

age >= 13 && age < 16

age >= 16 && age < 18

age >= 18

A non-maliciously compliant implementation would need to retain a date of birth or equivalent until the user was over 18.

A maliciously compliant API could just wait 18 years after account creation before yielding an answer. (remember folks: "real time" does not mean "fast").

One of the oddities about the way the law is phrased is that it requires the age band information about the user be provided to "the developer" rather than to the application.

[WhyNotHugo]

> One of the oddities about the way the law is phrased is that it requires the age band information about the user be provided to "the developer" rather than to the application.

So, expose it via a Unix socket only accessible to the account named "developer"?

Only half joking.

[ErroneousBosh]

> The second requirement of the California law is that there be an API available to all apps that returns the age band a user is in -- one of:

Is anyone actually going to bother to do this though? Why would they?

[endofreach]

Agree. I didn't even think of that. Embarrassing. Your approach might have been the best option.