Age verification becomes more common. Australia, France, etc. introduce such laws to ban children below 15 years from social media platforms, to protect them.
Will these laws also be relevant to fediverse/lemmy specifically?
Personally I think these laws will focus on the big platforms at first (facebook/meta, youtube, discord, instagramm), which will force younger users with technical skills onto smaller and niche sites. Over time focus on this question will increase for the fediverse.
@[email protected] @[email protected] @[email protected] @[email protected]
They have to.
Otherwise, the wallet wouldn’t be able to verify whether the website is authorized to request age check (say, if a website asks the wallet’s API “Hey, please hand me the age checking token for the email [email protected] which you checked for me some time ago, they’re trying to access the gatekept sections of my website again”, the wallet needs to be sure that this website did request it previously and is not trying to exfiltrate someone else’s data), or the person wouldn’t be able to know which sites previously got their age checking data (eventually the users will have lots of websites where they previously had to check their age, and as part of GDPR’s “Right to be forgotten”, they’d need to be sure which ones they would want to revoke previously handled data).
The Age check authn+authz flow isn’t unidirectional (i.e only the wallet handing out the result of age check to a website). In a nutshell, it works this way (at least, it’s how I think, as a DevOps formerly accustomed with building APIs for websites, how it would work):
PHPIDcookie key-value pair which identifies asession_start()for PHP websites)Notice how both the website and the wallet need to communicate in order to establish the authorization needed for the user to access the website.
Yeah… Fully agree. And, sadly, this is becoming “normalcy”… ☹
It sounds like you are assuming that the wallet needs to re-validate each session and I don’t see why this would be needed. Each user account would just need to validate their age once then the website operator could store this in their database. If you’ve validated once you can be sure the user keeps being old enough.
@[email protected] @[email protected]
One scenario I can imagine of is an age check from someone who’s still legally a minor (I’m not sure whether the age check would check for minors faces, I can think of platforms intended to minors, e.g. schools and gaming, having to check if the user is not an adult, but it’s just my speculation), who tries again some time later when they’re legally into adulthood. If the token isn’t validated, they’d be stuck into a perpetual “minor” label.
Sure, a token could be not returned by the wallet if the age check fails (i.e. if the user is a minor), but the associated credentials (email, phone number, username) would be tied, database-wise, to a failed age check attempt, and those teens will one day become adults, and a system shouldn’t lock them out forever. Hence the need for re-validation.
Also, depending on how the token is built and stored, it may or may not have an expiration timeout. In computing systems, it’s common practice for tokens and sessions to have an expiration date (just like logged in sessions will eventually log out and ask for logging in again). It’s different from having to do the age check again: it’s simply about renewing the token that identifies someone as adult, someone who already did the age check, with the wallet simply returning the renewed token without demanding the user to go through the age check flow again.
Another scenario: imagine a relative’s phone being pick-pocketed/stolen by the kid during late night, and the kid somehow knows the relative’s password/pin/pattern or even uses the relative’s finger to the biometric sensor to unlock it, all during the relative’s sleep. Then they head into the “forbidden fruit website”, which happens to be accessed by the relative as well, so it means that the website is already authorized with the relative’s wallet. I can see govs foreseeing this situation and requiring that websites always re-validate the authorization before effectively letting the user into the website’s “adult” content.
I believe that it’s specified in the architectural reference framework that it has to re-validate every session, to ensure that the token hasn’t been revoked. I’d be happy to be corrected, though!
@[email protected] @[email protected] @[email protected]
Exactly! This, too. I forgot to mention it in the reply I just sent to SirHaxalot. And given the GDPR “Right to be forgotten”, an authorization must be revocable, so this means an authorization must be re-validated, even if this doesn’t necessarily mean having to go through the age check flow all over again.