@ominouslemon@sh.itjust.works @linux@lemmy.ml
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:
- Human tries to access the system for the first time
- System asks for human consent to proceed with age checking
- Human (is compelled to) accept going through age checking shenanigans
- System redirects human to 3rd-party age checking provider interface (e.g. Persona).
- 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.
- 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.
- 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.
- System receives the authorization payload and confirms with the provider whether it’s a valid token.
- Provider replies positively, perhaps with some kind of checksum, regarding validity of the token.
- 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.
- 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.
@1dalm@lemmy.today @linux@lemmy.ml
The country I exist in (Brazil) passed an age verification law “Lei 15.211/2025” which, to a certain extent, is even more dystopian than Californian one. Because, at least, the Californian “allows” self-declared age, while Brazilian don’t. This means systems must employ mechanisms such as ID’ing, age estimation by selfie or behavioral analysis.
When UK passed their law, threatening and, to certain extent, effectively sanctioning even even non-UK “disobedient”, something happened: many sites and platforms started to geoblock UK. Many Fediverse instances geoblocked UK.
Brazil has a similar history of legal outreach, we had court decisions trying to enforce and rule over non-Brazilians. Something similar is expected to happen when it comes to this age verification law. So I’d expect a similar widespread reaction of sites and platforms geoblocking Brazil.
In fact, it’s already happening: in mere two days since the law became effective, MidnightBSD geoblocked Brazil, Arch Linux 32-bits (not the mainstream Arch Linux) geoblocked Brazil, and others are expected to follow, both distros and websites as well. Including the Fediverse.
This kind of law will hardly stay in the countries and USian states where they’ve been implemented. It’ll spread, because the narrative it’s wrapped with is too alluring and compelling (from emotional appealing “Think about the children!?” all the way to the strawman “If you disagree with age checking laws, you’re literally a pdf file”). So expect more countries embracing this dystopia. This means fewer and fewer places where it’s not a thing. It reeks of a coordinated agenda, especially because it achieves similar things that intended by projects such as Chat Control, PIPA/SOPA, among many other previous authoritarian attempts. The authoritarian found the correct recipe: wrap 1984 in a cute “children protection” wrapping, rinse and repeat.
Therefore, some Fediverse instances, especially those sitting under the hurricane’s eye (e.g. Lemmy Brasil) may end up implementing age checking, or stopping altogether if they can’t afford the additional costs of age checking (it won’t be a free thing for platforms to do; a trivial cost for giants such as Meta, Google and Microsoft, but unfeasible for, say, Fediverse instances and FOSS projects).
Now, regarding the “kid friendly” limitation: if the Web gets limited to “non-adult content”… what’s “adult content” to begin with? Is it just porn, or it may end up covering several non-pornographic things?
It turns out, and here I’m risking getting too off-topic, many things would end up beneath this purposefully vague terminology “adult content”, content from many vulnerable groups: LGBTQIA+ (check out what happened during the recent itch.io and Steam crusade against “adult games”), women, pagans/occultists, political dissidents and whistleblowers, among others. This is what age verification laws are about: silencing everything deemed non-normative.