YSK: Your Lemmy activities (e.g. downvotes) are far from private - eviltoast

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.

  • Irv@midwest.socialEnglish
    7·
    1 year ago

    There might be possible technical solutions to this using hashing. Hashing is like encryption in that the original cannot be extracted, but the hashed result is unique.

    For example, a solution would be to have a VOTES table with an indexed column that is a hash of a combination of the user ID, post ID, (and perhaps another “salt”, not sure). When a vote is made, the VOTES table is checked that the record (vote) does not already exist, gets an insert, and then a COUNTER is triggered for the actual vote count. (COUNTER is a db command that simply updates a counter). The hash would prevent multiple votes from the same user (as the salted hash is unique), and it would also prevent identifying who the user is from the table.

    • orangeboats@lemmy.worldEnglish
      31·
      1 year ago

      Yeah, I admit that sounds reasonable.

      Although that still leaves the question of “is it scalable/performant?” on the table… Lemmy already suffers a lot from server overloading, adding the overhead of cryptographic hashing (anything less than that is not going to ensure uniqueness/true anonymity) to each act of voting surely isn’t going to help.

    • Irv@midwest.socialEnglish
      1·
      1 year ago

      I really don’t even think the votes table would need to itself be federated; it could just be on the user’s instance. Upvote/downvote would be a call, but it should really only require the post or comment ID and voter instance. If an instance spams votes, those upvotes/downvotes could be deleted and the instance defederated

    • quintium@lemmy.worldEnglish
      1·
      1 year ago

      Still you can easily and quickly check if a user has voted on a particular post. While your method makes the tracking process quite a bit slower, it doesn’t make it unrealistic. There just aren’t that many users and posts as is the case with passwords. Still 100% better than the current approach, I hope this gets implemented.