swicg / swicg/activitypub-e2ee

Flagging *encrypted* content to a moderator team

Open
#87 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
78
Forks
2
PR merge metrics
No merged PRs in 30d

Description

In our discussion of https://github.com/swicg/activitypub-e2ee/issues/77 in the last task force meeting there was agreement that some mechanism for reporting harmful content within E2EE groups is necessary for community safety, but some wanted to simply send regular Flag activities to mods with the decrypted message contents in cleartext, and others wanted a mechanism to forward encrypted messages to mods for review without revealing the contents to the server.

I'd suggest fleshing out the cleartext approach in the existing issue (#77) and using this new issue to figure our how to do the latter.

For the encrypted approach, the reporter forwards message content to the mod team in a new E2EE chat. The forwarded content is re-encrypted by the client so it can be read only by the mod team and is not revealed to the server(s).

How it works

  1. Reporter selects a message (or several) and triggers a "report" action in the client UI
  2. Client discovers the relevant mod team: could be the group's designated mod team or the server-level mod team, or maybe a manually-selected mod team? (see https://github.com/swicg/activitypub-e2ee/issues/86 for how mod teams could be defined and discovered)
  3. Client starts a new E2EE chat group with the mod team as member(s)
  4. Client pre-populates the forwarded message content, clearly marked as forwarded, with metadata: originating group, sender's actor URI, timestamp
  5. Reporter optionally adds their own comment before sending
  6. The report is sent as a normal E2EE message (or series of messages) to the mod team, using the same PrivateMessage flow as any group message

The mod team receives the report in their mod chat area (separate from their normal chat, as this would use different keys to preserve pseudonymity when desired), can discuss with the reporter, and can act. What actions are available depends on how the mod team relates to the group:

  • If the mod [team] is a regular group member: full group participant capabilities, such as removing the member
  • If the mod [team] has a special moderator role in the group (TBD): may have elevated capabilities (eg. edit/delete others' messages?)
  • In all cases: can block the sender at the server level (if they are a sever moderator), escalate to other moderators, or take action outside the group

What this does and doesn't guarantee

  • Does not cryptographically verify the forwarded content is unaltered: mods must treat it as a reporter's account of events (unless https://github.com/swicg/activitypub-e2ee/issues/79 is also implemented)
  • Give mods enough context to investigate (group identity, claimed sender, timestamp, content)
  • Keeps the reporting flow E2EE end-to-end, so the server never sees report content

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the proposed flow in this issue and read issues #77, #86, and #79 for the related cleartext reporting, moderator discovery, and content-integrity questions. Trace the existing PrivateMessage flow and client report action entry point. Done means the encrypted report process, moderator context, key separation, and available moderator actions are specified without exposing report content to servers.

Written by the indexing model from the issue text.

Assessment

Domain
api, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.