Edit: obligatory explanation (thanks mods for squaring me away)…

What you see via the UI isn’t “all that exists”. Unlike Reddit, where everything is a black box, there are a lot more eyeballs who can see “under the hood”. Any instance admin, proper or rogue, gets a ton of information that users won’t normally see. The attached example demonstrates that while users will only see upvote/downvote tallies, admins can see who actually performed those actions.

Edit: To clarify, not just YOUR instance admin gets this info. This is ANY instance admin across the Fediverse.

  • dukk@programming.dev
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    1
    ·
    edit-2
    1 year ago

    That’s the point of a hash function. You have a public hash function, say SHA-256. It’s easy to check a username against it’s hash, but virtually impossible to reverse the hash back to the username.

    Edit: Instead of storing, say, eddie, we’d store 3b9d8298f1b5086d012618feebb2da1a394357c1dab7523443c9f6a743c4c84d. Then when the instance gets a Like from eddie, it hashes his username to get 3b9d8298f1b5086d012618feebb2da1a394357c1dab7523443c9f6a743c4c84d, realizes there’s a match, and doesn’t update the count.

    Note that when given 3b9d8298f1b5086d012618feebb2da1a394357c1dab7523443c9f6a743c4c84d, it would take millions of CPU years to compute the original username from it. Therefore, we can check for duplicates without actually checking the name itself (a similar method is used for checking passwords; Lemmy is open source, we know the hashing algorithm, but we can’t unhash user passwords, only check them).

    • quintium@lemmy.world
      cake
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 year ago

      While there is an enormous amount of possible passwords, there is only a limited (and quite small) amount of users. Couldn’t you just hash all the usernames one by one and map the hashes to the usernames? So you could still reverse engineer the usernames of those who voted on a post.

      Edit: Salting with the post id would make this attacking process harder, but still realistic. Probably the only real solution is to hide the votes table from federated instances, I’m not sure if that brings technical problems.

      • dukk@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        That was what I was implying, yes.

        Just hash each username and store it. Then just check the usernames hash to see if it matches.

        • quintium@lemmy.world
          cake
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          I was more comnenting that you could still reverse engineer the users who voted on a post

          • dukk@programming.dev
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            Actually, you’re not really wrong.

            All the more reason to give out limited data to all other instances. Why do these instances really need this data? Mastodon doesn’t need it, not quite sure why Lemmy does it.

            • quintium@lemmy.world
              cake
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 year ago

              Yeah I don’t understand why every instance can’t keep track of their own votes privately. Sure, voting manipulation is a thing, but it’s possible regardless.

              Honestly I really hope Lemmy does something to address this issue. Otherwise it’s kind of a dealbreaker for me.

      • sab@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        If anything, wouldn’t that make vote abuse even easier? Just send 100 upvotes with 100 random hashes.