- cross-posted to:
- thenexusofprivacy@lemmy.blahaj.zone
- cross-posted to:
- thenexusofprivacy@lemmy.blahaj.zone
If you’re a developer working on a fediverse app or service and want to get it right – or just don’t want to be the center of the next firestorm – here are a few suggestions.
You must log in or register to comment.
I’m not sure there’s a better way to put them, but I bristled at the two suggestions at a high level which tell me what to say or not say, and call out my being cis as a thing to be careful about.
I’m glad that I read them despite the bristling, because I found that they were things I wouldn’t say or do, and they were reasonable suggestions.
But especially the cis comment made me kind of worried. As the platform grows these types of desired policies are going to be drowned out by the majorities.
All of the proposed solutions are intentionally not scalable ones, and seem designed to keep the platforms smaller and protected. This makes absolute sense especially when held up beside the marginalized peoples who are asking for them’s experiences of being marginalized.
I hope that we can find ways that satisfy those needs even through growth. It would be interesting to see scalable opt-in solutions for this problem. It would especially be useful to integrate solutions into the protocol.
But in truth I was shocked to learn about robots.txt recently, and more shocked to hear how well-ish that type of solution worked until AI came along and ignored it. So it’s anyone’s guess as to how well similar solutions might work here.
Thanks for the feedback – and thanks for reading them despite the bristling. I couldn’t come up with a better way to put them … I know they’ll cause some people to tune out, but oh well, what can you do.
I don’t think these solutions are inherently unscalable, it’s more that there hasn’t ever been a lot of effort put into figuring out how to make things scalable so we don’t have any great suggestions yet. I wrote about this some in The free fediverses should focus on consent (including consent-based federation), privacy, and safety (the article is focused on instances that don’t federate with Threads, but much of it including this section is true more generally):
There aren’t yet a lot of good tools to make consent-based federation convenient scalable, but that’s starting to change. Instance catalogs like The Bad Space and Fediseer, and emerging projects like the FIRES recommendation system. FSEP’s design for an"approve followers" tool, could also easily be adapted for approving federation requests. ActivityPub spec co-author Erin Shepherd’s suggestion of “letters of introduction”, or something along the lines of the IndieWeb Vouch protocol, could also work well at the federation level. Db0’s Can we improve the Fediverse Allow-List Model? and the the “fedifams” and caracoles I discuss in The free fediverses should support concentric federations of instances could help with scalability and making it easier for new instances to plug into a consent-based network.
(The post itself has links for most of these.)
Thank you for the thoughtful response here.
If it helps, I feel like “Be an ally if you’re cis and joining the conversation” might fit what you’re saying and wouldn’t have bristled me. But I recognize that it isn’t your responsibility to manage the emotions of people who have unquestioned privilege.
I also hope this isn’t a weird question but I noticed that I have to turn my vpn off to see your site. Is that intentional?
On the other stuff, I love that you’re talking about the importance of account migration, and I like the idea of the concentric federation.
There’s a bit more in there about scalability. So it’s nice to see your thoughts around it. I was thinking that the opt-in process which messages you for approval was the closest to scalable from the former article, because it allows everyone the opportunity to opt in without requiring hidden knowledge. But it could also feel like some sort of fishing attempt to get a message asking for consent.
So I guess finding a way to build opt-in into the protocol in some way would be the most scalable option in the long term. However that could work.
Thanks for the tipoff on having to turn off the VPN, it’s not at all intentional – and it’s not a good look for a site with privacy in its name! I’ll try to figure out what’s going on, it’s pretty vanilla Ghost / nginx hosted on a Digital Ocean droplet so not immediately obvious.
And yeah, it’ll be interesting to see how well the messaging you for approval works out in practice. As you could say it could look like phishing; and even if it’s fine when just one app is doing it, it’ll be annoying if there are hundreds. Also, there’s a Mastodon setting to silently ignore DMs (and I think other platforms have similar options as well). And for Bridgy Fed, it would be great to have a mechanism that works symmetrically between the fediverse and Bluesky … but Bluesky doesn’t have DMs. Tricky!
I should probably mention something about being a good ally in that section, that’s a good suggestion. That’s not the main message I’m trying to convey though, I really do mean it as a warning to cis guys to be careful. These firestorms are tiresome for everybody, ould we please just not? Also btw sometimes particularly unpleasant for whoever sets them off. But maybe there’s a better way to word it.
That’s all fair. I can see what you meant after reading it, so maybe it’s more of a me thing than one you have to consider in any depth. I know I have issues around feeling heard that aren’t the general. And people who don’t like being called out for cis-typical behaviors tend to be various forms of awful people that don’t really need to be included.
Anyway, thank you for the conversation and the blog posts. I’m using Hotspot Shield as a vpn, if that helps and looking at your site through Safari on my iPhone.
They all seem reasonable suggestions:
- Consent matters, even for public posts
- Get broad feedback before launching – and listen to it
- Honor existing opt-in and opt-out mechanisms
- Include an additional opt-in mechanism for your service if it’s not just a search engine or profile discovery (or something very close to them)
- Make sure to communicate that you’re taking an opt-in approach and honoring existing mechanisms
- DON’T say the things that developers who ignore consent typically say
- Be extra careful if you’re a cis guy
- Look at opt-in as an opportunity for a potential competitive advantage
I’m conflicted over the fact that using ActivitiyPub necessarily implies consent for other people to collect the data you send through it. It seems that many people using ActivitiyPub connected services want something different than ActivitiyPub or different default settings on many ActivityPub services.
Thanks, glad you think they’re reasonable. I don’t see it as using ActivitiyPub implying consent; it’s more that ActivityPub doesn’t provide any mechanisms to enforce consent. So mechanisms like domain blocking, “authorized fetch”, and local-only posts are all built on top of ActivityPub. I agree that many people want something different than ActivityPub currently provides, it’ll be interesting to see how much the protocol evolves, how far people can go with the approach of building on top of the protocol, or whether there’s shift over time to a different protocol which has more to say about safety, security, privacy, and consent.
That’s similar to the “you’re being inconsistent” thing that the article says not to say, kind of.
Consent isn’t really built into ActivityPub and it’s inherently the opposite of how I understand it to work (copying your content all over the place regardless of your desires).
But their argument is kind of reasonable.
Who cares?
We can change ActivityPub, but we couldn’t change Twitter. People were tolerating worse just for the sake of having a community before they moved to the fediverse. They had no say before and they’re asking for better from it now that they can have their voices heard at all.
Consent isn’t really built into ActivityPub and it’s inherently the opposite of how I understand it to work (copying your content all over the place regardless of your desires).
ActivityPub is a means of sharing information in a way that the information can easily be collected and reshared. By using it, you should expect that people will collect and reshare information you send via the ActivityPub protocol.
The article addresses this directly in the section on things to not say, though:
ActivityPub does indeed “makes assumptions that are fundamentally opposed to the kinds of protections that people seem to be seeking.” But in a discussion about whether or not to get consent, even the ones that are true the miss the point – just because ActivityPub leaves open possibilities for you to do something without getting consent, that’s not the only option.
That addressing is insufficient because it begs the question of consent being withheld. But the consent is implicitly given by the sending of information via the protocol, otherwise a service like Mastodon can’t exist. The question of asking for consent after it is given is the part that I’m conflicted about.
Read the article, I didn’t write it.
“Implicit consent” is another one they call out directly.
I did. I’m sharing my thoughts about it. Some of those thoughts are that it seems to make assumptions that don’t hold.
DON’T say the things that developers who ignore consent typically say
That’s likely to increase the pushback. If that’s your goal, great, go for it! If not, though, it’s best to avoid stuff like this.
- “Posting publicly gives implied consent to use the data”
I don’t inherently agree with the article’s ask, but you’ve literally only proven its point by stating, verbatim, one of their “please stop making us retread these tired arguments over and over” points.
OP links to a Mastodon thread from a user who breaks down the technical limitations of ActivityPub and proposes how the situation can be improved. Maybe read that.
Also, if you think that these are reasonable suggestions, then perhaps ignoring them directly isn’t the best way to engage with this article?
