Question I'd like to hear everyone's thoughts on possibly making votes public. This has been discussed in a lot of other issues, but here's a dedicated one for discussion. Positives Could help figh...
Probably better to post in the github issue rather than replying here.
I think people misunderstand. I too would prefer privacy, but theres a big BUT.
Due to how the federation works, anyone who is tech savvy enough can already see votes. One way is to run an instance.
This change doesn’t lower privacy, it aligns expectations with reality. A false sense of privacy, which people obviously show here in the comments, is way more dangerous.
Except, if you’re using anything other than Lemmy at this point that information is already about. The Likes/Dislikes are considered public information by the protocol. Lemmy devs probably just didn’t get around to building out the UI for that before the Reddit APIcolypse.
If anything, Lemmy devs should work on methods to obscure user identities, not expose them.
One of the biggest issues with the fediverse is very specifically how much user information can be exposed outside your home instance. As has been pointed out in this thread, it is very easy for rogue instance admins to set up quiet data mining instances.
It seems like it should be relatively straightforward for certain activities, like votes and telemetry, to be anonymized/tokenized for the purposes of federation, since that information all propagates outward from the home instance anyway.
How about you assume less? I spent 40+ minutes looking for this here, here, here and here and I’m already fairly familiar having done work on two other ActivityPub based projects.
In addition public-addressing (or the lack of use thereof) in no way claims to achieve what you’ve stated - which is probably why it’s not the answer to my query.
That would be great. I’m not sure how to solve the problems that arises though. If i can send an anonymous vote to an instance, what stops me from sending 100?
Maybe there’s some smart cryptographical solution here that alludes me, but it seems hard, if possible.
This is literally already a problem. I can easily set up an instance and write a simple bot which just spams votes with randomized user strings. There are generally a bunch of these functional vulnerabilities in the AP trust model which are only mitigated by the current lack of scale. Work needs to be put into reworking the trust model, not exposing user telemetry to even more people.
I can easily set up an instance and write a simple bot which just spams votes with randomized user strings.
Well you can do that for a little bit, until your instance gets found out and it gets defederated. And you need to pay for a new domain if you want to do it again. So the current system actually makes it cost real money to do this spam you’re talking about.
Good point. Would it be useful to somewhat anonymize them by giving every user a unique code? So admins would see these codes but not easily know what users they represent.
I’m afraid this may enable a malicious instance to use this mechanism to manipulate votes while making it much harder to detect. I think transparent voting is much preferable.
If we look at any of the big social media platforms with public votes, that has not prevented voting abuse through bots and the like. Rather it has served to fuel online harrassment campaigns and value of influential individuals votes (ooh Bill Gates liked X, Kamala Harris disliked Y etc.)
Aggregating votes rather than having individually visible votes serves the purpose of shifting focus to how the community values of the content. It’s the same reason that we follow communities rather than people.
Vote aggregates would be insanely easy to maliciously manipulate. Also, the underlying protocol has no support for vote aggregates so this isn’t even an option in the first place.
Votes already are presented to the end user in an aggregated fashion, as opposed to how it is on kbin/mbin. In any case, even in the current implementation manipulation is relatively easy, as an admin can just spin up extra accounts. The fediverse relies on trust.
I think people misunderstand. I too would prefer privacy, but theres a big BUT.
Due to how the federation works, anyone who is tech savvy enough can already see votes. One way is to run an instance.
This change doesn’t lower privacy, it aligns expectations with reality. A false sense of privacy, which people obviously show here in the comments, is way more dangerous.
I accept if a dozen people can see my votes.
That’s not what you’re saying.
Ultimately I’m not invested in this decision. If the instance wants to watch people vote then people stop voting truly or at all.
Except, if you’re using anything other than Lemmy at this point that information is already about. The Likes/Dislikes are considered public information by the protocol. Lemmy devs probably just didn’t get around to building out the UI for that before the Reddit APIcolypse.
If anything, Lemmy devs should work on methods to obscure user identities, not expose them.
One of the biggest issues with the fediverse is very specifically how much user information can be exposed outside your home instance. As has been pointed out in this thread, it is very easy for rogue instance admins to set up quiet data mining instances.
It seems like it should be relatively straightforward for certain activities, like votes and telemetry, to be anonymized/tokenized for the purposes of federation, since that information all propagates outward from the home instance anyway.
Lemmy actually marks votes as private for federation, but it seems that kbin/mbin ignore that.
Ahh, didn’t even know there was a flag for that. I don’t suppose you could link to the relevant w3c or FEP for it?
https://www.w3.org/TR/activitypub/#public-addressing
Next time try reading the spec before asking.
How about you assume less? I spent 40+ minutes looking for this here, here, here and here and I’m already fairly familiar having done work on two other ActivityPub based projects.
In addition public-addressing (or the lack of use thereof) in no way claims to achieve what you’ve stated - which is probably why it’s not the answer to my query.
Right the standard is even more vague than I remember. Unfortunately it’s the only thing we have.
I read about that. In my opinion is that what should change, if possible. There are good reasons why votes a secret in democracies.
That would be great. I’m not sure how to solve the problems that arises though. If i can send an anonymous vote to an instance, what stops me from sending 100?
Maybe there’s some smart cryptographical solution here that alludes me, but it seems hard, if possible.
You could just hash your username+instance combo, right?
hmm, how would the receiving instance verify? what happens if I send 100 random hashes?
This is literally already a problem. I can easily set up an instance and write a simple bot which just spams votes with randomized user strings. There are generally a bunch of these functional vulnerabilities in the AP trust model which are only mitigated by the current lack of scale. Work needs to be put into reworking the trust model, not exposing user telemetry to even more people.
Well you can do that for a little bit, until your instance gets found out and it gets defederated. And you need to pay for a new domain if you want to do it again. So the current system actually makes it cost real money to do this spam you’re talking about.
Sure, but the detection and enforcement mechanism would be the same as it is now.
well, since the voting is public it’s easy to remove your votes and block your instance after the fact
Each instance could store a static private key used to encrypt all usernames in that instance maybe?
Then again, private votes would be private for mods and admins too. So no more moderating vote brigading or downvote abuse or anything like that.
Good point. Would it be useful to somewhat anonymize them by giving every user a unique code? So admins would see these codes but not easily know what users they represent.
I’m afraid this may enable a malicious instance to use this mechanism to manipulate votes while making it much harder to detect. I think transparent voting is much preferable.
If we look at any of the big social media platforms with public votes, that has not prevented voting abuse through bots and the like. Rather it has served to fuel online harrassment campaigns and value of influential individuals votes (ooh Bill Gates liked X, Kamala Harris disliked Y etc.)
Aggregating votes rather than having individually visible votes serves the purpose of shifting focus to how the community values of the content. It’s the same reason that we follow communities rather than people.
Vote aggregates would be insanely easy to maliciously manipulate. Also, the underlying protocol has no support for vote aggregates so this isn’t even an option in the first place.
Votes already are presented to the end user in an aggregated fashion, as opposed to how it is on kbin/mbin. In any case, even in the current implementation manipulation is relatively easy, as an admin can just spin up extra accounts. The fediverse relies on trust.
If this is a hard requirement for federation, then I guess federated services are not for me, as I value my privacy more than I care to use them.