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 6 days ago | parent | next [-]

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 6 days ago | parent | next [-]

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.

▲

mmooss 6 days ago | parent | prev [-]

[flagged]

	▲	snackbroken 6 days ago \| parent \| next [-]
		People who live in authoritarian states like North Korea or California can (and arguably should) ignore the fact that GrapheneOS is illegal where they live and use it anyway.
	▲	applfanboysbgon 6 days ago \| parent \| prev \| next [-]
		If you want a privacy-violating OS, there are already two big options on the market. A secure OS for people who do not live in authoritarian surveillance states offers a benefit to some people, even if not all people. A third privacy-violating OS offers no value to anyone anywhere in the world.
	▲	epolanski 6 days ago \| parent \| prev [-]
		As they stated "If GrapheneOS devices can't be sold in a region due to their regulations, so be it."

▲

Polizeiposaune 6 days ago | parent | prev | next [-]

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 6 days ago \| parent \| next [-]
		> 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 6 days ago \| parent \| prev [-]
		The New York bill specifies a biometric requirement.

▲

WhyNotHugo 6 days ago | parent | prev | next [-]

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 6 days ago | parent [-]

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 5 days ago \| parent \| next [-]
		> 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 6 days ago \| parent \| prev [-]
		> 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 6 days ago | parent | prev [-]

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