CARIAD Policy

From the IFTAS Trust & Safety Library - supporting volunteer moderators in the Fediverse

Consensus Aggregated Retractable IFTAS Allowlist Denylist

Version 1.2 May 1st, 2025

Summary #

CARIAD is intended to provide new service providers a basic, first step in reflecting the domain blocking activity demonstrated by high volume service providers, as a means to block the most widely blocked domains. IFTAS Needs Assessment respondents; community members; and advisors have asked for a shared knowledge of the most commonly blocked domains. The CARIAD list reflects the observable domain blocks affecting roughly 55% of all Mastodon accounts.

CARIAD cannot and will not provide safety for all possible use cases.

Many communities will require additional research and resources to provide more comprehensive domain federation management. Specifically, CARIAD does not protect LGBTQ, BIPOC, BAME or other marginalised communities. Additional research will be required to better serve your membership, we recommend reviewing the Denylist Resources section of the IFTAS Connect Library.

CARIAD is not intended to be a long term solution. It is highly recommended that new service providers first use CARIAD or a similar “minimum necessary” list to begin their domain curation activities, then explore additional resources.

Motivation #

Newcomers to Mastodon service provision are often unaware of the full extent of the large number of servers with which they will immediately federate content once installation is complete. A known number of these federating servers are operated by bad faith actors, leading to documented cases of newly-created servers being overwhelmed with hate speech, illegal content, network or service abuse, and spam.

Denylist assistance is an oft-requested feature and the lack of knowledge or at-install support for denylists leads to documented cases of new administrators being overwhelmed by hate speech, trolling, network or service abuse, and spam. This highlights the need for an effective, early denylist approach to curtail the most obvious vectors for abuse and inauthentic behaviour.

As noted in The Atlantic Council’s Task Force for a Trustworthy Future Web report “Scaling Trust on the Web”:

Federated spaces have many of the same propensities for harmful misuse by malign actors as mainstream platforms like Facebook and Twitter, while possessing few, if any, of the hard-won detection and moderation capabilities necessary to stop them. Each instance of a federated service can choose for itself what its governance approach will be. Community standards, content moderation, user reporting, and protecting against large-scale or coordinated campaigns of harassment or disinformation—even within an individual instance—require a broad array of technical, institutional, financial, and logistical competencies that federated spaces are not currently designed to support.

Securing Federated Platforms: Collective Risks and Responses notes that

“…shareable or centralized denylists—that is, lists of instances believed to be malicious or harmful that can be blocked en masse by instance administrators and moderators—are a useful first step for knowledge-sharing among community members, while alleviating burdens on moderators to curate and block instances individually. Initial implementations of shared instance denylists could readily extend to a critical gap identified in our analysis: an inability to exchange content moderation decisions and threat information across instance boundaries.”

The high-volume providers that CARIAD observes have demonstrated that they block domains for:

  • Network and service abuse, spam, malware, malicious activity;
  • Illegal (in their respective jurisdiction) content – this may include (but is not limited to) sale of illicit drugs or weapons, child sexual abuse material, terroristic content, advocation of national socialism;
  • Inactive domains – domains that are no longer in service but may become available for sale or otherwise transferred and re-used maliciously.

CARIAD Policy Specification #

Intended Use #

CARIAD is intended to provide new service providers a basic, first step in defederating the domains already widely defederated by high volume service providers. IFTAS needs assessment respondents, community members and advisors have asked for a shared knowledge of the most commonly blocked domains. The CARIAD list reflects the observable domain blocks in place covering roughly 55% of all Mastodon accounts.

CARIAD cannot and will not provide safety for all possible use cases. Many communities will require additional research and resources to provide more comprehensive federation management. It is not intended to be a long term solution, and resources are listed below for service providers seeking to enhance their denylist to further curate the domains with which they federate. 

Source Inclusion Criteria #

