skyline2Systemd preparing to comply with age verification laws
Dæmon S.@[email protected] @[email protected]
Brazilian here. I'm neither a lawyer nor a specialist, just someone who has read the Portuguese text from the Brazilian flavor of the ongoing worldwide age check set of laws.
I must note that the Brazilian age check law (Lei 15.211/2025) specifies "vedada a autodeclaração" (English: "self-declaring is forbidden"). This means that this kind of implementation, where age or birthday is an user input, wouldn't be compliant to Lei 15.211/2025, because it requires the age information to be assessed independently from the user whose age is being assessed. This means face biometrics, government-issued ID (in our case, CPF, CNH, Passaporte and similar) or "behaviorial analysis"... Anything but a "yes I'm 18" or "I was born in day month year", for those are self-declared and the Law says it's "not enough".
Someone should warn the systemd maintainers of this "Brazilian jabuticaba".
(Cross posting this reply of mine because the post was cross posted to two different Lemmy instances)
Brazilian here. I'm neither a lawyer nor a specialist, just someone who has read the Portuguese text from the Brazilian flavor of the ongoing worldwide age check set of laws.
I must note that the Brazilian age check law (Lei 15.211/2025) specifies "vedada a autodeclaração" (English: "self-declaring is forbidden"). This means that this kind of implementation, where age or birthday is an user input, wouldn't be compliant to Lei 15.211/2025, because it requires the age information to be assessed independently from the user whose age is being assessed. This means face biometrics, government-issued ID (in our case, CPF, CNH, Passaporte and similar) or "behaviorial analysis"... Anything but a "yes I'm 18" or "I was born in day month year", for those are self-declared and the Law says it's "not enough".
Someone should warn the systemd maintainers of this "Brazilian jabuticaba".
(Cross posting this reply of mine because the post was cross posted to two different Lemmy instances)
I believe this only stores that information. It’s not a system of declaring an age
@[email protected] @[email protected]
The git PR specifically mentions a
Thinking of age checking as some kind of OAuth flow, one would ideally store the authz token from whatever age checking provider validated the user's age, instead of some plain data which, depending on the provider, wouldn't even be handed to the application.
I can sort of imagine the following, hypothetical flow:
1. Human tries to access the system for the first time
2. System asks for human consent to proceed with age checking
3. Human (is compelled to) accept going through age checking shenanigans
4. System redirects human to 3rd-party age checking provider interface (e.g. Persona).
5. Provider proceeds with whatever means necessary for the human to upload ID and/or selfie, who does whatever is required from them by the provider interface.
6. In case of IDs, the provider talks with gov databases (e.g. Receita Federal do Brasil for CPF "Cadastro de Pessoa Física") in order to attest the validity of the ID. In case of selfie, provider communicates with a facial recognition model/algorithm/platform.
7. Provider gets the information necessary for age-bracketing, appends it to their own DB with a signing hash, then returns the digest of said hash as a token to the system.
8. System receives the authorization payload and confirms with the provider whether it's a valid token.
9. Provider replies positively, perhaps with some kind of checksum, regarding validity of the token.
10. System stores the token to hand it to whatever subsystem (for OSes, a software; for online platforms such as social media, a module/route) requesting age info.
11. Subsystem allows or denies human access.
Some age checking models (such as EU) seems to be doing a similar thing to what I hypothesized above: the EU Digital Wallet returns a token, instead of PII. A token that can be checked against the Digital Wallet API for validity (theoretically) without disclosing who the user is (in practice, it'd be another, pretty reliable piece of traceable data despite any "anonymity")
I'm not sure whether a similar thing will be implemented here in Brazil (we got an official gov app, gov.br, which can already be used for "social log-in" by 3rd-party platforms, but I don't know whether it's ready for age check provisioning).
As far as I know Brazil and Brazilians, it's highly likely we'd end up with dependencies on Microsoft or Google services because Brazilian gov can't help but handing its own sovereignty to US tech corps, which adds to the dystopia.
I must make something very clear: I'm far from agreeing with this dystopia, I deeply despise this whole "age check" thing going on worldwide; I'm just thinking as a DevOps would.
The git PR specifically mentions a
birthDate, a data struct that feels like it could easily be tampered with (therefore, far from "confiável" (trustworthy) as explicitly required by "deverão ser adotados mecanismos confiáveis de verificação de idade" ("trustworthy age checking mechanisms must be adopted")).Thinking of age checking as some kind of OAuth flow, one would ideally store the authz token from whatever age checking provider validated the user's age, instead of some plain data which, depending on the provider, wouldn't even be handed to the application.
I can sort of imagine the following, hypothetical flow:
1. Human tries to access the system for the first time
2. System asks for human consent to proceed with age checking
3. Human (is compelled to) accept going through age checking shenanigans
4. System redirects human to 3rd-party age checking provider interface (e.g. Persona).
5. Provider proceeds with whatever means necessary for the human to upload ID and/or selfie, who does whatever is required from them by the provider interface.
6. In case of IDs, the provider talks with gov databases (e.g. Receita Federal do Brasil for CPF "Cadastro de Pessoa Física") in order to attest the validity of the ID. In case of selfie, provider communicates with a facial recognition model/algorithm/platform.
7. Provider gets the information necessary for age-bracketing, appends it to their own DB with a signing hash, then returns the digest of said hash as a token to the system.
8. System receives the authorization payload and confirms with the provider whether it's a valid token.
9. Provider replies positively, perhaps with some kind of checksum, regarding validity of the token.
10. System stores the token to hand it to whatever subsystem (for OSes, a software; for online platforms such as social media, a module/route) requesting age info.
11. Subsystem allows or denies human access.
Some age checking models (such as EU) seems to be doing a similar thing to what I hypothesized above: the EU Digital Wallet returns a token, instead of PII. A token that can be checked against the Digital Wallet API for validity (theoretically) without disclosing who the user is (in practice, it'd be another, pretty reliable piece of traceable data despite any "anonymity")
I'm not sure whether a similar thing will be implemented here in Brazil (we got an official gov app, gov.br, which can already be used for "social log-in" by 3rd-party platforms, but I don't know whether it's ready for age check provisioning).
As far as I know Brazil and Brazilians, it's highly likely we'd end up with dependencies on Microsoft or Google services because Brazilian gov can't help but handing its own sovereignty to US tech corps, which adds to the dystopia.
I must make something very clear: I'm far from agreeing with this dystopia, I deeply despise this whole "age check" thing going on worldwide; I'm just thinking as a DevOps would.
Wait until Iran nukes the US and the financial systems collapses. Having bajillions of dollars will not help when dollars are worth nothing.