Hacker News Reader

Comment by notatoad | Hacker News Reader

>Mastodon (and most other fediverse software) wasn't designed with privacy and user safety in mind

this is the real problem. Mastodon and lemmy share way more information than they actually need to (like lemmy shares a list of usernames who upvoted or downvoted a post, not just a count), and if you're using one of those services you should expect that all your data and interactions are public. that's the actual threat here, not the possibility that facebook might suck up that data. Blocking Threads from federating is just a short-term patch over mastodon's bad privacy controls.

View on HN

Not justifying the design decision (which is bad IMO), but the reason upvotes and downvotes are shared is the nature of sending discrete events. I've been working on a Reddit like thing on top of Matrix and likewise I have to send upvote and downvote events, which means other clients that fetch events will fetch each upvote and downvote event and a malicious client can then track what individuals upvote and downvote.

(I'm trying to play around with ways around this, like using a bot to instead publish aggregation events and making votes private, but it's an ongoing exploration.)

We’re two people making a Reddit-thing on top of Matrix as well. Going open source in a few days. My email is in my GitHub profile if you wanna talk!

To be clear, Twitter also shares the list of users who like a post, and people generally seem to view this as a good feature rather than an invasive one, so it makes sense that Mastodon implemented it as well.

twitter shares that while making it immediately clear that the information is public. when you like a post you know your name is going to show up on the list of people who liked it, because the "like" button and the list are right beside each other. that's consent.

lemmy does not make it in any way clear that upvotes and downvotes are public information.

that's an UX problem more than a protocol problem. anonymous voting would be more easily gameable.

> Blocking Threads from federating is just a short-term patch over mastodon's bad privacy controls.

It's not a patch at all. Facebook (and literally anyone else) can still scrape or otherwise access that data in a hundred different ways. Blocking Threads is simply some server admins making an anti-Facebook statement, nothing more.

Not related to privacy, but the main point of blocking is to never host their content. Not listing it, not caching it, not hosting their interactions with your users's posts. It's more than a statement.

ActivityPub has been ignoring privacy since at least 2017 https://github.com/w3c/activitypub/issues/225

I see a good discussion of the different options and why they've chosen not to take them. That's not ignoring

One idea is to create a privacy-oriented server (client?) that lies; expresses things like upvotes but does so with generated identities.

it doesn't even appear that there's any need to lie. upvotes/downvotes in activitypub are expressed as a number, so a server could simply report -300 instead of a list of 300 different "-1"s to indicate that 300 people had downvoted. but that's not what the lemmy default behaviour is.

If ActivityPub and Mastodon were designed with privacy in mind, Facebook/Meta wouldn't touch it with ten foot pole.

Reply on news.ycombinator.com