Private Hierarchical Governance for Encrypted Messaging

TL;DR

Private hierarchical governance extends end-to-end encrypted messaging by moving governance logic to clients and introducing ordered application messages (OAMs) to maintain a consistent governance state without exposing content to the platform. The approach builds on MLS with a PolicyKit-inspired RBAC and a policy engine, enabling rich governance actions like voting, moderator management, and content takedowns while preserving content confidentiality and governance privacy. The authors implement MlsGov, a prototype platform, and evaluate latency, bandwidth, and scalability up to group sizes of 1024, demonstrating practical overheads for governance workloads. This work provides a concrete path toward privacy-preserving community governance in encrypted messaging and offers an open-source platform for ongoing experimentation and policy exploration.

Abstract

The increasing harms caused by hate, harassment, and other forms of abuse online have motivated major platforms to explore hierarchical governance. The idea is to allow communities to have designated members take on moderation and leadership duties; meanwhile, members can still escalate issues to the platform. But these promising approaches have only been explored in plaintext settings where community content is public to the platform. It is unclear how one can realize hierarchical governance in the huge and increasing number of online communities that utilize end-to-end encrypted (E2EE) messaging for privacy. We propose private hierarchical governance systems. These should enable similar levels of community governance as in plaintext settings, while maintaining cryptographic privacy of content and governance actions not reported to the platform. We design the first such system, taking a layered approach that adds governance logic on top of an encrypted messaging protocol; we show how an extension to the message layer security (MLS) protocol suffices for achieving a rich set of governance policies. Our approach allows developers to rapidly prototype new governance features, taking inspiration from a plaintext system called PolicyKit. We build a prototype E2EE messaging system called MlsGov that supports content-based community and platform moderation, elections of community moderators, votes to remove abusive users, and more.

Figures (8)

• Figure 1: A comparison between our work and other messaging platforms that support communities. * - based on our assessment (no public documentation).
• Figure 2: Diagram of an example governance scenario in which a user $U_2$ reports another user $U_3$ to a community moderator $U_1$, who kicks that user from the community and escalates by reporting the abuse to the platform's moderation systems. This results in a temporary ban of $U_3$ from the platform. Execution of community governance is handled on clients (denoted by the gears) and remains private to the community. Only when a user chooses to report to the platform does the latter become involved.
• Figure 3: Functions exposed by our message layer API, including inputs and the MLS messages invoked to handle the API request in our implementation. Here P+C stands for the indicated proposal type followed immediately by a commit.
• Figure 4: A subset of our supported actions, whether they affect governance state or content state, and the MLS messages they produce. UAM refers to an unordered application message, OAM refers to an ordered application message, and Add/Remove refers to a commit with the Add/Remove proposal.
• Figure 5: Latency breakdown for various messaging operations and traffic for a user in a group of 64 users in MlsGov (5-trial average). Clients are on US-East AWS instances while DS/AS are on US-West. For operations$^s$ requested by multiple clients simultaneously, data from the 33rd starting client is used. Total latency represents the time between loading the pre-operation group state and saving the post-operation group state, including server processing and key package generation/update delays. Sync request generations take consistently $<0.01$ ms. For results in a group of 1024, refer to Figure \ref{['fig:netTimes1024']} in Appendix \ref{['addl_exp']}.