18
Fundamental problems with private voting Question Features poll (piefed.social)
submitted 1 year ago by to c/piefed_meta@piefed.social
48 comments fedilink hide all child comments
 

Several months ago I have PieFed users the option to vote privately, where an alt/sockpuppet account automatically votes on their behalf. Since then I've been watching to see how it turned out.

  • Finding bigots who upvote transphobia (etc) is harder. To work around this, piefed shares the real vote with trusted instances, BUT:
  • trusted instances Announce votes using the primary to untrusted instances, so the privacy doesn't work most of the time
  • Maintaining a list of trusted instances is a pain in the ass.
  • People always ask why their instance isn't trusted
  • Figuring out who the primary account is, could be quite easy if you have technical skills and a little knowledge of how ActivityPub works. It's not truly 100% private.

Plus, cases of admins/mods abusing their knowledge of who downvoted them have been very rare, lately. This removes most of the reason for private voting in the first place.

I'm starting to feel like private voting is not working and can't really be made to work. Thoughts?

63% Get rid of private voting
14% Keep private voting and make no changes
23% Keep private voting and try harder to make it work
35 votes - ended 1 year ago
you are viewing a single comment's thread
view the rest of the comments
[–] 5 points 1 year ago (7 children)

So, there has been quite a bit of discussion on this in this thread and there was also a ton of it on matrix:

From everything I have seen, I am convinced that votes within the Activitypub spec can't be private. Anonymizing them either breaks the spec, become simple for a technical user to de-anonymize, or end up really spammy and would just be ignored/defederated by other instances.

So...just don't federate them. If a user really doesn't want their vote to be public, give them the option to not have their votes federate. It would still influence content curation and sorting on their local instance, but it wouldn't broadcast their votes to anybody that knows how to query an api. It seems like kbin (RIP) had a similar idea in the past, and scrolling through that thread is what gave me the idea to bring it up here.

Along these lines, lemmy is planning on introducing instance-wide settings to allow/block remote votes. So, something like selectively federating votes is already coming for the fediverse.

  • permalink
  • fedilink
  • source
  • hideshow 7 child comments
    •
  • [–] 1 point 1 year ago

    The entire point, as far as I see it, isn't that this is not meant to be an absolute anonymous function, but that it provides a layer of plausible deniability if my account was doxxed years down the road. I am profoundly uncomfortable with how activitypub makes these things public not just to admins but to anyone on the network, and there are already website popping up to display that activity to anyone. In the future, if my account is doxxed, there's a world of difference between someone being able to query my user activity on a search form, versus needing to forensically link a bunch of anonymized database entries.

  • permalink
  • fedilink
  • source
  • parent
  • [–] [S] 3 points 1 year ago* (5 children)

    I'll share your elaboration of this idea here because it deserves a wider audience:

    For people who turn on private voting:

    you click the vote button one time to vote locally, then click it again to federate that vote out if you are comfortable with that vote being public

    Currently, the second click removes the previously cast vote. I guess that would continue to be how it works for those who didn't turn on this feature.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 3 points 1 year ago (4 children)

    how would someone remove their vote in that case, without first making it public?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 2 points 1 year ago* (2 children)

    Gah. I didn't think of that.

    Maybe, by casting a vote in the other direction?

    I guess if it public for a second and then immediately removed that's not the end of the world.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 1 year ago (1 child)

    Yeah, I think that this paradigm would require a UI change for voting. I can imagine two different scenarios:

    • Like mentioned above, clicking an vote button a second time triggers federation. This would likely require a separate button on the voting bar dedicated to removing your vote.
    • Another option would be to have two upvote buttons/two downvote buttons; a local vote button and a federated vote button. Clicking the federated vote button also votes locally, but not vice versa.

    I think that apps are unlikely to implement something like this, so the api would probably be ok to just stick with only local/only federated based on user preference.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •