Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Quarantine new instances by default #113
This was mentioned in #108 and has been brought up several times before.
There are already instances in the wild which opt for only federating with a list of instances, and have various forms to opt into their lists. awoo.space is the one that comes to mind first, but I'm sure that there are others.
In addition to this, it might make sense to offer the ability to quarantine new instances when they federate for the first time. In other words, instances that try to federate are treated as suspended or silenced by default, and an admin can decide whether they should be allowed, silenced, or suspended long-term.
There are obviously lots of nuances to this, but it seems like starting a discussion on it would be a good idea.
Yeah we've been trying to not use that language either, that's why we removed Master from the repo, and the pinned lists too.
Allow-lists are great, and I do think we should do similar to what awoo.space did, and maybe just have that be default for Florence.
This loops back to a previous conversation we've had, about adding in "approved" servers to that allow-list by default (or a selected few).
Allow-list federation trends towards centralizing and/or fully public content, people will need to migrate towards well-supported instances to be able to see each others posts, or cope with not being able to see them in the UI by falling back to viewing them on the remote public timeline -- if we want to give people a realistic ability to exist on the fediverse in a more private or semi-public way (which is necessary for preventing the information asymmetry that harassment coordinators use for abuse) then we should be aware of which threat this is actually addressing and what holes it will leave.
Benefits of Allow-Listing by Default:
Possible Drawbacks/Risks of Allow-Listing by Default:
Those tradeoffs may be good defaults, but it's worth considering to what extent that's a good path to go down.
Why not both? Could there not just be a toggle between "secure federation" (allow-listing by default) and "open federation" (only using block-lists) that admins could choose for themselves when there is a choice between two methods with their own drawbacks? I'm sure for different communities different set of drawbacks could take precedence in the minds of their administrators. The choice also could vary according to the moderation capacity of an instance, instances with fewer or busier moderators may want to opt for secure federation while others may not.
Another thing: if an allow-listing mode is made available, I think it is worth noting that allow-listing and block-listing are not mutually exclusive, they can be combined. Especially if communities make subscription-based allow-lists it would be useful for administrators to apply a block-list to their list of currently allowed instances to prune specific instances not in line with that particular instance's policies (removing instances from the local allow-list with a blocklist that is applied after new allows are added or imported). This would prevent any major possible allow-list governance conflicts over minor instance policy differences (concerning inclusion of a potentially unwanted instance) by allowing an override. With this in mind I don't think there is a serious problem with allowing administrators to import allow-lists and block-lists in secure federation mode.
I never said I was against providing options, making something the default option should be done with eyes wide open as to the tradeoffs. Defaults are meant to represent the option that is most likely to be best in the average case, I think it's an open question which federation mode that's true for, if either (it's an entirely different question whether instance-level action here is the best layer to handle these decisions, and whether this even makes sense as the primary security tool for the fediverse).
I have largely cultural concerns w/ federating or publishing allow/block lists but it's a mostly-separate concern in that it's mostly just going to amplify the worst flaws in either scheme, as automated processes by computers tend to do and not fundamentally change anything.
Since Funkwhale was mentionned and we have allow-listing ready to ship in next release, maybe some insights about our implementation could help you?
When enabled (it is disabled by default), allow-listing in Funkwhale is enforced by:
Items 1 and 2 usually are usually mentionned during discussions on the topic, but this is rarely the case for items 3 and 4.
@meltheadorable our implementation prevents that, because we're enforcing HTTP signatures on fetches (item 4). Because of that, we can detect if a fetch occurs from a trusted pod or not, and answer accordingly (typically, a 403 HTTP code).
Hence, I'd say it is possible to have an implementation that prevent leaks, which potentially remove two items from your
We don't have such a thing in Funkwhale, but for the purpose of transparency and building this kind of features in the future, we do have an opt-in settings that allow admins to share their allow-list publicly.
Someone suggested recently that we could implement this allow-list federation using some trust mechanism. Typically, if a pod is allowed by X trusted pods, it would become trusted by yours too. (X being a configurable threshold). But if it went under your treshold, it would be removed automatically (unless added manually to your own list).
There are also a wide range of in-between possibility, e.g using this trust factor not to automatically allow federation, but to suggest pods to allow, the final say would still go to a human. As of today, I tend to lean toward this kind automated suggestions (vs. completely automated/federated allow-list).
But it still doesn't solve the cold start problem of someone running a 1-user pod, not being able to federate with anyone, because of allow-listing.
One thing I can think of: It's likely that people starting new instances already know people on the network. If those people could somehow suggest the pod for approval to their mods, then the trusting mechanism described above would rapidly kick-in and take over afterwards.
Regarding the "allow-list" term you all are using: it is "problematic", to use your own terminology.
Black/whitelist are proper terms.
Black -> dark -> dark of night -> hidden.
White -> bright -> light of day -> seen.
To assume a racial component is, to be frank, quite racist. It really comes off like Michael Scott saying "Can we use a less offensive term than 'Mexican'?"...
Additionally, making such a connection to such a binary concept inherently erases brown people. Apparently I don't exist?
By tripping over yourselves to look like "one of the good ones", you really end up looking much worse.
Except that it is 100% clear.
First, it's not yes/no, as I outlined above.
Additionally, you would not be able to find anyone who would be genuinely confused as to the meaning. By definition, this makes the meaning clear. The meaning is just being intentionally conflated with skin color for no constructive reason.
But that's my take. I'll refrain from further comment. I just wanted to note this for any passive readers of this thread.
You are very right in pointing it out and I appreciate it. I should make it clear that while I stand that allow is a better term in this case, it being so due to conflation with race is not a very good argument, and you pointed out a fair case why.
Sorry for shutting your argument down because of a reason other than your actual argument. Your statement is still important and it reminds us that we need to involve more people of colour in the project.
I think it is better to change to allow/blocklist because:
Racism has influenced our non-literal terms too. These little efforts can change the way we see the world and reduce (micro)aggresions against black people. Language is important.
I'm not sure this issue requires more noise, but hopefully I have something useful to add.
We currently have:
What we don't have and that I don't see here:
Ultimately, a new instance to me, should not be able to have 1000s people following a user, send 1000s of message to a user, fetch 1000s of status from a users (and or the reverse, 1 to many users).
Bonus point if I know what that instance blocks, who is their admin, who they already federate with.