diff --git a/docs/initial-design.md b/docs/initial-design.md index 98ccd1b..fe62a91 100644 --- a/docs/initial-design.md +++ b/docs/initial-design.md @@ -2,7 +2,6 @@ This document is designed as a detailed technical overview of how the FAIR decentralized concept works, including background information on inspiration. - ## Prior Art ### Linux Package Distribution @@ -13,7 +12,6 @@ This also incorporates package signing, however this is implemented as a layer o The mirror system also leads to complexity in synchronization, and does not provide any authoritative source of data for usage statistics. - ### Composer Composer is a package manager for the PHP ecosystem. It consists of "repositories" which host any number of "packages". @@ -24,12 +22,10 @@ Composer's primary usage is for developers, and the complexity of the tool and s The internals of Composer are difficult to reuse in other contexts, and it is not guaranteed to have a stable API. - ### AT Proto -- - -- +- [atproto.com](https://atproto.com/) +- [Atproto for distributed systems engineers](https://atproto.com/articles/atproto-for-distsys-engineers) AT Proto is the protocol underlying Bluesky, which was developed in response to an existing centralized service as a way to redesign to avoid the problems centralization had created. @@ -43,7 +39,6 @@ This avoids some of the big synchronisation problems that occur with similar pro We look to AT Proto as a great example of a specific response to centralisation - there's plenty that will be applicable, but also aspects that aren't, since their problems aren't the same as ours. In the social web, all players are equal - but we're designing a distribution system of providers and users, not a social network. - ### WordPress already WordPress already has a type of decentralized system hacked into it, with premium plugins and tools like Git Updater having to be grafted on to core's update system - and with no potential to integrate into the core install system (there is no way to find the plugin from within WordPress dashboard at this time). @@ -52,11 +47,10 @@ Each implementation integrates independently, with two large implementations com This means that the flow today for many sites looks like: -![](./initial-existing.png)  +![Graph of WordPress' current implementation of package updaters](./initial-existing.png) Notably though, none of these providers speak a common protocol, and all have to integrate into WordPress independently. This makes it more difficult to develop new plugins, and stifles innovation. Integrating these natively will make it much easier for new vendors, and can also solve the new install problem too. - ## Our Protocol Taking lessons from the prior art in the ecosystem, we can model out a similar system. @@ -66,9 +60,7 @@ Taking lessons from the prior art in the ecosystem, we can model out a similar s We'll create three core concepts: - Repository Nodes - - Aggregators - - Extras (e.g. Analytics) The Repository Nodes are servers that provide package zips and some information about them (name, description, images, FAQ, etc). @@ -77,11 +69,10 @@ The Aggregators are servers that provide any service that collects information a Additionally, we'll have some extras. Specifically, a neutral central analytics service that can provide information to aggregators, but is not essential. -![](./initial-overview.png) +![Graph of FAIR's protocol initial design](./initial-overview.png) To bootstrap the network, we'll create reference implementations of the Repository Node, some key Aggregators, and our analytics service - all as open source. We'll also run a central version of each to provide services to smaller players, while allowing bigger players to federate into the network when it makes sense. This will balance flexibility and independence with practicality and accessibility. - ### Repository Node A Repository Node is a simple server that acts as the original source for packages. It can offer a single package or an entire ecosystem's worth, but it is the canonical source for the packages it offers. @@ -96,7 +87,7 @@ Example endpoints for repository nodes might look like: - `/packages` - List all packages the repository node offers. - `/packages/{id}` - Get metadata about a specific package, including: - - `name`, `id`, `description` + - `name`, `id`, `description` - `/packages/{id}/versions` - Get available versions of a package. - `/packages/{id}/versions/{version}/download` - Download a specific package version. - `/packages/{id}/versions/{version}/signature` - Get the package signature for a specific version. @@ -107,7 +98,6 @@ Custom authorization for repository nodes can be implemented for licensing, usin (Detailed design on endpoints tbd, but can be modelled after Composer's design.) - ### Aggregators Aggregators pool information from multiple Repository Nodes to create an index, and offer various services based on this. They store some metadata about packages, but point sites to the actual Repository Node for the canonical information and downloads. @@ -115,7 +105,6 @@ Aggregators pool information from multiple Repository Nodes to create an index, Since package metadata can be used for a wide variety of purposes, many different services are possible, but we think the following are the essential ones we'll need to start with: - **Discovery** - An aggregator to find all available packages, and let users browse and search them. - - **Moderation** - An aggregator to flag insecure/bad packages (and package releases) as well as vouched packages - to provide a good/bad status to help users make an informed decision. A single server could offer multiple types of aggregators - they don't need to be arbitrarily split. @@ -124,28 +113,25 @@ We think there's a wide scope for businesses to build off the aggregation system Also, the network would be open to new aggregator types to allow for innovation - for example, a new recommender type could provide data-driven recommendations on great packages to solve user problems. - #### Discovery Aggregator Example endpoints for a discovery node might be: - `/packages` - List all packages this node knows about. - - `/packages?tag=seo` - Get all packages tagged with "SEO". + - `/packages?tag=seo` - Get all packages tagged with "SEO". - `/packages/{id}` - Get metadata about a specific package, including: - - `name`, `id`, `description` - - `repository_node` + - `name`, `id`, `description` + - `repository_node` - `/search` - Find packages by name, type, tag, etc. - #### Moderation Aggregator Example endpoints for a moderation node might be: - `/check/{id}` - Check a singular package's status data, including: - - `score` - -1 for bad, 1 for good, 0 for neutral or unknown. + - `score` - -1 for bad, 1 for good, 0 for neutral or unknown. - `/check-all` - Check multiple packages. - ### Analytics This decentralised system leaves a problem of how we track and monitor data. Fundamentally, centralised analytics are at odds with a decentralised system. @@ -160,7 +146,6 @@ Aggregators and repository nodes can still collect their own data, but the use o The analytics concept breaks from AT Proto, which gets "like" and "repost" counts by searching for like/repost events. In a social media context like AT Proto, all actors are public, whereas in our context sites are not public. Using a single, central, neutral service for the common good provides a simple way to fix this, while designing the protocol to not require it if it turns bad. This is not dissimilar to parts of other trust structures, such as [Sigstore's Public Good Instance](https://openssf.org/blog/2023/10/03/running-sigstore-as-a-managed-service-a-tour-of-sigstores-public-good-instance/). - ## Data Each package has some metadata associated with it, as well as package versions and assets (zips). @@ -177,12 +162,10 @@ Similar to other package management systems, we could use (reverse) DNS, e.g. or This is easier and doesn't involve any central service, but is harder to use for small developers who may not have a domain yet. It also does not retain portability through renaming, so the ID may forever contain a fixed name - which can bring trademark concerns. - #### UUIDs We could use standalone unique IDs, like UUIDs. This would give us a concept of global uniqueness, but we wouldn't be able to prove the provenance of any ID - anyone could use any ID. - #### DIDs Using the W3C Distributed ID (DID) standard, we could make packages portable across Repository Nodes. @@ -193,7 +176,6 @@ For example, I might install a plugin "Toast SEO", which has the internal ID of We could also support the did:web: method, which does use DNS - this would give that as a possibility too. This uses a combination of DNS with a /.well-known/did.json endpoint which any site could implement. This is lacking data portability, but we could support both to let people pick whichever they prefer. - ### Signatures Signatures likely need to be tied to IDs in some regard to bootstrap the web of trust. @@ -202,34 +184,30 @@ Using either DIDs or DNS, we can likely store public keys in a publicly accessib We should likely look at a service like [Sigstore](https://www.sigstore.dev/) for signature storage - this is also how GitHub package signing works. - ## Examples Here are some examples as to how the system works. - ### Search and Install a Plugin In this scenario, a user is looking for a plugin, but doesn't know where to find it. They contact their discovery aggregator to find it. Since the discovery aggregator pulls analytics data periodically, it would be updated with the newest releases. -![](./initial-scenario-search-install.png) +![Graph of FAIR's initial Search and Install scenario](./initial-scenario-search-install.png) The Discovery node never knows which package was selected, but can still recommend more-frequently-used plugins using the analytics data. The Analytics node has no direct influence or control, but can assist the Discovery node - the Discovery node can also ignore it if it turns bad. - ### Check and Update a Plugin In this scenario, a user has a plugin and wants to check for updates. They contact the repository node (DistA) to check for updates. -![](./initial-scenario-update.png) +![Graph of FAIR's initial Update scenario](./initial-scenario-update.png) The Discovery node is not involved at all, meaning the distributor has full control - they can't be hijacked. - ### Positive and Negative Moderation In this scenario, a user is about to install several packages. They have two moderation aggregators enabled: a developer verification (VerifyMod) and a security scanning tool (SecurityMod). -![](./initial-scenario-moderation.png) +![Graph of FAIR's initial Moderation scenario](./initial-scenario-moderation.png) diff --git a/docs/moderation/FAIR-APPROVAL-POLICIES.md b/docs/moderation/FAIR-APPROVAL-POLICIES.md index 813193f..ff3cb78 100644 --- a/docs/moderation/FAIR-APPROVAL-POLICIES.md +++ b/docs/moderation/FAIR-APPROVAL-POLICIES.md @@ -1,9 +1,9 @@ # FAIR Approval and Governance Policies -| | | -|----------|------------| +| | | +|----------|-----------------| | Status | Policy Document | -| Date | 2025-01-27 | +| Date | 2025-01-27 | ## Executive Summary @@ -105,16 +105,19 @@ This ensures that community concerns are addressed proportionally while preventi ### Defederation Process Defederation removes a participant from the FAIR discovery and recommendation systems and does the following: + - Prevents _new_ sites from discovering packages from defederated Repositories - Removes defederated Aggregators from FAIR's discovery services - Excludes defederated participants from federation-wide moderation and trust systems Bear in mind that being defederated will _not_: + - Remove packages from individual sites that already have them installed - Disable or shut down the defederated server - Affect existing installations or functionality **Some Reasons for Defederation:** + - Confirmed malware or malicious code - Critical security vulnerabilities with active exploitation - Copyright violations with valid takedown requests @@ -156,12 +159,14 @@ FAIR will not intervene in Repository-specific decisions about package hosting o FAIR takes full responsibility for all defederation decisions it makes regarding Repositories and Aggregators. When FAIR defederates a participant, we provide a transparent appeals process to ensure fairness and due process. The scope of the appeals process covers: + - FAIR-initiated defederation decisions - FAIR-applied moderation labels that result in widespread consequences - Decisions made by FAIR working groups - Policy enforcement actions taken by FAIR **What Appeals Do Not Cover:** + - Repository-specific decisions about individual packages - Aggregator-specific listing decisions - Third-party service decisions @@ -206,24 +211,28 @@ All policy decisions are thoroughly documented and made publicly available to en This timeline is a loose idea of the directions to take: **Phase 1 (Immediate):** + - Create robust documentation about the moderation system - Determine if a started Working Group is needed - Policy documentation and communication **Phase 2 (3 months):** + - Working group formation and training - Integration requirements enforcement **Phase 3 (6 months):** + - Automated compliance monitoring - Appeal process implementation - Transparency reporting systems **Phase 4 (9 months):** + - Performance metrics implementation - Policy refinement based on experience - Community feedback integration --- -*This document is a living policy that will be updated based on community feedback and evolving requirements. All changes are subject to public review and comment periods.* +_This document is a living policy that will be updated based on community feedback and evolving requirements. All changes are subject to public review and comment periods._ diff --git a/docs/moderation/README.md b/docs/moderation/README.md index cb3f650..e1abfdf 100644 --- a/docs/moderation/README.md +++ b/docs/moderation/README.md @@ -1,6 +1,6 @@ # Moderation in the FAIR Ecosystem -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | diff --git a/docs/moderation/discovery.md b/docs/moderation/discovery.md index d18eb33..a8c578c 100644 --- a/docs/moderation/discovery.md +++ b/docs/moderation/discovery.md @@ -1,6 +1,6 @@ # Discovery in a Decentralized System -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -17,6 +17,6 @@ Any Aggregator may choose to list Repositories and packages from the federation. This decentralized structure encourages diversity while maintaining compatibility through the FAIR Protocol. See also: -* [Service Hierarcy →](service-hierarchy.md) -* [Submissions →](./submissions/README.md) +- [Service Hierarcy →](service-hierarchy.md) +- [Submissions →](./submissions/README.md) diff --git a/docs/moderation/faq.md b/docs/moderation/faq.md index 6006770..ec20606 100644 --- a/docs/moderation/faq.md +++ b/docs/moderation/faq.md @@ -1,6 +1,6 @@ # Frequently Asked Questions -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -48,7 +48,7 @@ Labels are digital tags applied to plugins, themes, Repositories, or Aggregators * **For Developers/Operators:** Labels can reflect the status or reputation of your plugin, Repository, or Aggregator. Positive labels can build trust, while negative ones (e.g., `repository:non-compliant`) might indicate issues you need to address. Persistent negative labels from reputable labelers could affect your discoverability. -You can learn more about the system in [Ozone Labeling System](./ozone-labeling-system.md) and Services](./governance-services.md). +You can learn more about the system in [Ozone Labeling System](./ozone-labeling-system.md) and [Services](./governance-services.md). ## Can I run my own Aggregator? What's involved? @@ -66,9 +66,9 @@ Running an Aggregator comes with responsibilities to maintain transparency and c A **Federation Monitor** is a service that acts as an independent, trusted recipient for copies of reports filed within the FAIR network (e.g., reports about plugins, Repositories, etc.). Its main purpose is to ensure reports aren't lost or suppressed by a single Repository or Aggregator. -* **As a User:** You generally won't interact directly with a Federation Monitor. When you submit a report through a compliant system, a copy should automatically be sent to a Monitor in the background. -* **As a Repository Operator:** You need to ensure your system forwards reports correctly. -* **As an Aggregator Operator:** You are *required* to ensure your Aggregator is connected to and forwards relevant report data to at least one recognized Federation Monitor. +* **As a User:** You generally won't interact directly with a Federation Monitor. When you submit a report through a compliant system, a copy should automatically be sent to a Monitor in the background. +* **As a Repository Operator:** You need to ensure your system forwards reports correctly. +* **As an Aggregator Operator:** You are *required* to ensure your Aggregator is connected to and forwards relevant report data to at least one recognized Federation Monitor. You can find more details in the [Integrity Requirements documentation](./governance/integrity.md#redundant-submissions-and-federation-monitors). @@ -134,24 +134,24 @@ This is a critical question, and understanding your responsibilities is key. **Legal Liability (Copyright, Illegal Content, etc.):** * **You, as the Repository operator, are generally responsible and potentially liable for complying with all applicable laws in your jurisdiction regarding the content you host.** This includes, but is not limited to: - * **Copyright Law:** You are responsible for addressing copyright infringement claims (e.g., through DMCA takedown notices or similar legal processes in your region). Hosting copyrighted material without permission can lead to legal action against you. - * **Other Illegal Content:** Distributing content that is illegal in your jurisdiction (e.g., malware, incitement to violence, child exploitation material) can also result in severe legal consequences for you as the publisher. + * **Copyright Law:** You are responsible for addressing copyright infringement claims (e.g., through DMCA takedown notices or similar legal processes in your region). Hosting copyrighted material without permission can lead to legal action against you. + * **Other Illegal Content:** Distributing content that is illegal in your jurisdiction (e.g., malware, incitement to violence, child exploitation material) can also result in severe legal consequences for you as the publisher. **FAIR's View on Accountability (Within the FAIR Ecosystem):** Within the FAIR protocol's framework, there's a distinction between direct liability for content *behavior* (e.g., a plugin malfunctioning or having a security flaw *after* installation) and accountability for the *systems and processes* around that content on your Repository. * **Accountability for Systems, Signals, and Processes:** - * While FAIR's model encourages developers to be responsible for the code they write, **Repository operators are held accountable by the FAIR community and governance for the systems, signals, and processes by which content is submitted, vetted (according to your Repository's policies), displayed, and discovered on your Repository.** - * This means you are accountable for: - * Implementing and enforcing your Repository's submission and content guidelines. - * How you integrate with FAIR's moderation and labeling systems (e.g., applying labels, responding to threshold warnings). - * Ensuring transparency about your Repository's operations and affiliations. - * Your processes for handling reported issues or takedown requests. - * Adhering to FAIR's integrity requirements (e.g., connecting to Federation Monitors). + * While FAIR's model encourages developers to be responsible for the code they write, **Repository operators are held accountable by the FAIR community and governance for the systems, signals, and processes by which content is submitted, vetted (according to your Repository's policies), displayed, and discovered on your Repository.** + * This means you are accountable for: + * Implementing and enforcing your Repository's submission and content guidelines. + * How you integrate with FAIR's moderation and labeling systems (e.g., applying labels, responding to threshold warnings). + * Ensuring transparency about your Repository's operations and affiliations. + * Your processes for handling reported issues or takedown requests. + * Adhering to FAIR's integrity requirements (e.g., connecting to Federation Monitors). * **Behavior of Hosted Content:** - * FAIR's reporting and labeling systems are designed to help identify and flag problematic content *behavior* (like security vulnerabilities or spammy actions) after it's been distributed. - * If content hosted on your Repository is found to be problematic, your Repository may receive negative labels, and you would be expected to act on such information (e.g., by removing the content or working with the developer, according to your policies and FAIR guidelines). Persistent failure to manage problematic content responsibly can impact your Repository's reputation and standing within the FAIR ecosystem. + * FAIR's reporting and labeling systems are designed to help identify and flag problematic content *behavior* (like security vulnerabilities or spammy actions) after it's been distributed. + * If content hosted on your Repository is found to be problematic, your Repository may receive negative labels, and you would be expected to act on such information (e.g., by removing the content or working with the developer, according to your policies and FAIR guidelines). Persistent failure to manage problematic content responsibly can impact your Repository's reputation and standing within the FAIR ecosystem. **In summary:** @@ -224,20 +224,19 @@ If you have legal questions or concerns about operating your Repository or Aggre Here are some suggestions on how to find appropriate legal counsel: * **Local Bar Associations:** Many regional or national bar associations offer referral services that can help you find lawyers specializing in relevant areas such as: - * Technology Law - * Intellectual Property Law (especially copyright and software licensing) - * Internet Law - * Data Privacy Law (e.g., GDPR, CCPA, PIPEDA) - * Business Law + * Technology Law + * Intellectual Property Law (especially copyright and software licensing) + * Internet Law + * Data Privacy Law (e.g., GDPR, CCPA, PIPEDA) + * Business Law * **Lawyers Specializing in Open Source Software:** Some lawyers and law firms specialize in legal issues surrounding free and open source software (FOSS). Searching for legal professionals with this specific expertise might be beneficial, especially concerning licensing. * **Organizations Supporting Digital Rights or Open Source:** While they may not provide direct legal counsel to individuals or businesses in all cases, organizations like: - * The Electronic Frontier Foundation (EFF) - * The Software Freedom Law Center (SFLC) - * Local digital rights groups may have resources, guides, or be able to point you towards lawyers who work in these areas. Some may offer clinics or pro bono services for specific types of cases or clients (often non-profits). + * The Electronic Frontier Foundation (EFF) + * The Software Freedom Law Center (SFLC) + * Local digital rights groups may have resources, guides, or be able to point you towards lawyers who work in these areas. Some may offer clinics or pro bono services for specific types of cases or clients (often non-profits). * **Referrals:** If you know other individuals or organizations operating similar services, they might be able to refer you to legal professionals they have worked with. When seeking legal advice, be prepared to discuss the specifics of your Repository or Aggregator, the types of content you plan to host or index, your target audience, and your operational practices. A legal professional can help you understand your specific rights and responsibilities, draft appropriate terms of service and privacy policies, and navigate any legal challenges that may arise. - diff --git a/docs/moderation/governance/README.md b/docs/moderation/governance/README.md index 5fb1dfe..e4d459c 100644 --- a/docs/moderation/governance/README.md +++ b/docs/moderation/governance/README.md @@ -1,6 +1,6 @@ # Governance -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | diff --git a/docs/moderation/governance/appeals.md b/docs/moderation/governance/appeals.md index 9551c0e..b0cfc4e 100644 --- a/docs/moderation/governance/appeals.md +++ b/docs/moderation/governance/appeals.md @@ -1,6 +1,6 @@ # Appeals Process for FAIR Moderation Decisions -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -54,30 +54,30 @@ _Simply disagreeing with the decision is not adequate grounds for appeal: new in ## The Appeals Process 1. **Submission:** - * Appeals must be submitted via the form or published contact information on the FAIR website specifically addressing moderation requests, dispute resolutions and appeals. - * The appeal should be submitted within 60 days of the notification of the decision being appealed. + - Appeals must be submitted via the form or published contact information on the FAIR website specifically addressing moderation requests, dispute resolutions and appeals. + - The appeal should be submitted within 60 days of the notification of the decision being appealed. 2. **Required Information, in FAIR's Preferred Order:** - * Appellant's name and contact information. - * Clear identification of the decision or label being appealed (e.g., Repository URL, DID (if available, else package slug or other identifier), date of decision, specific label). - * A summary of the grounds for appeal consisting of no more than 300 words. - * A detailed explanation of the justifiable grounds for the appeal as listed here. When presenting new information, it will be helpful to note why the information was not available during the initial review process. - * Any available applicable supporting evidence (e.g., logs, screenshots, corrected information). - * The desired outcome of the appeal. - -3. **Review:** - * Appeals will be reviewed by a designated FAIR Appeals Working Group, which whenever reasonably possible will be independent of the body that made the initial decision. - * The Appeals Working Group may request further information from the appellant or other relevant parties. - * The review process will aim to be completed within 60 days, though complex cases may take longer. Appellants will be kept informed of the progress. - -4. **Decision:** - * The Appeals Working Group will issue a written decision, outlining the reasons for upholding, overturning, or modifying the original decision. - * Possible outcomes include: - * **Appeal Declined for Consideration:** Valid grounds for appeal have not been established. - * **Appeal Upheld:** The original decision is overturned or modified. - * **Appeal Partially Upheld:** Parts of the original decision are modified, while others stand. - * **Appeal Denied:** The original decision stands. - * The decision of the Appeals Working Group is typically final. + - Appellant's name and contact information. + - Clear identification of the decision or label being appealed (e.g., Repository URL, DID (if available, else package slug or other identifier), date of decision, specific label). + - A summary of the grounds for appeal consisting of no more than 300 words. + - A detailed explanation of the justifiable grounds for the appeal as listed here. When presenting new information, it will be helpful to note why the information was not available during the initial review process. + - Any available applicable supporting evidence (e.g., logs, screenshots, corrected information). + - The desired outcome of the appeal. + +3. **Review:** + - Appeals will be reviewed by a designated FAIR Appeals Working Group, which whenever reasonably possible will be independent of the body that made the initial decision. + - The Appeals Working Group may request further information from the appellant or other relevant parties. + - The review process will aim to be completed within 60 days, though complex cases may take longer. Appellants will be kept informed of the progress. + +4. **Decision:** + - The Appeals Working Group will issue a written decision, outlining the reasons for upholding, overturning, or modifying the original decision. + - Possible outcomes include: + - **Appeal Declined for Consideration:** Valid grounds for appeal have not been established. + - **Appeal Upheld:** The original decision is overturned or modified. + - **Appeal Partially Upheld:** Parts of the original decision are modified, while others stand. + - **Appeal Denied:** The original decision stands. + - The decision of the Appeals Working Group is typically final. ## Transparency and the Appeals Viewer diff --git a/docs/moderation/governance/contact-and-privacy.md b/docs/moderation/governance/contact-and-privacy.md index 2813cb2..6a15936 100644 --- a/docs/moderation/governance/contact-and-privacy.md +++ b/docs/moderation/governance/contact-and-privacy.md @@ -1,6 +1,6 @@ # Contact and Privacy Requirements -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -61,4 +61,3 @@ This includes: Integration with Ozone enables real-time coordination between federation participants, allowing FAIR and other Aggregators to track abuse reports, verify identities, and ensure that moderation actions are visible and enforceable across the network. Failure to implement or maintain this integration will be treated as a breach of federation protocol and may lead to delisting or defederation. - diff --git a/docs/moderation/governance/defederation.md b/docs/moderation/governance/defederation.md index 5b3191e..aacd7b4 100644 --- a/docs/moderation/governance/defederation.md +++ b/docs/moderation/governance/defederation.md @@ -1,9 +1,9 @@ # Defederation and Removal Policy -| | | -|----------|------------| +| | | +|----------|-----------------| | Status | Policy Document | -| Date | 2025-01-27 | +| Date | 2025-01-27 | ## Executive Summary @@ -22,17 +22,20 @@ This document defines FAIR's comprehensive policy for removing participants, con ### 1. Content-Level Removal (Packages, Themes, Plugins) **Immediate Removal Criteria:** + - Confirmed malware or malicious code - Critical security vulnerabilities with active exploitation - Copyright violations with valid takedown requests - Illegal content as defined by applicable law **Graduated Removal Process:** + - **Warning Level**: Minor policy violations, security concerns - **Suspension Level**: Repeated violations, moderate security issues - **Removal Level**: Persistent violations, serious security issues **Required Documentation:** + - Specific violation description - Evidence supporting the decision - Date and time of removal @@ -42,6 +45,7 @@ This document defines FAIR's comprehensive policy for removing participants, con ### 2. Repository-Level Removal **Immediate Defederation Criteria:** + - Persistent failure to respond to security incidents - Repeated hosting of malicious content - Failure to maintain required contact information @@ -49,11 +53,13 @@ This document defines FAIR's comprehensive policy for removing participants, con - Refusal to integrate with Ozone moderation system **Graduated Defederation Process:** + - **Warning (7 days)**: First policy violation, technical issues - **Suspension (30 days)**: Repeated violations, failure to remediate - **Defederation (permanent)**: Persistent non-compliance, security risks **Required Documentation:** + - Detailed violation report - Timeline of incidents and responses - Communication attempts with operators @@ -63,12 +69,14 @@ This document defines FAIR's comprehensive policy for removing participants, con ### 3. Aggregator-Level Removal **Immediate Defederation Criteria:** + - Failure to maintain moderation standards - Persistent listing of defederated repositories - Non-compliance with federation API requirements - Refusal to implement required security measures **Graduated Process:** + - **Warning (14 days)**: Policy violations, technical issues - **Suspension (60 days)**: Repeated violations, failure to remediate - **Defederation (permanent)**: Persistent non-compliance @@ -138,6 +146,7 @@ This document defines FAIR's comprehensive policy for removing participants, con ### Reinstatement Process **Eligibility Requirements:** + - Demonstrated remediation of violations - Implementation of required security measures - Compliance with all federation policies @@ -145,6 +154,7 @@ This document defines FAIR's comprehensive policy for removing participants, con - Payment of any required fees or penalties **Reinstatement Process:** + - Formal application with evidence of compliance - Technical review by Security Working Group - Policy review by Vetting Working Group @@ -190,12 +200,14 @@ This document defines FAIR's comprehensive policy for removing participants, con ### Critical Security Incidents **Immediate Action Required:** + - Zero-day vulnerabilities with active exploitation - Confirmed supply chain attacks - Large-scale security breaches - Regulatory compliance failures **Emergency Process:** + - Immediate suspension by Security Working Group - Notification to all federation participants - Public security advisory within 24 hours @@ -227,16 +239,19 @@ This document defines FAIR's comprehensive policy for removing participants, con ## Implementation Timeline ### Phase 1 (Immediate) + - Policy communication and training - Working group formation - Monitoring system implementation ### Phase 2 (30 days) + - Automated violation detection - Warning system implementation - Appeal process establishment ### Phase 3 (90 days) + - Full defederation capability - Performance metrics implementation - Policy refinement based on experience diff --git a/docs/moderation/governance/integrity.md b/docs/moderation/governance/integrity.md index 5adcf06..44ae18f 100644 --- a/docs/moderation/governance/integrity.md +++ b/docs/moderation/governance/integrity.md @@ -1,6 +1,6 @@ # Integrity and Transparency Requirements -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -22,39 +22,39 @@ To ensure the highest level of transparency and allow users to make informed dec Open disclosure of these relationships is essential for: -* User Trust: Users can better assess the neutrality and motivations behind listings and recommendations. -* Fair Competition: It prevents hidden advantages and ensures that merit and quality can be more fairly judged. -* Preventing Deception: It guards against practices that could mislead users into believing endorsements are purely organic when they are commercially influenced. +- User Trust: Users can better assess the neutrality and motivations behind listings and recommendations. +- Fair Competition: It prevents hidden advantages and ensures that merit and quality can be more fairly judged. +- Preventing Deception: It guards against practices that could mislead users into believing endorsements are purely organic when they are commercially influenced. This principle is vital for maintaining user trust and ensuring a level playing field within the FAIR ecosystem. -### Specific Disclosure Requirements: +### Specific Disclosure Requirements -* **Paid Listings or Preferential Treatment:** - * **By Aggregators:** If an Aggregator receives payment from a Repository for inclusion in its listings, for preferential placement (e.g., "featured," "sponsored"), or for any other form of paid promotion, this relationship **must** be clearly and conspicuously disclosed by the Aggregator. - * **By Repositories:** If a Repository receives payment from a plugin/theme author/developer for hosting their package, for preferential display on the Repository, or for any other form of paid promotion, this **must** be clearly and conspicuously disclosed by the Repository. - * In both cases, this disclosure should be visible alongside the relevant listing(s) and in a dedicated, easily accessible section detailing all such arrangements. -* **Sponsorship of Infrastructure or Operations:** If server hosting, significant operational costs, or development are sponsored or paid for by a third-party entity (especially if that entity also participates in or benefits from the FAIR ecosystem, such as a commercial plugin company, hosting provider, or another Repository/Aggregator), this sponsorship **must** be disclosed, **naming** the sponsoring entity and the nature of the support provided. -* **Other Material Affiliations:** Any other affiliations or relationships (e.g., common ownership between a Repository and an Aggregator, significant investment by an ecosystem participant in another) that could reasonably be perceived by users as a potential conflict of interest or a source of bias **must** be disclosed. +- **Paid Listings or Preferential Treatment:** + - **By Aggregators:** If an Aggregator receives payment from a Repository for inclusion in its listings, for preferential placement (e.g., "featured," "sponsored"), or for any other form of paid promotion, this relationship **must** be clearly and conspicuously disclosed by the Aggregator. + - **By Repositories:** If a Repository receives payment from a plugin/theme author/developer for hosting their package, for preferential display on the Repository, or for any other form of paid promotion, this **must** be clearly and conspicuously disclosed by the Repository. + - In both cases, this disclosure should be visible alongside the relevant listing(s) and in a dedicated, easily accessible section detailing all such arrangements. +- **Sponsorship of Infrastructure or Operations:** If server hosting, significant operational costs, or development are sponsored or paid for by a third-party entity (especially if that entity also participates in or benefits from the FAIR ecosystem, such as a commercial plugin company, hosting provider, or another Repository/Aggregator), this sponsorship **must** be disclosed, **naming** the sponsoring entity and the nature of the support provided. +- **Other Material Affiliations:** Any other affiliations or relationships (e.g., common ownership between a Repository and an Aggregator, significant investment by an ecosystem participant in another) that could reasonably be perceived by users as a potential conflict of interest or a source of bias **must** be disclosed. -### Method of Disclosure: +### Method of Disclosure Disclosure information must be: -* Clear and Conspicuous: Not hidden in fine print or obscure locations. -* Easily Accessible: Users should not have to hunt for this information. -* Machine-Readable: Where feasible, such disclosures should also be available in a machine-readable format as part of the Repository's or Aggregator's metadata API, allowing tools and other services to surface this information. For example, a `sponsored: true` flag or an `affiliations` array in metadata. -* Typically Provided On: - * A dedicated "About Us," "Disclosure," "Sponsorship," or "Transparency" page on the Repository or Aggregator's public-facing website/interface. - * Directly on or adjacent to listings if the disclosure pertains to a specific item (e.g., a "Sponsored Listing" badge). +- Clear and Conspicuous: Not hidden in fine print or obscure locations. +- Easily Accessible: Users should not have to hunt for this information. +- Machine-Readable: Where feasible, such disclosures should also be available in a machine-readable format as part of the Repository's or Aggregator's metadata API, allowing tools and other services to surface this information. For example, a `sponsored: true` flag or an `affiliations` array in metadata. +- Typically Provided On: + - A dedicated "About Us," "Disclosure," "Sponsorship," or "Transparency" page on the Repository or Aggregator's public-facing website/interface. + - Directly on or adjacent to listings if the disclosure pertains to a specific item (e.g., a "Sponsored Listing" badge). -### Consequences of Non-Disclosure: +### Consequences of Non-Disclosure Failure to adequately disclose such material affiliations and financial interests will be considered a breach of FAIR's integrity standards. This may lead to: -* A formal warning from FAIR. -* The Repository or Aggregator being flagged as "Lacking Transparency" by FAIR's official Aggregator or other community tools. -* Persistent or egregious non-disclosure may result in a review for suspension or delisting from FAIR's official Aggregator and potential defederation warnings issued to the community. +- A formal warning from FAIR. +- The Repository or Aggregator being flagged as "Lacking Transparency" by FAIR's official Aggregator or other community tools. +- Persistent or egregious non-disclosure may result in a review for suspension or delisting from FAIR's official Aggregator and potential defederation warnings issued to the community. ## Signed and Auditable Logs @@ -72,9 +72,9 @@ To further bolster the integrity of moderation decisions originating from FAIR i This involves: -* **Signed Records:** Key moderation events (e.g., formal warnings, suspensions, delistings initiated by FAIR, or the application of critical FAIR-issued labels) will be recorded as cryptographically signed, verifiable entries. -* **Publicly Auditable:** These signed records can be published to a distributed ledger or a system built on technologies like the AT Protocol graph. This makes FAIR's own moderation interventions transparent and available for public audit. -* **Contribution to System Integrity:** By making its own oversight actions verifiable and difficult to tamper with, FAIR not only ensures accountability for its role but also provides a trusted dataset that other participants in the ecosystem can reference. This complements the requirements for individual Repositories and Aggregators to maintain their own logs. +- **Signed Records:** Key moderation events (e.g., formal warnings, suspensions, delistings initiated by FAIR, or the application of critical FAIR-issued labels) will be recorded as cryptographically signed, verifiable entries. +- **Publicly Auditable:** These signed records can be published to a distributed ledger or a system built on technologies like the AT Protocol graph. This makes FAIR's own moderation interventions transparent and available for public audit. +- **Contribution to System Integrity:** By making its own oversight actions verifiable and difficult to tamper with, FAIR not only ensures accountability for its role but also provides a trusted dataset that other participants in the ecosystem can reference. This complements the requirements for individual Repositories and Aggregators to maintain their own logs. The mechanisms for creating and distributing these signed moderation records, including how they relate to the broader label-based system, are detailed further in the [Ozone Labeling System documentation](../ozone-labeling-system.md). This approach ensures that even FAIR's own interventions are subject to scrutiny, reinforcing the overall integrity of the federated ecosystem. @@ -98,8 +98,8 @@ A **Federation Monitor** (or "Monitor") is a designated, trusted service whose p - **Requirement for Aggregators:** All Aggregators participating in the FAIR ecosystem **must** be configured to forward copies of relevant reports they process or receive to at least one FAIR-recognized Federation Monitor. - **Public List of Recognized Monitors:** FAIR will maintain and publish a list of recognized Federation Monitor services. This list will be: - - Publicly accessible and machine-readable (e.g., via a JSON API endpoint like `GET /fair/v1/monitors`). - - Provide necessary details for each Monitor, such as its name, report submission API endpoint, and public key if applicable. + - Publicly accessible and machine-readable (e.g., via a JSON API endpoint like `GET /fair/v1/monitors`). + - Provide necessary details for each Monitor, such as its name, report submission API endpoint, and public key if applicable. - **FAIR's Default Usage:** The official FAIR Aggregator service(s) will utilize FAIR's own designated Federation Monitor service(s). FAIR's Aggregator and other ecosystem tools may flag or indicate Aggregators that are not verifiably connected to a recognized Monitor, signaling a potential risk or lack of full compliance with integrity standards. - **Purpose:** Monitors serve as an independent receipt point, facilitating audits by FAIR working groups, verifying report acknowledgment, and helping investigate claims of suppression. diff --git a/docs/moderation/governance/moderation-labels.md b/docs/moderation/governance/moderation-labels.md index d962f27..8684bde 100644 --- a/docs/moderation/governance/moderation-labels.md +++ b/docs/moderation/governance/moderation-labels.md @@ -1,6 +1,6 @@ # Moderation Labels -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -14,6 +14,7 @@ This section documents all proposed labels for the FAIR ecosystem, organized by ### FAIR Official Labels #### Threshold-Based Labels + These labels are automatically applied by FAIR's official labeler based on community reporting thresholds: - `fair:threshold:warning25` - Applied when 25% of active users report an issue @@ -22,6 +23,7 @@ These labels are automatically applied by FAIR's official labeler based on commu - `fair:threshold:suspended75` - Applied when 75% of active users report an issue, triggers suspension #### FAIR Governance Labels + Labels applied by FAIR working groups based on policy decisions: - `fair:verified` - Entity has been verified by FAIR @@ -32,6 +34,7 @@ Labels applied by FAIR working groups based on policy decisions: ### Package-Level Labels #### Security and Safety + - `package:malicious` - Package contains malicious code or behavior - `package:vulnerability:active` - Package has active security vulnerabilities - `package:unverified` - Package has not been verified for safety @@ -47,22 +50,26 @@ Labels applied by FAIR working groups based on policy decisions: ### Repository-Level Labels #### Compliance and Trust + - `repository:insecure` - Repository has security issues - `repository:non-compliant` - Repository does not comply with FAIR standards #### Operational Status + - `repository:verified` - Repository has been verified - `repository:trusted` - Repository is trusted by the community ### Aggregator-Level Labels #### Compliance and Trust + - `aggregator:compliant` - Aggregator complies with FAIR standards - `aggregator:trusted` - Aggregator is trusted by the community ### Author/Developer Labels #### Verification + - `author:verified` - Author/developer has been verified - `author:trusted` - Author/developer is trusted by the community @@ -71,48 +78,57 @@ Labels applied by FAIR working groups based on policy decisions: The following are examples of labels that third-party moderation services might implement: #### Security Focus + - `myorg:security:audited` - Package has been security audited by organization - `myorg:security:reviewed` - Package has been reviewed for security #### Accessibility Focus + - `community:focus-accessibility` - Package focuses on accessibility - `wcag:2.2AA` - Package meets WCAG 2.2 AA standards #### Vendor/Organization Labels + - `vendor:verified` - Vendor has been verified - `vendor:official-partner` - Vendor is an official partner - `myorg:custom-label` - Custom label from specific organization #### Community Labels + - `community:trusted` - Trusted by the community ### Label Categories by Impact Level #### Critical (Immediate Action Required) + - `fair:threshold:suspended75` - `fair:defederated` - `package:malicious` - `repository:insecure` #### High Risk (Warning Required) + - `fair:threshold:review60` - `package:security-vulnerability:active` - `repository:non-compliant` - `repository:non-compliant` #### Medium Risk (Notice Required) + - `fair:threshold:notice50` - `package:unverified` - `package:deprecated` - `theme:deprecated` #### Low Risk (Information Only) + - `fair:threshold:warning25` - `plugin:experimental` - `plugin:community-trusted` - `theme:accessibility-reviewed` #### Positive Signals + - `fair:verified` - `fair:security-vetted` - `author:verified` diff --git a/docs/moderation/governance/moderation-services.md b/docs/moderation/governance/moderation-services.md index 6c2241b..ab705d9 100644 --- a/docs/moderation/governance/moderation-services.md +++ b/docs/moderation/governance/moderation-services.md @@ -1,6 +1,6 @@ # Moderation Services and Labelers in FAIR -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -47,24 +47,24 @@ The FAIR ecosystem is designed to support the operation of independent, third-pa A third party wishing to establish their own Moderation Service within the FAIR ecosystem would generally need to: 1. **Define Scope and Criteria:** - * Determine the types of labels they will issue and the clear, consistent criteria for applying them. - * Identify their target audience or the specific value their labels will provide. + - Determine the types of labels they will issue and the clear, consistent criteria for applying them. + - Identify their target audience or the specific value their labels will provide. 2. **Set Up Technical Infrastructure:** - * Implement or deploy a "labeler" application. This could involve: - * Forking and customizing existing open-source Ozone components. - * Developing a custom application that can interact with the AT Protocol or a similar decentralized identity and data framework used by FAIR. - * The service must be able to sign and publish labels associated with DIDs in a way that is consumable by other FAIR participants. - * Ensure the service has a stable, discoverable endpoint (API). + - Implement or deploy a "labeler" application. This could involve: + - Forking and customizing existing open-source Ozone components. + - Developing a custom application that can interact with the AT Protocol or a similar decentralized identity and data framework used by FAIR. + - The service must be able to sign and publish labels associated with DIDs in a way that is consumable by other FAIR participants. + - Ensure the service has a stable, discoverable endpoint (API). 3. **Establish Identity:** - * The Moderation Service should have its own clear identity within the network (e.g., its own DID). This allows consumers of its labels to know who is issuing them. + - The Moderation Service should have its own clear identity within the network (e.g., its own DID). This allows consumers of its labels to know who is issuing them. 4. **Publish Labeling Policies:** - * It is highly recommended (though not mandated by FAIR for independent services) to publicly document the service's labeling policies, criteria, and any dispute resolution mechanisms they offer for their own labels. This builds trust with potential consumers of their labels. + - It is highly recommended (though not mandated by FAIR for independent services) to publicly document the service's labeling policies, criteria, and any dispute resolution mechanisms they offer for their own labels. This builds trust with potential consumers of their labels. 5. **Announce and Promote:** - * Make the FAIR community aware of the new Moderation Service, its purpose, and how to subscribe to its labels. + - Make the FAIR community aware of the new Moderation Service, its purpose, and how to subscribe to its labels. ### Interoperability Considerations diff --git a/docs/moderation/governance/risk-management.md b/docs/moderation/governance/risk-management.md index 45d9e0f..b31eaf0 100644 --- a/docs/moderation/governance/risk-management.md +++ b/docs/moderation/governance/risk-management.md @@ -1,6 +1,6 @@ # Risk Management and Mitigation Strategies -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -64,13 +64,13 @@ The following risks have been identified, and mitigation proposed. In most cases ## Risk Matrix -| Risk | Impact | Likelihood | Mitigation Strategy | -|----------------------------------------------|-----------------------------------------------------------------------------|--------------|-------------------------------------------------------------------------------------------------------------------------------| -| Repository Abandonment or Ownership Transfer | Medium: Users may lose access to updates or inherit a compromised Repository | Medium | Require Repository handoff process with updated contact info, content audit, and FAIR grace period | -| Package Tampering | High: Users may unknowingly install modified or malicious code | High | Implement digital signatures and checksums for all content; require signature verification at the Repository level | -| Malicious Forking or Identity Spoofing | High: User trust and developer reputation undermined | Medium | Recommend use of identity-bound signatures or namespaces; encourage plugin origin metadata | -| Inter-Repository or Inter-Developer Disputes | Medium: Reputation damage, legal risk, or community fragmentation | Low to Medium| FAIR to provide voluntary mediation framework; define conflict escalation paths across Repositories | -| Non-Cooperative Repositories Avoiding Federation Rules | Medium: Inconsistent enforcement weakens trust in federation | Medium | Incentivize federation listing via discovery tools, reputation badges, and optional technical benefits (e.g., CDN, caching) | -| Collapse or Compromise of FAIR Governance | High: Loss of central trust body could destabilize the network | Low | Define governance succession plan and forkable federation structure to ensure continuity under new leadership | -| Directory Manipulation (bias, favoritism) | Medium: Perceived unfairness, erosion of trust | Low | Directories must publish policies for inclusion/removal and log decisions transparently; FAIR to review disputes over abuse | -| Insufficient Incentives to Report Issues | Medium: Under-reporting of dangerous content | Medium | Encourage reporting via built-in tooling, optional anonymity, and user feedback loops to show impact of submitted reports | +| Risk | Impact | Likelihood | Mitigation Strategy | +| --- | --- | --- | --- | +| Repository Abandonment or Ownership Transfer | Medium: Users may lose access to updates or inherit a compromised Repository | Medium | Require Repository handoff process with updated contact info, content audit, and FAIR grace period | +| Package Tampering | High: Users may unknowingly install modified or malicious code | High | Implement digital signatures and checksums for all content; require signature verification at the Repository level | +| Malicious Forking or Identity Spoofing | High: User trust and developer reputation undermined | Medium | Recommend use of identity-bound signatures or namespaces; encourage plugin origin metadata | +| Inter-Repository or Inter-Developer Disputes | Medium: Reputation damage, legal risk, or community fragmentation | Low to Medium | FAIR to provide voluntary mediation framework; define conflict escalation paths across Repositories | +| Non-Cooperative Repositories Avoiding Federation Rules | Medium: Inconsistent enforcement weakens trust in federation | Medium | Incentivize federation listing via discovery tools, reputation badges, and optional technical benefits (e.g., CDN, caching) | +| Collapse or Compromise of FAIR Governance | High: Loss of central trust body could destabilize the network | Low | Define governance succession plan and forkable federation structure to ensure continuity under new leadership | +| Directory Manipulation (bias, favoritism) | Medium: Perceived unfairness, erosion of trust | Low | Directories must publish policies for inclusion/removal and log decisions transparently; FAIR to review disputes over abuse | +| Insufficient Incentives to Report Issues | Medium: Under-reporting of dangerous content | Medium | Encourage reporting via built-in tooling, optional anonymity, and user feedback loops to show impact of submitted reports | diff --git a/docs/moderation/governance/vetting-and-reporting.md b/docs/moderation/governance/vetting-and-reporting.md index b0c509f..e94c302 100644 --- a/docs/moderation/governance/vetting-and-reporting.md +++ b/docs/moderation/governance/vetting-and-reporting.md @@ -1,6 +1,6 @@ -# Vetting and Reporting +# Vetting and Reporting -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -27,11 +27,11 @@ While everyone should be free to submit and host repositories, safeguards are es Each Repository and Aggregator must implement easily accessible reporting features: - **Repositories:** Must provide features visible within the client (package installer or browser interface) interface: - - "Report Package" - - "Report Repository" + - "Report Package" + - "Report Repository" - **Aggregators:** Must include additional reporting features: - - "Report Repository" - - "Report Aggregator" + - "Report Repository" + - "Report Aggregator" These reporting tools must be available to the client from both listing and detail views for packages, Repositories, and Aggregators. For example, the WordPress theme or plugin installer (client) using FAIR should make this information visible to the end user, whether the user is browsing or searching plugins or themes, or reviewing those which are already installed. @@ -56,16 +56,16 @@ Valid reports contribute toward a threshold system that escalates actions based ### Reporting Actions by Threshold - **25%:** - - Automated warning recorded and shown in system logs. + - Automated warning recorded and shown in system logs. - **50%:** - - Notice displayed on all relevant listings. - - Reports forwarded to directory Aggregators. - - “Community Notice” badge shown. + - Notice displayed on all relevant listings. + - Reports forwarded to directory Aggregators. + - “Community Notice” badge shown. - **60%:** - - “Community Notice” escalates to a visible Warning. - - FAIR working group is alerted for manual review. + - “Community Notice” escalates to a visible Warning. + - FAIR working group is alerted for manual review. - **75%:** - - Automated temporary suspension from Repository and Aggregators, pending FAIR decision. + - Automated temporary suspension from Repository and Aggregators, pending FAIR decision. Note on Implementation: These threshold-triggered actions, such as warnings, notices, and suspensions, are implemented and propagated across the decentralized network as "labels." These labels are applied to the relevant Repository, Aggregator, or package. For a detailed explanation of how this labeling system works, including its basis on systems like Ozone, please see the [Ozone Labeling System documentation](../ozone-labeling-system.md). diff --git a/docs/moderation/guidelines.md b/docs/moderation/guidelines.md index 8a521d4..392f29e 100644 --- a/docs/moderation/guidelines.md +++ b/docs/moderation/guidelines.md @@ -1,6 +1,6 @@ # Guidelines for Repositories and Aggregators -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -18,9 +18,10 @@ Content intended for integration with WordPress (such as plugins and themes) is **Consequences of Non-Alignment:** Repositories distributing content for a specific ecosystem that does not align with that ecosystem's prevailing licensing norms (e.g., distributing non-GPLv2 compatible plugins for WordPress) may find: - * Their content is not accepted or listed by Aggregators focused on that ecosystem. - * Their Repository or content is flagged by community tools or labelers as "not recommended" for that specific ecosystem due to licensing incompatibility. - * They face challenges with user adoption and trust within that target community. + +* Their content is not accepted or listed by Aggregators focused on that ecosystem. +* Their Repository or content is flagged by community tools or labelers as "not recommended" for that specific ecosystem due to licensing incompatibility. +* They face challenges with user adoption and trust within that target community. **Repository/Aggregator Responsibility:** @@ -51,17 +52,17 @@ Repositories are expected to have a clearly defined copyright complaint process. To ensure accountability and open communication, all Repositories and Aggregators **must** maintain clear, reliable contact channels and provide transparency in their operations. (See also: [Contact and Privacy](./governance/contact-and-privacy.md) and [Disclosure of Affiliations and Financial Interests](./governance/integrity.md#disclosure-of-affiliations-and-financial-interests)). * **Minimum Requirements:** - * **Public Contact:** Each Repository or Aggregator **must** publish easily accessible public-facing contact information (e.g., a name, organization, website, pseudonym, or properly forwarded email alias). - * **Private Administrative Contact:** Operators **must** maintain private contact details (e.g., an administrative email address or secure contact form) made available to FAIR and other authorized federation participants for: - * Abuse or security incident coordination. - * Compliance checks or moderation escalations. - * Federation audits and integrity verifications. - * Privacy law investigations. + * **Public Contact:** Each Repository or Aggregator **must** publish easily accessible public-facing contact information (e.g., a name, organization, website, pseudonym, or properly forwarded email alias). + * **Private Administrative Contact:** Operators **must** maintain private contact details (e.g., an administrative email address or secure contact form) made available to FAIR and other authorized federation participants for: + * Abuse or security incident coordination. + * Compliance checks or moderation escalations. + * Federation audits and integrity verifications. + * Privacy law investigations. * **Timely Response Obligation:** Operators are expected to respond in a timely manner to: - * Legitimate abuse reports (including copyright infringement notices). - * Inquiries from FAIR working groups or moderation teams. - * Requests for updates or clarifications from other directory maintainers or federation participants. + * Legitimate abuse reports (including copyright infringement notices). + * Inquiries from FAIR working groups or moderation teams. + * Requests for updates or clarifications from other directory maintainers or federation participants. * **Appeals Process (Recommended):** If a Repository or Aggregator hosts user-submitted content or makes moderation decisions, they are strongly encouraged, though not strictly required by FAIR for all cases, to have an appeals process for content removals or other moderation actions they take. FAIR itself will have an appeals process for its own decisions (see [Appeals Process](./appeals.md)). ## 5. Technical Interoperability @@ -84,20 +85,20 @@ If any plugin, theme, Repository, or Aggregator is removed from a listing by a R ## 7. Repository Operator Responsibility for Hosted Content -Repository operators are responsible for the content of the code distributed through their services. This responsibility pertains _only_ to the provenance, licensing, and integrity of the content as it is stored and distributed by their Repository. Repository operators are _not_ liable for the _behavior_ of code they host. +Repository operators are responsible for the content of the code distributed through their services. This responsibility pertains *only* to the provenance, licensing, and integrity of the content as it is stored and distributed by their Repository. Repository operators are *not* liable for the *behavior* of code they host. -For example, a package has the ability to scrape data from websites, and someone complains to the Repository that their package is doing damage to their site. This is _not_ the responsibility of the Repository, but that of the user of said package. +For example, a package has the ability to scrape data from websites, and someone complains to the Repository that their package is doing damage to their site. This is *not* the responsibility of the Repository, but that of the user of said package. * **Scope:** This responsibility covers: - * Packages (plugins, themes, other software, or content of any type) served via the Repository’s API. - * Associated metadata (descriptions, images, documentation, changelogs, etc.). - * Any hosted files made available through discovery tools or client systems originating from the Repository. + * Packages (plugins, themes, other software, or content of any type) served via the Repository’s API. + * Associated metadata (descriptions, images, documentation, changelogs, etc.). + * Any hosted files made available through discovery tools or client systems originating from the Repository. * **Key Responsibilities Include:** - * **Content Vetting & Moderation:** Repository operators **must** have processes to ensure hosted content meets these FAIR guidelines, their own published Repository policies, and applicable local laws. - * **Security:** Repository operators are expected to monitor for and respond to known security issues or malicious submissions within the content they host. - * **Accuracy:** Metadata, versioning, and licensing information provided by the Repository for its hosted content **must** accurately reflect the actual content being served. - * **Removal Compliance:** If content is legitimately flagged or subject to a valid takedown request (e.g., for abuse, licensing violation, copyright infringement, or legal claim), the Repository operator **must** act promptly to address the issue or remove the content as appropriate. - * **Traceability & Cooperation:** Repositories **must** maintain reasonable audit logs of submissions and publishing events and **must** cooperate with FAIR during authorized investigations. Logs must be retained for not less than 120 days at minimum. + * **Content Vetting & Moderation:** Repository operators **must** have processes to ensure hosted content meets these FAIR guidelines, their own published Repository policies, and applicable local laws. + * **Security:** Repository operators are expected to monitor for and respond to known security issues or malicious submissions within the content they host. + * **Accuracy:** Metadata, versioning, and licensing information provided by the Repository for its hosted content **must** accurately reflect the actual content being served. + * **Removal Compliance:** If content is legitimately flagged or subject to a valid takedown request (e.g., for abuse, licensing violation, copyright infringement, or legal claim), the Repository operator **must** act promptly to address the issue or remove the content as appropriate. + * **Traceability & Cooperation:** Repositories **must** maintain reasonable audit logs of submissions and publishing events and **must** cooperate with FAIR during authorized investigations. Logs must be retained for not less than 120 days at minimum. Claims such as “a user uploaded this” or “we just mirrored it without review” do not absolve a Repository operator of their responsibilities for the content they choose to distribute within the FAIR federation. Repository operators who fail to take adequate ownership of their distributed content may be subject to warnings, negative labeling, review by FAIR working groups, or delisting/defederation actions. @@ -106,12 +107,12 @@ Claims such as “a user uploaded this” or “we just mirrored it without revi While Aggregator servers do not host plugin or theme package files directly, they are responsible for the integrity, accuracy, availability, and security of their listing infrastructure and any metadata they aggregate, display, or generate. * **Key Responsibilities Include:** - * **Listing Integrity:** Aggregators **must** strive to accurately reflect the content, metadata, and moderation status (including labels) of the Repositories and packages they index. - * **Infrastructure Maintenance:** Aggregators **must** maintain secure, compliant, and interoperable infrastructure, adhering to FAIR API specifications. - * **Security Practices:** Aggregators are responsible for contributing to a secure and trustworthy discovery layer. - * **Transparency of Listing Policies:** Aggregators **must** provide clear public policies on how they select Repositories for inclusion/exclusion and how they curate their listings. - * **Disclosure of Sponsorship/Affiliation:** Any sponsored listings, promoted placements, or material affiliations **must** be clearly disclosed to users (see [Disclosure of Affiliations and Financial Interests](./integrity.md#disclosure-of-affiliations-and-financial-interests)). - * **Timely Updates & Syncing:** Aggregators **must** routinely synchronize with participating Repositories and accurately reflect additions, removals, or changes in status, including acting upon FAIR-issued defederation notices or critical labels. + * **Listing Integrity:** Aggregators **must** strive to accurately reflect the content, metadata, and moderation status (including labels) of the Repositories and packages they index. + * **Infrastructure Maintenance:** Aggregators **must** maintain secure, compliant, and interoperable infrastructure, adhering to FAIR API specifications. + * **Security Practices:** Aggregators are responsible for contributing to a secure and trustworthy discovery layer. + * **Transparency of Listing Policies:** Aggregators **must** provide clear public policies on how they select Repositories for inclusion/exclusion and how they curate their listings. + * **Disclosure of Sponsorship/Affiliation:** Any sponsored listings, promoted placements, or material affiliations **must** be clearly disclosed to users (see [Disclosure of Affiliations and Financial Interests](./integrity.md#disclosure-of-affiliations-and-financial-interests)). + * **Timely Updates & Syncing:** Aggregators **must** routinely synchronize with participating Repositories and accurately reflect additions, removals, or changes in status, including acting upon FAIR-issued defederation notices or critical labels. Aggregators are accountable for the systems, signals, and processes by which content is displayed and discovered through their service. Failure to uphold these responsibilities may result in delisting from FAIR's official Aggregator index, negative labeling, or federation warnings. @@ -120,12 +121,12 @@ Aggregators are accountable for the systems, signals, and processes by which con All participants **must** be diligent in keeping their infrastructure secure, trustworthy, and resistant to tampering. * **This includes:** - * Regularly auditing platforms for unauthorized access, manipulation, or misconfigurations. - * Ensuring metadata integrity, ideally by pulling information directly from verified sources or using cryptographic verification where available. - * Promptly removing or delisting (for Aggregators) or ceasing distribution of (for Repositories) any content found to be distributing malware, actively exploiting users, or containing unaddressed critical security vulnerabilities. - * Respecting and acting upon FAIR-issued security advisories, defederation notices, and verified abuse reports. - * Respecting and acting upon notifications from legal authorities or their representatives regarding infringement or illegal content they host or list. - * Not facilitating or indirectly enabling the continued availability of unsafe content through negligence or undue delay. + * Regularly auditing platforms for unauthorized access, manipulation, or misconfigurations. + * Ensuring metadata integrity, ideally by pulling information directly from verified sources or using cryptographic verification where available. + * Promptly removing or delisting (for Aggregators) or ceasing distribution of (for Repositories) any content found to be distributing malware, actively exploiting users, or containing unaddressed critical security vulnerabilities. + * Respecting and acting upon FAIR-issued security advisories, defederation notices, and verified abuse reports. + * Respecting and acting upon notifications from legal authorities or their representatives regarding infringement or illegal content they host or list. + * Not facilitating or indirectly enabling the continued availability of unsafe content through negligence or undue delay. Participation implies a duty to protect users from malicious code, compromised infrastructure, and ecosystem-level threats. Failure to maintain secure systems may result in FAIR investigation, temporary suspension, negative labeling, or defederation. @@ -134,12 +135,12 @@ Participation implies a duty to protect users from malicious code, compromised i To protect users and preserve trust, no Aggregator or Repository may knowingly list, distribute, or facilitate access to content that is confirmed to compromise user safety or engage in malicious activities. * **This includes, but is not limited to:** - * Packages containing malware, backdoors, undisclosed trackers, or unpatched critical security vulnerabilities. - * Repositories that consistently or knowingly distribute unpatched, dangerous, or intentionally harmful code. - * Content authoritatively flagged and verified by FAIR or other widely trusted security bodies as malicious or legally actionable. + * Packages containing malware, backdoors, undisclosed trackers, or unpatched critical security vulnerabilities. + * Repositories that consistently or knowingly distribute unpatched, dangerous, or intentionally harmful code. + * Content authoritatively flagged and verified by FAIR or other widely trusted security bodies as malicious or legally actionable. * **Responsibilities:** - * **Aggregators must** delist any Repository or package that is reliably verified to distribute harmful content, even if the Aggregator does not host the code itself. - * **Repositories must** remove or suspend access to any plugin or theme hosted on their platform that is identified as malicious, imminently dangerous, or in critical violation of federation safety standards. + * **Aggregators must** delist any Repository or package that is reliably verified to distribute harmful content, even if the Aggregator does not host the code itself. + * **Repositories must** remove or suspend access to any plugin or theme hosted on their platform that is identified as malicious, imminently dangerous, or in critical violation of federation safety standards. Failure to act within a reasonable timeframe after credible notification may result in defederation from FAIR systems and removal from federation discovery services. Federation participants are expected to be proactive, not passive mirrors, when faced with credible, verified safety issues. @@ -148,11 +149,11 @@ Failure to act within a reasonable timeframe after credible notification may res FAIR operates as a standards body, a provider of default discovery services (e.g., a FAIR-operated Aggregator), an issuer of trust signals (via its Labeler Service), and an oversight facilitator. However, FAIR does not govern or control the internal day-to-day operations of independent federation participants. * **This means:** - * Repositories and Aggregators are autonomous and independently operated entities. They are solely responsible for their own actions, the content they distribute or list, their adherence to local laws, and their own terms of service. - * FAIR provides guidelines, coordination mechanisms, and escalation frameworks but **does not and cannot guarantee** the safety, legality, quality, or functionality of any individual software package or other content, Repository, or Aggregator within the broader federation. + * Repositories and Aggregators are autonomous and independently operated entities. They are solely responsible for their own actions, the content they distribute or list, their adherence to local laws, and their own terms of service. + * FAIR provides guidelines, coordination mechanisms, and escalation frameworks but **does not and cannot guarantee** the safety, legality, quality, or functionality of any individual software package or other content, Repository, or Aggregator within the broader federation. * **FAIR is not liable for:** - * Harm caused by software or other content obtained from or listed by participating Repositories or Aggregators. - * The specific inclusion, removal, or moderation decisions made by independent third-party Repository or Aggregator operators. - * Legal violations or compliance failures by individual federation members. + * Harm caused by software or other content obtained from or listed by participating Repositories or Aggregators. + * The specific inclusion, removal, or moderation decisions made by independent third-party Repository or Aggregator operators. + * Legal violations or compliance failures by individual federation members. Each federation participant assumes full responsibility for its own actions and operations. FAIR’s role is primarily advisory, standard-setting, and facilitative, taking no role in legal regulation over independent entities. diff --git a/docs/moderation/ozone-labeling-system.md b/docs/moderation/ozone-labeling-system.md index 7c3b0fc..f9f315d 100644 --- a/docs/moderation/ozone-labeling-system.md +++ b/docs/moderation/ozone-labeling-system.md @@ -1,6 +1,6 @@ # FAIR's Label-Based Moderation System with Ozone -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -36,25 +36,25 @@ The philosophy behind Ozone aligns well with FAIR's goals for a decentralized ec FAIR will leverage Ozone's capabilities in the following ways: 1. **FAIR as a Labeling Authority:** - * FAIR (or designated working groups within FAIR) will operate one or more "labeler" services built upon Ozone. - * These services will issue labels relevant to the FAIR ecosystem, such as: - * `package:malicious` - * `package:unverified` - * `package:deprecated` - * `repository:insecure` - * `repository:non-compliant` - * `aggregator:compliant` - * `author:verified` - * `fair:verified` - * These and other labels will be publicly queryable and attached to the Decentralized Identifiers (DIDs) of Repositories, Aggregators, or developer identities. + - FAIR (or designated working groups within FAIR) will operate one or more "labeler" services built upon Ozone. + - These services will issue labels relevant to the FAIR ecosystem, such as: + - `package:malicious` + - `package:unverified` + - `package:deprecated` + - `repository:insecure` + - `repository:non-compliant` + - `aggregator:compliant` + - `author:verified` + - `fair:verified` + - These and other labels will be publicly queryable and attached to the Decentralized Identifiers (DIDs) of Repositories, Aggregators, or developer identities. 2. **Transparency Ledger for Moderation Actions:** - * FAIR’s working groups (e.g., for Security, Vetting, or future Appeals) could publish signed moderation records as ATProto data. - * Each significant moderation event (e.g., a warning issued, a suspension, a guideline violation finding) becomes a verifiable label event, potentially including metadata about the decision. This contributes to the integrity of the moderation process (see also [Integrity and Transparency Requirements](./governance/integrity.md)). + - FAIR’s working groups (e.g., for Security, Vetting, or future Appeals) could publish signed moderation records as ATProto data. + - Each significant moderation event (e.g., a warning issued, a suspension, a guideline violation finding) becomes a verifiable label event, potentially including metadata about the decision. This contributes to the integrity of the moderation process (see also [Integrity and Transparency Requirements](./governance/integrity.md)). 3. **Aggregator-Level Enforcement and Filtering:** - * FAIR Aggregators, and potentially third-party aggregators, can choose which labelers to trust (e.g., FAIR's official labeler or other community-recognized labelers). - * Based on subscribed labels, Aggregators can implement their filtering policies (e.g., hide items labeled `package:malicious`, warn about `repository:insecure`, or boost `author:verified` content). This maintains federation while allowing directories to apply moderation in a composable, client-controlled way. + - FAIR Aggregators, and potentially third-party aggregators, can choose which labelers to trust (e.g., FAIR's official labeler or other community-recognized labelers). + - Based on subscribed labels, Aggregators can implement their filtering policies (e.g., hide items labeled `package:malicious`, warn about `repository:insecure`, or boost `author:verified` content). This maintains federation while allowing directories to apply moderation in a composable, client-controlled way. _End users may choose to subscribe to Aggregators which best align with their own moderation preferences._ @@ -67,14 +67,14 @@ Ozone itself does not implement threshold-specific rules directly within its cor 1. **Build a FAIR-Specific Labeler Service:** This service will use Ozone's infrastructure but incorporate FAIR’s specific reporting and escalation logic. 2. **Monitor Report Metrics:** The FAIR labeler will track report volume and the percentage of active users reporting an item, as defined in the reporting policy. 3. **Apply Escalation Labels:** Based on the defined thresholds, the FAIR labeler will automatically apply specific, clearly defined labels, such as: - * `fair:threshold:warning25` (when 25% threshold is met) - * `fair:threshold:notice50` (when 50% threshold is met) - * `fair:threshold:review60` (when 60% threshold is met, signaling need for manual review) - * `fair:threshold:suspended75` (when 75% threshold is met) + - `fair:threshold:warning25` (when 25% threshold is met) + - `fair:threshold:notice50` (when 50% threshold is met) + - `fair:threshold:review60` (when 60% threshold is met, signaling need for manual review) + - `fair:threshold:suspended75` (when 75% threshold is met) 4. **Actioning Escalation Labels:** These `fair:threshold:*` labels will then be used by: - * **Aggregators:** To automatically show/hide content, display warnings, or temporarily delist items. - * **Package Installers (e.g., Clients like the FAIR Plugin for WordPress):** To notify end-users and site administrators of the status of plugins/themes or Repositories they interact with. - * **FAIR Review Dashboards:** To alert FAIR working groups to items requiring manual review or decision-making. + - **Aggregators:** To automatically show/hide content, display warnings, or temporarily delist items. + - **Package Installers (e.g., Clients like the FAIR Plugin for WordPress):** To notify end-users and site administrators of the status of plugins/themes or Repositories they interact with. + - **FAIR Review Dashboards:** To alert FAIR working groups to items requiring manual review or decision-making. 5. **Audit Log:** Optionally, the FAIR labeler service will write to a publicly auditable log (e.g., as ATProto repository posts or signed JSON records) each time a threshold-based label is applied, further enhancing transparency. ## Supporting Technical Components diff --git a/docs/moderation/service-hierarchy.md b/docs/moderation/service-hierarchy.md index a49f801..01ac63f 100644 --- a/docs/moderation/service-hierarchy.md +++ b/docs/moderation/service-hierarchy.md @@ -1,6 +1,6 @@ # Service Hierarchy -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -8,15 +8,18 @@ FAIR's discovery system operates on multiple levels: ## Repositories + - Host and distribute actual package files - Primary content storage layer ## Aggregators + - Index and list Repositories and their packages - Provide search and discovery interfaces - Can list other Aggregators (recursive) ## Discovery Services + - Higher-level directories that aggregate multiple Aggregators - Enable ecosystem stakeholders to create unified search experiences - Examples: Hosting companies, CMS vendors, large developer communities diff --git a/docs/moderation/submissions/README.md b/docs/moderation/submissions/README.md index 1c283ae..2dcc7a2 100644 --- a/docs/moderation/submissions/README.md +++ b/docs/moderation/submissions/README.md @@ -1,6 +1,6 @@ # Submissions -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | diff --git a/docs/moderation/submissions/aggregators.md b/docs/moderation/submissions/aggregators.md index 86d5600..c51cd1d 100644 --- a/docs/moderation/submissions/aggregators.md +++ b/docs/moderation/submissions/aggregators.md @@ -1,6 +1,6 @@ # Submitting Aggregators to a Discovery Service -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | diff --git a/docs/moderation/submissions/packages.md b/docs/moderation/submissions/packages.md index 523bb77..0cfcd25 100644 --- a/docs/moderation/submissions/packages.md +++ b/docs/moderation/submissions/packages.md @@ -1,11 +1,12 @@ # Submitting Packages to a Repository -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | A Package is any digital file which may be downloaded, installed, or served from a Repository. This may be include: + * **Software:** Software may be in binary or source code form, whether excutable or not. * **Digital archive files:** File archives may bundle and/or compress multiple files into a single file to be "extracted" into its original form for use. (e.g., .zip, .tar.gz, .rar, etc.) * **Other content:** Other content may include text, images, media such as audio or video, or other digitally stored information. @@ -23,6 +24,7 @@ Each Repository must perform the following automated checks: * **Security:** Perform an automated security scan at upload time to identify potentially dangerous code, such as known vulnerable patterns or libraries, malware, filesystem abuse, or unauthorized remote calls. In addition, software Repositories can: + * Scan for use of obfuscation techniques like base64 encoding, ROT13, or unreadable one-liners. * Look for raw API keys, secret tokens, or OAuth credentials committed in the source. * Compare submitted author name and plugin slug against known identifiers (DIDs, GitHub handles, etc.). diff --git a/docs/moderation/submissions/repositories.md b/docs/moderation/submissions/repositories.md index f910e2a..188f018 100644 --- a/docs/moderation/submissions/repositories.md +++ b/docs/moderation/submissions/repositories.md @@ -1,6 +1,6 @@ # Submitting Repositories to Aggregators -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | diff --git a/docs/moderation/tools/setup-ozone.md b/docs/moderation/tools/setup-ozone.md index 0d987b2..9a92c39 100644 --- a/docs/moderation/tools/setup-ozone.md +++ b/docs/moderation/tools/setup-ozone.md @@ -1,6 +1,6 @@ # Setting Up and Running a FAIR-Compatible Ozone Labeler Instance -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -8,6 +8,7 @@ This guide provides an overview for developers and organizations interested in setting up and operating their own independent Ozone-based Labeler Service that is compatible with the FAIR ecosystem. Running your own labeler allows you to contribute specialized moderation signals, cater to specific community needs, or offer alternative perspectives on trust and safety. Before proceeding, ensure you are familiar with: + - The core concepts of label-based moderation in FAIR, as detailed in [Ozone Labeling System](../../ozone-labeling-system.md). - FAIR's governance principles, particularly those related to [Moderation Services](../../governance/moderation-services.md). - Basic principles of Decentralized Identifiers (DIDs) and the AT Protocol, upon which Ozone is built. @@ -20,22 +21,22 @@ Before proceeding, ensure you are familiar with: Before deploying a labeler, clearly define: -* **Your Moderation Scope:** What types of content or entities will you focus on? (e.g., security of packages, WCAG accessibility, compliance with a specific regional policies such as GDPR, PIPEDA, or other legislation, or factual information for cataloguing packages such as license, software features, or genres of other content.) -* **Your Label Set:** What specific labels will you issue? (e.g., `myorg:security-audited`, `community:focus-accessibility`, `vendor:official-partner`, `wcag:2.2AA`, etc.) Define these clearly. -* **Your Moderation Criteria:** What are the transparent rules and processes by which you will apply these labels? -* **Your Target Audience:** Who do you expect to consume your labels? (e.g., a specific community, developers focused on a certain type of package) +- **Your Moderation Scope:** What types of content or entities will you focus on? (e.g., security of packages, WCAG accessibility, compliance with a specific regional policies such as GDPR, PIPEDA, or other legislation, or factual information for cataloguing packages such as license, software features, or genres of other content.) +- **Your Label Set:** What specific labels will you issue? (e.g., `myorg:security-audited`, `community:focus-accessibility`, `vendor:official-partner`, `wcag:2.2AA`, etc.) Define these clearly. +- **Your Moderation Criteria:** What are the transparent rules and processes by which you will apply these labels? +- **Your Target Audience:** Who do you expect to consume your labels? (e.g., a specific community, developers focused on a certain type of package) ## 2. Core Ozone Instance Setup Setting up the base Ozone service involves several technical steps, which should be guided by the official Ozone documentation. At a high level, this typically includes: -* **Deployment Environment:** Choosing and configuring a server environment (e.g., cloud virtual machine, containerized setup). -* **Ozone Service Installation:** Deploying the Ozone application software. -* **Database Configuration:** Setting up and connecting a compatible database (e.g., PostgreSQL). -* **Service Configuration:** Configuring Ozone with its operational parameters, such as its domain, connection to the AT Protocol network (if applicable for identity resolution or publishing), etc. -* **Identity for the Labeler Service (DID):** - * Your Labeler Service itself will need a Decentralized Identifier (DID). This DID will be associated with the labels it issues, ensuring accountability and allowing other services to identify the source of the labels. - * Follow AT Protocol/Ozone procedures for creating or assigning a DID to your service instance. +- **Deployment Environment:** Choosing and configuring a server environment (e.g., cloud virtual machine, containerized setup). +- **Ozone Service Installation:** Deploying the Ozone application software. +- **Database Configuration:** Setting up and connecting a compatible database (e.g., PostgreSQL). +- **Service Configuration:** Configuring Ozone with its operational parameters, such as its domain, connection to the AT Protocol network (if applicable for identity resolution or publishing), etc. +- **Identity for the Labeler Service (DID):** + - Your Labeler Service itself will need a Decentralized Identifier (DID). This DID will be associated with the labels it issues, ensuring accountability and allowing other services to identify the source of the labels. + - Follow AT Protocol/Ozone procedures for creating or assigning a DID to your service instance. **Action:** Refer to the latest official Ozone installation and configuration guides for detailed, up-to-date instructions. @@ -43,43 +44,43 @@ Setting up the base Ozone service involves several technical steps, which should To ensure your Ozone labeler instance can effectively participate in the FAIR ecosystem: -* **Understanding FAIR Entity Identification:** - * FAIR Repositories, Aggregators, and packages will be identified by DIDs or other standardized unique identifiers within the FAIR network. - * Familiarize yourself with how FAIR plans to structure its "Package/Repository Registry" and any specific ATProto record types FAIR might define for these entities (see [Ozone Labeling System](../../ozone-labeling-system.md)). Your labeler will need to target these identifiers. +- **Understanding FAIR Entity Identification:** + - FAIR Repositories, Aggregators, and packages will be identified by DIDs or other standardized unique identifiers within the FAIR network. + - Familiarize yourself with how FAIR plans to structure its "Package/Repository Registry" and any specific ATProto record types FAIR might define for these entities (see [Ozone Labeling System](../../ozone-labeling-system.md)). Your labeler will need to target these identifiers. -* **Defining and Publishing Your Labels:** - * **Schema (Recommended):** While not strictly enforced by FAIR for third-party labelers, consider defining a clear, public schema for the labels your service will issue. This helps consumers understand the meaning and intent behind your labels (e.g., `com.myorg.labels.securityReviewLevel` with possible values `basic`, `thorough`). - * **Public Documentation:** Publicly document the labels your service issues, their meanings, and your criteria for applying them. This builds trust and encourages adoption. +- **Defining and Publishing Your Labels:** + - **Schema (Recommended):** While not strictly enforced by FAIR for third-party labelers, consider defining a clear, public schema for the labels your service will issue. This helps consumers understand the meaning and intent behind your labels (e.g., `com.myorg.labels.securityReviewLevel` with possible values `basic`, `thorough`). + - **Public Documentation:** Publicly document the labels your service issues, their meanings, and your criteria for applying them. This builds trust and encourages adoption. -* **Making Labels Discoverable:** - * Ensure your Ozone instance's API endpoint for querying labels is publicly accessible. - * Consider how your labels will be discoverable within the broader AT Protocol ecosystem or any FAIR-specific indexing services. +- **Making Labels Discoverable:** + - Ensure your Ozone instance's API endpoint for querying labels is publicly accessible. + - Consider how your labels will be discoverable within the broader AT Protocol ecosystem or any FAIR-specific indexing services. ## 4. Operational Best Practices -* **Transparency:** - * Clearly state who operates the labeler service. - * Publish your moderation policies and criteria. - * If you offer a process for disputing labels issued by your service, document it clearly. -* **Reliability and Maintenance:** Ensure your service is reliably hosted and maintained. Downtime can impact services that subscribe to your labels. You may want to consider high-availability architecture and the use of CDNs. -* **Security:** Secure your Ozone instance and its administrative interfaces to prevent unauthorized access or label manipulation. -* **Communication:** Provide a clear point of contact for your labeler service. +- **Transparency:** + - Clearly state who operates the labeler service. + - Publish your moderation policies and criteria. + - If you offer a process for disputing labels issued by your service, document it clearly. +- **Reliability and Maintenance:** Ensure your service is reliably hosted and maintained. Downtime can impact services that subscribe to your labels. You may want to consider high-availability architecture and the use of CDNs. +- **Security:** Secure your Ozone instance and its administrative interfaces to prevent unauthorized access or label manipulation. +- **Communication:** Provide a clear point of contact for your labeler service. ## 5. Announcing Your Labeler Service to the FAIR Community Once your labeler is operational and you have documented its purpose and policies: -* Inform the FAIR community through appropriate channels (e.g., FAIR forums, developer mailing lists, or *specific channels which may be defined by FAIR in the future*). -* Provide details on: - * The DID of your labeler service. - * The API endpoint to query labels. - * A link to your documentation explaining your labels and policies. +- Inform the FAIR community through appropriate channels (e.g., FAIR forums, developer mailing lists, or *specific channels which may be defined by FAIR in the future*). +- Provide details on: + - The DID of your labeler service. + - The API endpoint to query labels. + - A link to your documentation explaining your labels and policies. ## 6. Interaction with the FAIR Ecosystem -* **Subscription by Aggregators or Clients:** FAIR Aggregators (including FAIR's own), and client applications (package browsers or installers), and end users can choose to subscribe to labels from any discoverable labeler service, including third-party or private ones. -* **No Guaranteed Endorsement:** Running a FAIR-compatible labeler _does not_ imply an official endorsement or mandatory subscription by FAIR or its official services. Each subscribing service or user will decide which labelers to trust and follow. -* **Community Trust:** Building a reputation for issuing accurate, consistent, and useful labels is key to gaining adoption and trust within the FAIR community. +- **Subscription by Aggregators or Clients:** FAIR Aggregators (including FAIR's own), and client applications (package browsers or installers), and end users can choose to subscribe to labels from any discoverable labeler service, including third-party or private ones. +- **No Guaranteed Endorsement:** Running a FAIR-compatible labeler _does not_ imply an official endorsement or mandatory subscription by FAIR or its official services. Each subscribing service or user will decide which labelers to trust and follow. +- **Community Trust:** Building a reputation for issuing accurate, consistent, and useful labels is key to gaining adoption and trust within the FAIR community. --- diff --git a/docs/moderation/tools/wordpress-plugin.md b/docs/moderation/tools/wordpress-plugin.md index 89c9133..69609e7 100644 --- a/docs/moderation/tools/wordpress-plugin.md +++ b/docs/moderation/tools/wordpress-plugin.md @@ -1,6 +1,6 @@ # FAIR WordPress Plugin: Integrating Moderation and Trust Signals -| | | +| | | |----------|------------| | Status | Proposal | | Date | 2025-07-22 | @@ -29,17 +29,17 @@ The FAIR WordPress Plugin actively participates in the ecosystem's integrity by: The plugin aims to provide clear, actionable information to the WordPress site administrator. Examples of alerts and indicators include: * **Aggregator Status Alerts:** - * **"This Aggregator is not connected to a recognized Federation Monitor - HIGH RISK"**: Displayed if an Aggregator the site is configured to use (or one being browsed) does not have a verified connection to a Federation Monitor, as per data from FAIR's public monitor list. This indicates a potential lack of transparency in its reporting mechanisms. - * **"This Aggregator has limited moderation tool integration - CAUTION"**: Displayed if an Aggregator is not subscribing to key labelers or has not declared clear moderation policies. + * **"This Aggregator is not connected to a recognized Federation Monitor - HIGH RISK"**: Displayed if an Aggregator the site is configured to use (or one being browsed) does not have a verified connection to a Federation Monitor, as per data from FAIR's public monitor list. This indicates a potential lack of transparency in its reporting mechanisms. + * **"This Aggregator has limited moderation tool integration - CAUTION"**: Displayed if an Aggregator is not subscribing to key labelers or has not declared clear moderation policies. * **Repository Status Alerts:** - * **"This Repository is currently blocked/defederated by FAIR - CRITICAL RISK"**: Shown when a Repository has been issued a critical label by FAIR's official Labeler Service (e.g., `fair:defederated` or `fair:threshold:suspended75`) indicating severe or unresolved issues. Interactions with this Repository (e.g., downloads, updates) may be restricted or heavily warned against. - * **"This Repository has outstanding unresolved critical reports - HIGH RISK"**: If labels indicate a high volume of unresolved critical issues. + * **"This Repository is currently blocked/defederated by FAIR - CRITICAL RISK"**: Shown when a Repository has been issued a critical label by FAIR's official Labeler Service (e.g., `fair:defederated` or `fair:threshold:suspended75`) indicating severe or unresolved issues. Interactions with this Repository (e.g., downloads, updates) may be restricted or heavily warned against. + * **"This Repository has outstanding unresolved critical reports - HIGH RISK"**: If labels indicate a high volume of unresolved critical issues. * **Plugin/Theme Status Alerts:** - * **"This plugin has unresolved critical security reports - HIGH RISK"**: Based on labels like `plugin:security-vulnerability:active`. - * **"This theme is marked as deprecated by its author - CAUTION"**: Based on labels like `theme:deprecated`. - * **"Community Warning: This item has numerous user reports pending review."**: Based on threshold labels like `fair:threshold:notice50`. + * **"This plugin has unresolved critical security reports - HIGH RISK"**: Based on labels like `plugin:security-vulnerability:active`. + * **"This theme is marked as deprecated by its author - CAUTION"**: Based on labels like `theme:deprecated`. + * **"Community Warning: This item has numerous user reports pending review."**: Based on threshold labels like `fair:threshold:notice50`. These alerts will be contextually displayed, for example, within the plugin/theme browser, on update screens, or on specific Repository/Aggregator information pages within the WordPress admin area. @@ -47,7 +47,7 @@ These alerts will be contextually displayed, for example, within the plugin/them The FAIR WordPress Plugin dynamically updates its assessment of entities within the FAIR network: -- **Aggregator Trust:** The plugin will periodically refresh its list of available Aggregators, enriching this list with status information derived from Monitor checks and labels. Aggregators deemed "untrusted" (e.g., not connected to a Monitor, or labeled as problematic) may be visually deprioritized, flagged, or, in severe cases, the plugin might suggest not using them. -- **Repository, Plugin, and Theme Trust:** Similarly, the perceived trustworthiness of Repositories, plugins, and themes is continuously updated as new labels are discovered. This ensures that the WordPress admin has the most current information available when making decisions about installing, updating, or trusting software. +* **Aggregator Trust:** The plugin will periodically refresh its list of available Aggregators, enriching this list with status information derived from Monitor checks and labels. Aggregators deemed "untrusted" (e.g., not connected to a Monitor, or labeled as problematic) may be visually deprioritized, flagged, or, in severe cases, the plugin might suggest not using them. +* **Repository, Plugin, and Theme Trust:** Similarly, the perceived trustworthiness of Repositories, plugins, and themes is continuously updated as new labels are discovered. This ensures that the WordPress admin has the most current information available when making decisions about installing, updating, or trusting software. The plugin provides a crucial layer of defense and awareness for end-users, translating the abstract concepts of decentralized moderation and trust into tangible, understandable information within their daily workflow. diff --git a/docs/security.md b/docs/security.md index 54c20a4..72ce9c6 100644 --- a/docs/security.md +++ b/docs/security.md @@ -2,7 +2,6 @@ Security is at the heart of the FAIR system, and is a fundamental design principle of the system. - ## Security of DIDs FAIR is designed to protect against a package being hijacked by anyone else. This is incorporated into the core design of the system, with the use of Decentralized IDs that cannot be controlled by any one entity. @@ -17,7 +16,6 @@ Because the repository's key is secondary, your recovery key can override the se Since you control the primary key, you can also move to a different repository - such as one that you trust more, or even one that you run yourself. - ## Security of packages Each DID contains a list of keys which are valid to sign packages, integrating a package signing system directly with the DID. @@ -32,7 +30,6 @@ However, situations can change, and repositories may become untrustworthy in the For publishers who are concerned about this vector, we recommend running your own repository to maintain full control of your DID and package systems. Note that this may be complex to run, and you also potentially have higher risks as there is no ability for others to help you update plugins or recover your DID. - ## Security of FAIR-controlled data Due to the nature of the FAIR system, very little data is centrally controlled by FAIR. @@ -46,12 +43,10 @@ There are four components run by FAIR for the benefit of the ecosystem: These services are hosted on servers provided by GoDaddy, who are a well-reputed host who have XXX compliance standards. The FAIR team includes experienced staff familiar with data privacy laws and secure architecture. - ### Main Repository The main repository is run by FAIR to provide a "default" repository publishers can use for their packages. We provide this so that publishers can easily get their packages out, without needing to worry about setting up their own infrastructure. This system contains the private keys used to manage DIDs for users, as well as signing keys for each package. As a result, it requires the highest level of security. -{Add further detail about security here.} - +*Add further detail about security here.*