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.

  • @boulderlyOPA
    1•1 year ago

    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?

    rows from the community_follower table

    • Max-P
      3•1 year ago

      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.

      • @boulderlyOPA
        1•1 year ago

        also, you could modify subscription counters so you had a count of subscribers from an instance without knowing who they were.

      • @boulderlyOPA
        1•1 year ago

        There, you’ve already found a reasonable way around it! 😀

      • @boulderlyOPA
        1•1 year ago

        what is the problem with votes btw? Someone else just mentioned those should be private too in the chat where I first raised this.

    • Scrubbles
      2•1 year ago

      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.

      • @boulderlyOPA
        1•1 year ago

        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
          1•1 year ago

          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?

          • @boulderlyOPA
            1•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.