search

florence-social / mastodon-fork

Florence's fork of Mastodon
GNU Affero General Public License v3.0
138 stars 15 forks source link

Quarantine new instances by default #113

Open clarfonthey opened 5 years ago

clarfonthey commented 5 years ago

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.

Laurelai commented 5 years ago

I think whitelisting is a good idea.

kindfulkirby commented 5 years ago

Sidenote: Funkwhale uses "allow-listing", which I think would be a better name for that list. It is more accurate and does not have the "white = good" baggage.

mal0ki commented 5 years ago

Sidenote: Funkwhale uses "allow-listing", which I think would be a better name for that list. It is more accurate and does not have the "white = good" baggage.

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).

meltheadorable commented 5 years ago

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.

thall-gnu commented 5 years ago

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.

meltheadorable commented 5 years ago

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.

agateblue commented 5 years ago

Since Funkwhale was mentionned and we have allow-listing ready to ship in next release, maybe some insights about our implementation could help you?

Context links:

When enabled (it is disabled by default), allow-listing in Funkwhale is enforced by:

  1. Dropping incoming messages from untrusted pods
  2. Dropping outgoing message delivery to untrusted pods
  3. Prevent fetches of messages/content hosted on untrusted pods
  4. Prevent fetches initiated by unstrusted pods

Items 1 and 2 usually are usually mentionned during discussions on the topic, but this is rarely the case for items 3 and 4.

  • Trend towards unauthenticated public content to cope with visibility restrictions (people can't read a thread from their own instance because it doesn't federate with all participants, so people post public threads and public replies so that they are visible on remote public timelines)
  • Does not prevent "leaks" (especially because of the prior point) which allow non-federating instances to coordinate harassment, especially through large instances or via other platforms (which amounts to an increased doxxing risk)

@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 cons list, but possibly introducing others.

Allow-list federation

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.

david0178418 commented 5 years ago

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.

meltheadorable commented 5 years ago

Regardless of whether the terms are racist or not, black/whitelist are technical terms and "block" and "allow" are clear and unambiguous to everyone, might as well use terms that are more accessible.

clarfonthey commented 5 years ago

Another thing is that white = yes, black = no from a purely colourful sense isn't 100% clear. If I have a list on a piece of paper, you could use white to cover up text and black to add text.

Allow/deny or include/exclude is more explicit.

david0178418 commented 5 years ago

white = yes, black = no from a purely colourful sense isn't 100% clear

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.

clarfonthey commented 5 years ago

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.

scarlet-tobar commented 5 years ago

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.

1011X commented 5 years ago

I agree with @skrlet13 and @meltheadorable here but let's remember to keep the thread on-topic, at least until the CoC situation is finished and we figure out how to handle stuff like this.

Until then, since we've already agreed on this terminology, I'm marking these comments as off-topic.

kyzh commented 5 years ago

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.

maplefeline commented 4 years ago

I hacked a thing https://github.com/florence-social/mastodon-fork/compare/main...maplefeline:citizenship . It's incomplete, but there are no model changes which is what I cared about. It's deployed to my instance, and I set some alerts on logging

maplefeline commented 4 years ago

Seems to do everything I need. Next would probably need that log line exposed as an event for UI admin level, and a flag to disable the feature block.

maplefeline commented 4 years ago

Also, fix tests, because poke at dev instance and see if it works is a bad workflow.