Hi every lemmy. I’ve just stood up a couple new instances and I’ve been hanging out in the Admin chat over at https://matrix.to/#/#lemmy-support-general:discuss.online. Someone there asked if they could view subscriptions so I wrote and shared the sql query. (could I have done better on the joins with 2 joins to instance?)
And that’s when I realized what an invasion of privacy that is. Maybe there’s an easier way to do it but could we add optional support for user key pairs, so that if I associated a public key with my account, everything related to me in the db gets hashed with that key? Then I provide my private key at login?
I say optional because I know that’s hard for a lot of folks. But maybe there’s a way to make it easier with something like letsencrypt at sign up so it would be trivial for everyone to do it… Or maybe there’s a way to do it globally with a central key common to all instances, perhaps paired with instance specific keys?
I understand there’s other aspects of user activity that would be best made private to so this could also work, say for votes or whatever else.
Against the grain, but I don’t think users have an expectation of privacy here. This isn’t on some data dashboard for everyone to see, this is admin specific, and even then currently it’s not exposed in an admin panel even, it’s only here.
2 big things that I have already done as an admin that uses this.
- Querying for bot accounts. I had open signups for a while and wanted to know if anyone had signed up for my instance but had no subscriptions, something theoretically that would root out some bots, and it did.
- Querying for trolls. I run a safe space instance where I aim to have quality content. For the time being I allow downvotes, but I keep an eye out for trolling. I have a script that shows me anyone with negative “karma” or who downvote more than they upvote. This way I know who my bad-actors are and I can keep an eye on them.
Some may say it’s too far, but meh, don’t be a jerk on my instance. It keeps my other users happy so I’ll continue to do it.
Finally, none of this is PII I’d say except for the email address, which is also something that’s allowed to be a spam/throwaway email. If a user wants to sign up completely anonymously that’s completely up to them, from a lemmy perspective, it’s a binary “should this user be banned or not”
There’s no reasonable way around it. The best that can be done would to anonymize the votes but then there’s nothing preventing a rogue instance from reporting “yup, 500 users have upvoted this”.
Tying the votes to an account can be helpful mitigating spam. Bots can analyze your patterns and based on your account age, comment history and what not, establish whether you’re a legit user. If everything is anonymous, there’s nothing that can be done.
ActivityPub was just not designed with privacy in mind. There’s debates as to whether Lemmy can possibly be GDPR compliant at all.
Keys would not help at all here, you just switch it from a user ID to a public key.
Either we have trusted mega instances, or we have complete transparency.
lets take community subscriptions specifically. Here’s a handful of rows from community_follower with my person_id. Why couldn’t you hash community_id with my public key and then I provide my private key to whatever ui client I’m using to populate my feeds when I log in?
You’re just joining on your public key to a community then, but your public key still uniquely identifies you. If you encrypt the entire list of subscriptions then you lose all the benefits of sql, the payoff of a tiny bit more privacy would require an entire rearchitecture and requiring everyone to update.
At the end of the day you’re still going to have a unique userId that somehow matches to a community. It’s just how complicated do you want to make that for the sake of privacy.
There’s already a valid workaround. Create a burner account for going to lemmynsfw.
the point is not to encrypt your user id, check this out if you haven’t seen it I think I explain it better here: https://lemmyadmin.site/comment/46. It’s a lot more privacy. And thinking as an admin that wants to provide a safe space for my users, I think it’s worth the effort. I took a very quick look at the tables related to person and I’d bet you could treat these similarly to community_follower:
TABLE "comment_like" CONSTRAINT "comment_like_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "comment_saved" CONSTRAINT "comment_saved_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "community_block" CONSTRAINT "community_block_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "community_follower" CONSTRAINT "community_follower_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "person_follower" CONSTRAINT "person_follower_follower_id_fkey" FOREIGN KEY (follower_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "post_like" CONSTRAINT "post_like_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "post_read" CONSTRAINT "post_read_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "post_saved" CONSTRAINT "post_saved_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "private_message" CONSTRAINT "private_message_creator_id_fkey" FOREIGN KEY (creator_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "private_message" CONSTRAINT "private_message_recipient_id_fkey" FOREIGN KEY (recipient_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
Then how is the server gonna know what content to push to your home instance?
Arguably that might not be needed for subscriptions specifically, the home instance could just know the overall list of subscriptions and use that. But then the subscription counters would be wrong, and lead to the same problem as votes.
But at least subscriptions are already strictly between the home instance and the remote instance, and never leaves the instance if the community is local.
This sounds like it would achieve data at rest - It’s a good idea in theory but i’m not sure how sensible this would be for Lemmy?
Even if our subscriptions are protected, the server would need some way to establish what your followed communities are to populate your feed… Because of this it could still be possible to identify a user’s subscriptions, maybe via looking at proxy logs or outgoing traffic?
Would be useful if someone more knowledgeable had some input, I’m not really a cryptography guy myself 😅
Tbh, if you did a GDPR request to some site like the Alien R, part of that result package will include a plaintext list of communities you follow…
