There's very little privacy on the fediverse today. Mastodon and other fediverse software wasn't designed and implemented with privacy in mind. Even the underlying #ActivityPub protocol that powers the fediverse has major limitations. But it doesn't have to be that way!
Meta's new #Threads product means that it's critical for the fediverse to start focusing more on privacy. Of course, #Meta's a threat in many other ways as well; that said, the privacy aspects are important too.
For one thing, if Meta does indeed follow through on its plans to work with #Mastodon instance admins and others "partners" who to monetize their users (and their data), people in the region of the fediverse that's not Meta-friendly will need stronger privacy protections to protect their data. And Meta's far from the only threat to privacy out there; changes that reduce the amount of data Meta can gather without consent will also help with other bad actors.
More positively, there's also a huge opportunity here. Privacy's even worse on Facebook and Instagram than it is in the fediverse. So If the fediverse can provide a more private alternative, that will be hugely appealing to a lot of people.
Any way you look at it, now's a good time for the fediverse to take privacy more seriously.
The bulk of the article focuses on threat modeling, a useful technique for identifying opportunities for improvement. It's a long article, though, so if you don't want to wallow in the details, feel free to skip ahead to the section at the end on the path forward and the specific recommendations.
And if you're already bought in to the idea that the #fediverse
should focus more on privacy, and just want to know how you can help make it happen, it also suggests specific actions you can take -- and there's a section with some thoughts for #MastoAdmin
Here's the table of contents:
There's very little privacy on the fediverse today. But it doesn't have to be that way!
Today's fediverse is prototyping at scale
Threat modeling 101
They can't scrape it if they can't fetch it
Different kinds of mitigations
Attack surface reduction and privacy by default
Scraping's far from the only attack to consider
Win/win "monetization" partnerships, threat or menace?
A quick note to instance admins
Charting a path forward
Recommendations
This is still a draft, so as always feedback is welcome. And thanks to everybody for the feedback on previous drafts!
I vetted the relays I joined when my server (ailbhean.co-shaoghal.net) joined them, but constantly keeping an eye on relay members would be quite time consuming.
@gunchleoc that's a great point, thank you very much for bringing it up! I'll incorporate that when I do a revision. Is it okay if I acknowledge and thank you for pointing it out to me?
@gunchleoc good point, I should have mentioned that and been clearer about some of what's needed to make it practical on a large scale. Great feedback once again, I really appreciate it!
What it needs is what PeerTube already has and that you recommended in the article: Other instances make follow requests, and then you vet the follow request to let them in, block or simply delete the request so that they can make a new request in the future.
@thenexusofprivacy re: "there isn't yet any good tooling for sharing IP blocklists" I immediately think of DNSBL, this has long been established for antispam IP reputation lists. For high-volume checks like web access, zone transfer and local queries instead of individual on-access DNS queries to a master site is preferable (but the standard DNS caching by the resolver may already help).
You even mention it related to email a few paragraphs below.
FYI @jerry a question related to the post I just did on threat modeling meta and privacy. ⬆️. One of the topics I cover is reducing the number public posts (attack surface reduction from a privacy perspective). Local-only posts can make a big difference on smaller instances -- @darius was quoted as 70%. infosec.exchange is the only largeish Mastodon instance I know of that has local-only posts, and I was wondering if you have any estimate of how much they're used here.
[Also local-only posts are good for other reasons as well, so kudos to you for being a point off the curve and supporting them!]
@thenexusofprivacy I think I’ve only seen one or two people use them other than me. It’s a handy feature, but I think it’s hard to find that setting AND I think most people prefer their posts not be local only @darius
@jerry interesting! Most people on infosec probably see it as a public place, which isn't a bad thing at all, just different from the smaller services that tend to run Hometown. Anyhow I'll revise the post to incorporte that info, thanks much!
Calckey has local only posts & local only channels (a sort of groups/ community/ subreddit type feature -intended to go inter-server in future).
Forgive my ignorance but, aren't smaller instances a general win for decentralisation?
Yet local posting would encourage growth of the 'big' servers.
Also, quite apart from +scraping +apis +rss +federation, what really stops data operators collecting data by creating or piggybacking users & harvesting local feeds?
@ArtBear@thenexusofprivacy@jerry I think local posting makes more sense on a smaller server where you have context for who everyone is. It seems borne out in practice too.
To your final point, I also recommend not having open sign-ups on intentionally small servers.
@ArtBear@thenexusofprivacy@jerry yes but if I am in a group and there are 10 people from 10 servers in the group my privacy is only as good as the weakest link. Keeping things to a specific server with a single ToS and code of conduct and operating under a single legal regime is simpler and I think safer, though I acknowledge what you're saying is more useful
Yes of course. I suppose I understand infosec.servers or family servers and I understand say music or vegan groups as being two fairly different use cases we should both have access to 😀
Really would like to see more group/ subreddit type organisational community hub ability in the masto/calckey sphere, without going exclusively groups without the follows of users as the Lemmy sphere.
Great conversation! It could be that I'm overstating the privacy value of local-only posts on larger instances in practice so I'll think about that more.
"Even with all of today's software issues, community-oriented instances, configured with a focus on safety (which includes privacy) and an emphasis on local conversations, can be more private (and a lot safer) than Facebook or Instagram."
In an earlier draft I had a few more details (relatively small, not allowing open registration, limited federation to a small bubble of similarly safety-oriented instances), maybe I should put them back.
@ArtBear totally agree on the need for better groups -- including private groups which kbin/lemmy don't have.
And in terms of creating or piggybacking users & harvesting local feeds, the only potential defenses I talked about in the post are legal (TOS) or limiting the damage by doing rate limiting (which has its downsides) ... neither of which are great. So this is a hard-to-mitigate threat for threat actors like intelligence agencies or motivated stalkers targeting specific people or instances,. For Meta in particular though, or anybody trying to target "the whole fediverse", it's enough harder (and potentially legally risky) then other kinds of access that preventing and/or other easy options is useful.
Yes, true. A bit of friction achieves a lot even when hermetic seals aren't practical.
I would LOVE to see open / closed groups get future development. Even just for topic organisation and discoverability and conversations with less pressure to catch the post as it happens.
Add comment