Plugin para publicar hilos anónimos vía MP o dar feedback anónimo

Plugin
1
:information_source: Summary provides two independent, anonymous posting forms
:hammer_and_wrench: Repository Link GitHub - elRicharde/discourse-anonymous-feedback: Anonymous Feedback Formular in Discourse
:open_book: Install Guide How to install plugins in Discourse

This Discourse plugin provides two independent, anonymous posting forms: “Anonymous Feedback” and “White Board”. Both forms are protected by a “door code” (a simple password) and allow users without an account to send a private message to a pre-configured user group, even if your forum normaly requires Login, these two forms don´t.

Technically, posts are submitted via a webpage without requiring a login, and can even be used in a private browsing tab. There is no possibility of tracing back the sender, as IP addresses are not logged. This plugin is designed to offer a secure and confidential channel for communication.

Why Use This Plugin?

In many communities, sensitive topics or ideas require a channel for feedback that guarantees anonymity and reduces social pressure. This plugin addresses several key challenges:

  • Fostering Uninhibited Feedback: It provides a safe space for users (and even non-users, if the door code is shared externally) to share honest, unfiltered opinions, concerns, or innovative ideas without fear of judgment or repercussions. This can lead to more candid and valuable input that might otherwise be withheld.

  • Confidentiality and Trust: By ensuring anonymity through technical measures (like HMAC-based rate limiting without IP logging), the plugin builds trust and encourages broader participation, especially for delicate subjects.

  • Bridging Communication Gaps: It creates an accessible communication bridge for individuals who are hesitant to post publicly or who do not have a Discourse account, thereby expanding the reach of community engagement.

  • Structured Input: By directing feedback to a specific private group, it ensures that sensitive information is reviewed by the appropriate team members, allowing for focused discussion and action away from public view.

  • Simplicity for Non-Users: The door code mechanism allows external parties or temporary visitors to provide input without the overhead of full account registration.

Ultimately, this plugin enhances community interaction by enabling a more inclusive and secure environment for critical discussions and suggestions.

How It Works (Technical Overview)

The plugin was developed with a focus on anonymity and security.

  1. Access: A user navigates to /anonymous-feedback or /white-board.

  2. Unlock: The user must enter the correct door code. The server validates this code.

    • To prevent brute-force attacks, the server uses a rate-limiting system based on an HMAC hash of the user’s IP address and a rotating secret. The IP address itself is never stored.

    • If the code is correct, the server sets a temporary, one-time usable flag in the user’s session.

  3. Submit: The user writes and sends their message.

  4. Create PM: The server checks the session flag. If valid, it creates a new private message to the configured target group and posts it as the configured bot user (or system user). The session flag is then immediately deleted, so the user has to enter the door code again for any further message.

Example Use Cases / Workflows

This plugin was designed to be flexible. Here are two common workflows you can implement:

Use Case 1: The “White Board” - A Moderated Public Notice Board

This use case is for creating visibility for sensitive topics or inappropriate behavior that has been observed in the community (e.g., at events or in general interactions). For instance, making visible issues like sexism.

The Goal: To make important issues visible to the community without exposing the identity of the person reporting them. The focus is on the message, not the sender, and potentially not even on the individuals involved. A simple representation of situations with inappropriate behavior, without naming names, still creates visibility and raises awareness.

The Workflow:

  1. Submission: A user submits a post via the /white-board form. This can be accessed by members (MG), apprentices (ANW), and facilitators (FM). Only the USER “Anonymous” can create posts.

  2. Private Review: The post arrives as a Private Message to the configured target_group (e.g., a moderation team or a “Trust & Safety” committee). It will be identifiable as a “White Board” entry.

  3. Vetting: The team reviews the submission against pre-defined criteria (e.g., no personal attacks, no insults, adherence to community guidelines).

  4. Publication (If Approved): An admin is invited to the message who converts it into a public topic in a dedicated, public “White Board” category. This topic is posted using a specific, generic account (e.g., a “WhiteBoardBot” or “Anonymous” user, configured via the bot_username setting). The login details for this user can be shared with the reviewing group. The publication is done by the USER “Anonymous”.

  5. Discussion Control: The “White Board” category permissions are set so that it is visible to members/apprentices/facilitators but not commentable. Regular forum moderators are expected not to moderate this specific area; this is solely the responsibility of the designated target_group. There is still the question of whether the White Board should contain sub-categories (e.g., “anonymous closed” or categories specifically for target_group posts).

  6. Handling Rejections: Since there is no way to contact the anonymous sender, it’s a good practice to have a pinned topic in the “White Board” category explaining the publication criteria and the reasons why a submission might be rejected. Rules justifying non-publication should always be made public in one place in the forum.

Use Case 2: Anonymous Feedback - A Direct, Private Channel

This use case is for providing a direct, confidential line of communication to a specific team for any kind of feedback (e.g., for voting feedback or other anonymous suggestions).

The Goal: To give members and non-members a safe way to provide feedback on community matters, votes, or other topics directly to the leadership or a relevant committee.

The Workflow:

  1. Submission: A user submits feedback via the /anonymous-feedback form. The subject line can help categorize the message. This post arrives with the subject prefix “Anonymous Message - dd.mm.yyyy, hh:mm:ss” to the target_group’s collective inbox.

  2. Private Delivery: The message arrives as a Private Message to the target_group. It is identifiable as “Anonymous Feedback” by its subject prefix. The target_group then decides what to do with the message.

  3. Internal Handling: The team can then discuss the feedback privately, involve other relevant parties if necessary, or decide on a course of action. This feedback might be used for voting feedback or other anonymous suggestions.

  4. Best Practice for Inappropriate Feedback: If a submission is inappropriate, the team can simply delete it. You could consider posting a generic, public notice (e.g., in a “News” category) stating that “Feedback received on [Date] was not processed because it violated our community standards for respectful communication.” This informs the sender without revealing any details and encourages them to re-submit in a more constructive manner. If it’s a post for the White Board (identifiable by no special marking, or possibly a suffix if helpful): the mods are invited to the message, but no one replies to the message. The mods convert the message into a topic in the “White Board” category → visible to members/apprentices/facilitators and not commentable.

