It’d be nice to (eventually!) see a link laying out a privacy policy for the instance, something like: https://newsie.social/privacy-policy

I’d especially be interested to know how long you associate the IP addresses we visit from with our accounts, who can see that info (and our emails), what other PII you store, and how long deleted posts/accounts are stored for.

(Totally get and very much appreciate that smorks &co have a lot on their plates just getting this place off the ground, not trying to demand additional work, just a suggestion. Seems like it’d take some thinking to balance with eg. a good backup regimen.)

  • BuoyantCitrus@lemmy.caOPEnglish
    2·
    1 year ago

    Read it over and want to thank you for taking this on, it’s a good start covering most / all of what one would expect to be laid out in something like this. Tedious but well worth doing! I do think for the official policy it might well be worth the community crowdfunding a lawyer who has solid experience in such things, maybe EFF can help and we can do a sort of donation drive for them or similar?

    Don’t have tonnes of specific advice but a few things stood out:

    Retain the IP addresses associated with registered users no more than 12 months.

    Seems pretty long and I know this is a template so I imagine smorks will aim for much less given that he even makes an attempt to anonymise nginx logs. I think we might want to keep the template lower too just to nudge people in the right direction?

    You also understand that although there are controls to prevent the distribution of your email and IP address, due to the nature of federated services, all of your engagement on this platform should be considered public.

    I think this is a key point but the “although” calls the security of ip/email into question and seems to potentially lump it in with the other stuff. Maybe split them out somehow?

    {{your_instance_name}} makes every effort to secure your email and IP address and limit access to them. Due to the federated nature of this platform, we cannot provide similar guarantees for your direct messages as they are exposed to other instances outside of our control so it is best to consider them potentially public along with any other interactions you make.

    Which does cause me to wonder: how is voting federated, do other instances see which users up/downvoted a comment from lemmy.ca or does lemmy.ca just provide vote totals for the instance?

    And I think a plain language add-on explainer thingy is great, the fediverse is a bit confusing. I found your draft a bit long and a bit, I dunno, overfamiliar? Not saying I could do better, it’s just a hard thing to be conversational without being twee I suspect. Definitely respect your making the effort, it’s a worthwhile contribution in its own right and lays out what’s valuable and different about this space along with its limitations. Although it might be scope creep to include quite so much detail about how Alpha, Meta, etcetera. operate I like your concise explanation of “they’re probably not listening because what they do with metadata is kinda more powerful”. I often struggle with this as that “I know, it’s like they listen!” is a common reaction that people have in support of my aversion to eg. installing Meta’s apps on my phone.

    On second though, I wonder if this could be even more general and just a really polished version explaining the overall gist of the platform that instances can link to at joinlemmy.org. Like a section 1b “Why federated?” after https://join-lemmy.org/docs/index.html#introduction

    • sinnerdotbin@lemmy.caEnglish
      1·
      1 year ago

      Thanks for taking the time to look it over! As I’ve expressed, this is really a Lemmy wide initiative, and as you’ve suggested, something that warrants a community fundraising effort to provide proper legal oversight.

      Seems pretty long and I know this is a template so I imagine smorks will aim for much less given that he even makes an attempt to anonymise nginx logs. I think we might want to keep the template lower too just to nudge people in the right direction?

      Meant to make this a admin supplied variable and have now updated. You’ve caught onto the spirit of what I am doing here though; it is not just intended as a document to inform users but to help admins navigate their responsibilities. That is why I have given the example of disclosure in what I see is a huge potential issue with the PostgreSQL SSL support. This will hopefully make a potential inexperienced admin take pause when their server is being tach’d out and the decide to host the DB outside of the local host without a proper mitigating strategy (and I have seen this happen before with very experienced admins in a commercial setting).

      I think this is a key point but the “although” calls the security of ip/email into question and seems to potentially lump it in with the other stuff. Maybe split them out somehow?

      Agreed. I kind of see how in one hand I’m saying that component is secure while also saying it isn’t without making the distinction between the user submitted public data and the traceable data that is being protected. I’ll figure out a better way to partition that.

      Which does cause me to wonder: how is voting federated, do other instances see which users up/downvoted a comment from lemmy.ca or does lemmy.ca just provide vote totals for the instance?

      This is my big concern here and why despite telling myself to stay out of it I got involved. A lot of people, very experienced people, and some admins, do not have a full picture of how this works yet. Your votes are entirely public, there is just the UI choice in Lemmy to not display them. On other interoperable platforms this data becomes public. When this comes up there is a chorus of people chiming in, “don’t post anything you don’t want public on the internet”. There is a difference between potential scraped or captured copies and a copy that is distributed by design. There are two different goals: a monolith platform has a measure of control in how your engagement is made public while being completely open to being tracked. A federated system, by design, has limited control over how public your engagement is (and remains) but a high level of tracking protection. This maybe started out as a group of largely technical users that understands this distinction, but as adoption grows so does the risk of this distinction not being well understood.

      I found your draft a bit long and a bit, I dunno, overfamiliar?

      Yeah, I am going to work on a “lite” version eventually. It is not a simple task to educate in this domain where you have two distinct ideologies on the same subject.

      On second though, I wonder if this could be even more general and just a really polished version explaining the overall gist of the platform that instances can link to at joinlemmy.org. Like a section 1b “Why federated?” after https://join-lemmy.org/docs/index.html#introduction

      I am pushing this hardcore platform wide. I have confidence in our local admin and would like to see it protected here, but the scope of my goal has gone platform-wide.

      Thanks again for taking the time to provide input!

    • sinnerdotbin@lemmy.caEnglish
      1·
      1 year ago

      I found your draft a bit long and a bit, I dunno, overfamiliar?

      I created a “lite” version. Tried getting GPT to summarize it and it failed horribly. Don’t know if that says something good or bad about my writing or good or bad about the complicated nature of federation.

      https://github.com/BanzooIO/federated_policies_and_tos/blob/main/optional-privacy-policy-intro-lite.md

      Language still might not be for everyone, but hopefully gives admins a place to start in really making a clear distinction between their and the user’s responsibility.