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.
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.
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").
Why would anybody bother to implement that?
I don't think current iterations of the law require that this be sent off-device in any way.
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.
Is anyone actually going to bother to do this though? Why would they?
So, expose it via a Unix socket only accessible to the account named "developer"?
Only half joking.