Features

  • Two Independent Endpoints: Provides /anonymous-feedback and /white-board, each with its own separate configuration.

  • Protection via Door Code: Each form is protected by its own secret door code to prevent spam. The door code is the same for everyone, and the page can also be used in private mode or on parents’ computer.

  • Configurable Target Group: Messages from each form are sent as a private message to a specific, configurable user group.

  • One-Time Session: After a message has been successfully sent, the user is redirected back to the door code screen. They must enter the code again to send another message, which prevents simple multi-post spamming. After sending, you land back on the door code, no multi-post is easily possible.

  • Anonymity-Preserving Rate Limiting: Protects against brute-force attacks and spam without logging IP addresses.

  • Bot Protection: Contains a hidden honeypot field to catch simple bots.

  • Custom Sender User: You can define a bot user for each form so that the private messages appear to be sent by this user (e.g., “FeedbackBot”). The user must exist. If empty, the system user is used by default.

  • Clean, Modern User Interface: The forms are based on a reusable Ember.js component for a consistent and clean user experience.

Installation

Follow the standard guide for installing Discourse plugins: Install a Plugin.

  1. Add the plugin’s repository URL to your app.yml file:

    hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/elRicharde/discourse-anonymous-feedback

  2. Rebuild your container: cd /var/discourse && ./launcher rebuild app

Configuration

After installation, you can configure the plugin in the Discourse admin settings. Search for “anonymous feedback”. All settings are independent for the “Anonymous Feedback” and “White Board” forms.

Setting Description
anonymous_feedback_enabled Toggles the /anonymous-feedback page on or off.
white_board_enabled Toggles the /white-board page on or off.
... door_code The secret password users must enter to access the message form.
... target_group The name of the user group that receives the private messages. This group must exist.
... rate_limit_per_hour A global limit on how many messages can be sent per hour to prevent abuse. Set to 0 to disable.
... max_message_length The maximum number of characters allowed in the message text.
... hmac_rotation_hours How often the secret key for rate limiting rotates. A shorter duration resets brute-force locks faster but is slightly less secure.
... bot_username Optional. The username of the user who will send the PM. The user must exist. If empty, the system user is used.

Development / Architecture

  • Backend: A single Ruby on Rails controller, AnonymousFeedbackController, processes all requests for both endpoints. It uses a kind method that checks the request path (/anonymous-feedback vs. /white-board) to determine which configurations to use. This avoids code duplication. A dynamic setting helper further simplifies reading the configuration.

  • Frontend: The user interface is based on a single, reusable Ember.js component, <AnonymousFeedbackForm />.

    • This component contains the entire HTML, CSS, and Javascript logic for the form’s state (unlocking, sending, error handling).

    • The route templates (anonymous-feedback.hbs and white-board.hbs) are now extremely simple. They just instantiate this component and pass the correct parameters (e.g., title, API URLs). This DRY (Don’t Repeat Yourself) approach makes the frontend code clean and easy to maintain.

Deep Dive: Anonymity & Rate Limiting (HMAC)

A core feature of this plugin is the balance between absolute anonymity and protection against abuse (spam).

The Problem: Finite IP Addresses

IPv4 addresses consist of a finite set of combinations (approx. 4.3 billion).

  • The Risk: Hashing functions (like SHA256) are irreversible one-way functions. However, if we simply stored SHA256(IP_Address), an attacker (or admin) could pre-calculate the hashes for all existing IP addresses (a “Rainbow Table”) in seconds. By comparing the stored hash with their list, they could immediately reveal the original IP.

The Solution: HMAC with a Rotating Secret

We use HMAC (Hash-Based Message Authentication Code). This combines the message (IP) with a cryptographic Secret Key before hashing.

  • The Mechanism: Identifier = HMAC(IP_Address + Secret_Key)

  • Why it works: Even though the attacker knows all possible IP addresses, they do not know the Secret Key. Without this key, they cannot pre-calculate the hashes. The “Rainbow Table” attack becomes impossible because the secret variable is missing.

Forward Secrecy (Key Rotation)

The Secret Key is rotated automatically (e.g., every 4 hours).

  • Scenario: Imagine the server is hacked and the attacker steals the current Secret Key and the database.

  • Protection: Because the key changes regularly and old keys are permanently discarded, the attacker can only calculate IP hashes for the current time window (e.g., the last 4 hours). All activities from yesterday or last week were hashed with keys that no longer exist. This ensures Forward Secrecy: past anonymity cannot be broken, even if the current system is compromised.

Fast vs. Slow Rotation

You can configure the rotation interval (hmac_rotation_hours).

  • Fast Rotation (e.g., 1 hour):

    • Pros: Maximum anonymity. The window of time where distinct actions can be linked to the same (unknown) actor is very short.

    • Cons: “Memory loss” for rate limiting. When the key rotates, the server “forgets” who has already sent messages. A spammer blocked in Hour 1 is effectively unblocked in Hour 2.

  • Slow Rotation (e.g., 24 hours):

    • Pros: Stronger protection against spam, as blocks persist longer.

    • Cons: Within this 24-hour window, an admin can see that “User X” sent 5 messages, even if they don’t know who “User X” is (Linkability).

Recommendation: A value between 4 and 12 hours offers a solid balance.

2 Me gusta