CARIAD combines data from two sources:

  1. The IFTAS Do Not Interact list, a manually reviewed list of domains labelled by harm. 
  2. A curated aggregation of the blocks in place on high volume Mastodon service providers. To be eligible for observation, each service provider is reviewed for the following criteria:
    1. Have been in service for at least 6 months;
    2. Have at least 0.25% of total MAU as measured by FediIndex (at time of writing this is roughly 2,200 MAU);
    3. Themselves have a demonstrable set of domain blocks already in place;
    4. Not themselves appear on the CARIAD or DNI lists.

Bias #

The inclusion criteria is a mix of North American, Western European and Southeast Asian service providers. This biases the list in favour of white and global north speech and prejudices, and as such should be used only by new service providers who are comfortable reflecting the aggregated views of white or global north service providers.

Additionally, the sources represent the largest service providers, who have generally favoured preserving relationships over blocking speech and content, and therefore are less likely to take action against domains that others may consider worthy of blocking. Larger service providers are also less hesitant to block a small service with few accounts, which may lead to unintended aggregation of this bias. 

Domain Inclusion Criteria #

As new entries become eligible for inclusion, they are reviewed by IFTAS staff and advisors. If approved for inclusion, entries are listed with the majority recommendation. Domains listed on the IFTAS DNI list are included at the IFTAS severity level, regardless of observed sources.

The database and its associated lists will be reviewed quarterly by IFTAS to ensure the criteria are working as intended, and not causing harm to any community. 

Domain Exclusion Criteria #

As and when domains fail to meet inclusion they will be delisted, and FediCheck will remove the listing from any subscribed server. 

Appeals #

In order to appeal a listing, a request must be sent from an address at the listed domain (eg: abuse@example.com) to our contact address below, with evidence that the issue has been resolved. We may verify the address by sending back a confirmation message asking for a response. 

Delisting requests must be sent to the delisting email address, written in English language, in text form: delist-cariad (a) iftas (.) org 

Requests are typically investigated and processed within three business days. 

All delistings are free of charge.

Listing Longevity #

As an observational list, all listings are observed and reported. Each individual listing will remain on the list for as long as a listing is visible on any of the sources and meets the requisite threshold. 

Access #

Access to the CARIAD list will be free and available via the domain observatory service. No payment is required for use of the list, nor for listing or delisting requests.

Public Feedback #

Members of the public may make enquiries about the list, or raise issues, using the email contact@iftas.org

Further Reading #

Denylist Resources #

CARIAD is intended to be a new service provider’s first step in obtaining recommendations for limiting or defederating third-party services. It is highly recommended that service providers research additional resources to understand the threats, mitigations, and approaches to managing domain federation. The following links may be of help in this regard.

Server Administration and Moderation Communities #

Online communities are a good way to learn from experienced service providers and community managers.

Academic Research #

These papers may be helpful in understanding the benefits and dangers of shared lists.

FAQ #

  1. What sources does the aggregation process draw from?
    IFTAS manually curates a list of service providers that are deemed appropriate and representational. The source for CARIAD is IFTAS, not the observed sources.
  2. How are observed sources weighted?
    No weighting is applied, other than the source inclusion criteria, which precludes all but the largest providers from participating.
  3. What happens when a CARIAD source blocks an instance because it appears on the CARIAD list?
    A potential outcome of this activity is a number of domains may slowly progress to 100% observed agreement. This is an anticipated possible outcome that we will monitor and act on as needed. Of note, the observed sources at time of writing do not themselves collectively block any single domain, and fewer than ten percent of all observed domain blocks are shared by more than half the sources.
  4. Does IFTAS perform manual review?
    Each domain is reviewed for inclusion by IFTAS before being made available to FediCheck.
  5. What are the reasons or labels?
    IFTAS uses a shared vocabulary for the DNI list, and may, in the future, undertake to label additional domains and/or incorporate labels from trusted flaggers.
  6. Why “CARIAD”?
    Cariad is the Welsh word for love. We believe helping create and preserve safety is an act of love.
This page was last updated on 2025-05-06
Was this page helpful?

IFTAS Community Library is licensed under CC BY-NC-SA 4.0, unless otherwise noted.