Lemmy Support

4660 readers

24 users here now

Support / questions about Lemmy.

Matrix Space: #lemmy-space

founded 5 years ago

MODERATORS

dessalines@lemmy.ml

Feature Request: User Privacy (lemmyadmin.site)

submitted 1 year ago by boulderly@lemmyadmin.site to c/lemmy_support@lemmy.ml

16 comments fedilink hide all child comments

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?)

sql query to all user subscriptions

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.

you are viewing a single comment's thread
view the rest of the comments

[–] scrubbles@poptalk.scrubbles.tech 2 points 1 year ago (1 children)

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.

[–] boulderly@lemmyadmin.site 1 points 1 year ago* (last edited 1 year ago) (1 children)

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

[–] scrubbles@poptalk.scrubbles.tech 1 points 1 year ago (1 children)

Again I don't see the payoff really. I don't think posting on a site that's publicly available really means that you get privacy so to speak. DMs are the only thing that I'd be maybe weary of, but even then I'd say there is no expectation of privacy on Lemmy servers. Matrix chat would be a place to go for private DMs, but here I would take the 90's parent advice and say "Anything you put on the internet should be assumed public".

In Lemmy's case I'll reiterate that yes, it all points to you as in "your unique user ID", but you can control if it points to you, the human. Who cares of userId 42 subscribes to communities A and B. The privacy aspect is do we know who user 42 is?

[–] boulderly@lemmyadmin.site 1 points 1 year ago

so consider a smaller local instance like I'm setting up. If it's ever anything more than me and my mom it's gonna be a bunch of people I know and their friends. And if my instance is their entry point to the fediverse then yeah I want it to be as private as we can make it for them.

But also, even if someone's IRL identity was masked, I've only been around a week and I'm starting to recognize handles on the fediverse. Ideally we make friends here and it's a community for us.

Now imagine how humiliating it would be if someone malicious gained control over an instance and published everyone's subscriptions/likes etc. Sure more savvy users probably do have separate accounts but honestly most will not.