• [email protected]A
    link
    fedilink
    arrow-up
    17
    ·
    9 hours ago

    So I’ve just tested something and it seems lemmy devs haven’t set a default expiry time for the login jwt tokens, or it’s something stupidly long.
    Logging out clears the cookie from your browser, but not in the server database, which isn’t atypical and mostly fine, or at least would be fine if the server’s expired sooner than later.

    Just to be sure, I just tested that a password change does indeed purge those from the database, so that works at least.

    I’ll try and see what we can implement locally (hopefully without breaking everything) to purge these more frequently.
    Removing these faster also means forcing people to re-enter their credentials more frequently.
    I can’t find anywhere to configure that, neither in the instance settings nor in user settings, which probably means it’s whatever lemmy devs set as default.

    Anyway, thanks for the question, because it’s dumber than I thought.

    • vaguerant@fedia.io
      link
      fedilink
      arrow-up
      11
      ·
      8 hours ago

      Would it be possible to reset the purge timer for individual users based on activity? e.g. A user who comments or up/downvotes something gets their purge timer reset, so that active users never get purged unless they change their password or similar. Not sure how easy it is to tie activity data to a login token, I have no idea how Lemmy or anything else works.

      • [email protected]A
        link
        fedilink
        arrow-up
        6
        ·
        8 hours ago

        Lemmy could keep the last time each token was used (every request uses it), but then it’d do a lot of writes and likely be a somewhat poor choice for performance reasons.
        Some sites display your other current logins with an option to remove whichever as you see fit, which seems more elegant.
        Putting the user in control seems more ideal than guessing.

      • [email protected]A
        link
        fedilink
        arrow-up
        7
        ·
        8 hours ago

        Thanks for chiming in.
        Yea, in itself that’s nice enough, but that means in some fringe cases, your IP info might be in the database longer than I thought, or worse more often than I thought.
        In your case, you current login tokens are from forever ago, but there’s also very few of them, so the database has your IP address from 2 points in time in the last year.

        In my case, I login multiple times a day (Firefox mobile cookie bug + sometimes testing things in private windows) and so the database had my phones IP info at several hundred points in time, which isn’t too great. (Until I changed my password)

        Whatever IP you had a few months ago is mostly moot, whereas a detailed history of my IP over the last year is more info than I care for.

        Ideally, I think it’s something users should have control over. Like some sites where you can see your other current logins and revoke them.
        Or maybe have the option to set your max token age in your settings.
        As far as I know, these aren’t implemented in lemmy.

        As is, manually forcing the expiry on people without their consent isn’t too great because some apps might break until they log back in, which might not be handled gracefully in all apps, as well as be annoying to people like you.
        In your case, since you’ve logged in so few times, I’d argue the token not expiring is maybe more private for you because your IP info is so out of date as to be mostly useless.
        In my case, the tokens not expiring meant every new login painted a very detailed history.

        I’ve yet to figure something that would make sense for everyone.

        • “Ideally, I think it’s something users should have control over. Like some sites where you can see your other current logins and revoke them. Or maybe have the option to set your max token age in your settings. As far as I know, these aren’t implemented in lemmy.”

          1,000% this

          Lemmy should add it :)

  • [email protected]A
    link
    fedilink
    arrow-up
    16
    ·
    10 hours ago

    Most of it should be covered in here:
    https://sh.itjust.works/legal

    Most of the content is public by nature, things like posts, comments, modlog, etc. are kept basically forever. Your settings and stuff in your profile is also stored, obviously.
    Anyway, I’d imagine you wanna know about the stuff other than content and its federation.

    There would be mostly 2 things: server logs and the login tokens database table.
    Lemmy logs are a bit verbose and our current config limits the size of the files rather than its age.
    The legal page mentions 30 days, but with the current config it’s functionally much less than that. ie: Right now that file last wrapped less than a day ago.
    If we were troubleshooting something specific, we might increase that slightly, but otherwise there is little point in keeping those, let alone a month.

    The logins table contains your login tokens, which need to be kept until you log out or they expire (although TBH, I haven’t checked what the lemmy devs have set for default expiry of these).
    They’re also purged if you delete your account or you get site banned, and, hopefully, when you reset your password (which I’ll be testing after this comment just to make sure lol).
    The same table also holds the timestamp at which you logged in, your IP at the time of login (which might not be your current IP), and your browser’s user agent at the time of login.
    These aren’t easily accessible and require database access, which currently means only either TheDude or me.

    PS: We have so far not received any law enforcement request for user info, logs or whatnot.

    • sugar_in_your_tea
      link
      fedilink
      arrow-up
      6
      ·
      8 hours ago

      We have so far not received any law enforcement request for user info, logs or whatnot.

      Good, they haven’t caught me yet. :)

      Just wanted to say thank you for everything you do. And TheDude of course.