Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quarantine new instances by default #113

Open
clarfon opened this issue Jun 22, 2019 · 15 comments

Comments

@clarfon
Copy link
Member

commented Jun 22, 2019

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

This comment has been minimized.

Copy link

commented Jun 22, 2019

I think whitelisting is a good idea.

@kindfulkirby

This comment has been minimized.

Copy link

commented Jun 24, 2019

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

This comment has been minimized.

Copy link
Member

commented Jun 24, 2019

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

This comment has been minimized.

Copy link

commented Jun 24, 2019

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:

  • No need to play whack-a-mole with fash instances
  • More control over what data leaves your instance
  • Lower moderation burden for posted content
  • Fewer instances that can be leveraged to execute a harassment campaign

Possible Drawbacks/Risks of Allow-Listing by Default:

  • If manually approving liberally, may start federating with poorly-vetted instances
  • If manually approving conservatively, much less visibility of content, disincentive for people to run or join smaller instances
  • 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)

Those tradeoffs may be good defaults, but it's worth considering to what extent that's a good path to go down.

@thall-gnu

This comment has been minimized.

Copy link

commented Jun 24, 2019

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

This comment has been minimized.

Copy link

commented Jun 24, 2019

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.

@EliotBerriot

This comment has been minimized.

Copy link

commented Jun 26, 2019

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

This comment was marked as off-topic.

Copy link

commented Jun 29, 2019

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

This comment was marked as off-topic.

Copy link

commented Jun 29, 2019

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.

@clarfon

This comment was marked as off-topic.

Copy link
Member Author

commented Jun 29, 2019

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

This comment was marked as off-topic.

Copy link

commented Jun 29, 2019

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.

@clarfon

This comment was marked as off-topic.

Copy link
Member Author

commented Jun 29, 2019

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.

@skrlet13

This comment was marked as off-topic.

Copy link

commented Jun 29, 2019

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.

  • There are black people that have expressed that these microaggresions affect their lifes. They may not affect you personally, but everyone has a right to live peacefully. And if we can help, why not?
@1011X

This comment has been minimized.

Copy link
Member

commented Jun 29, 2019

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.

@florence-social florence-social deleted a comment from Kootnik Jul 7, 2019

@clarfon clarfon added this to the v0.1.0.0 (Pre-Release 1.0.0) milestone Jul 14, 2019

@kyzh

This comment has been minimized.

Copy link
Collaborator

commented Aug 11, 2019

I'm not sure this issue requires more noise, but hopefully I have something useful to add.

We currently have:

  • Suspend/silence: a way to disallow external instance communication in.
  • Allow list instance(s): a way to only federate in and out to the instance on said list

What we don't have and that I don't see here:

  • a review-list: a list of instance that I want to limit in a way (in quarantine)
  • a graduated-list: a list of instance I explicitly federate with so I can tell people who as trust.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.