65
Will Lemmy/ the fediverse become age verified platforms? (lemy.lol)
submitted 7 months ago by to c/asklemmy@lemmy.ml
40 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] 3 points 7 months ago (5 children)

Depends if the wallet records data of what site required verification. Any amount of privacy being eroded is bad.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [โ€“] 4 points 7 months ago (4 children)

    @warm@kbin.earth @Ladislawgrowlo@lemy.lol @asklemmy@lemmy.ml @SirHaxalot@nord.pub

    Depends if the wallet records data of what site required verification.

    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 foo@bar.baz 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):

    1. User requests to access sensitive ("adult") content from a website.
    2. Website requests the user to check their age.
    3. User agrees to proceed with age check.
    4. Website redirects the user to the governmental wallet
    5. The wallet asks for user authentication and/or 2FA ("open the gov app" or something)
    6. After authentication and/or 2FA flow within the gov app, the gov app redirects the user to an OAuth endpoint within the original website, alongside a unique token
    7. The Oauth endpoint will be invoked by user's browser's request, then the website will check the wallet API if this token is valid.
    8. Gov wallet will check if this website previously went through a flow, then will check the requested token and answer "yes" to the website's endpoint.
    9. Website redirects the user to the walled-garden they requested initially, storing the token both server-side and, indirectly, in the client-side via the framework session id (things such as PHPID cookie key-value pair which identifies a session_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.

    Any amount of privacy being eroded is bad.

    Yeah... Fully agree. And, sadly, this is becoming "normalcy"... โ˜น

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [โ€“] 2 points 7 months ago (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [โ€“] 1 point 7 months ago (1 child)

    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!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [โ€“] 1 point 7 months ago

    @SirHaxalot@nord.pub @asklemmy@lemmy.ml

    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.

  • permalink
  • fedilink
  • source
  • parent