Overview of Privacy with OpenSay

We want to be fully transparent about how OpenSay works and how we use cryptography to never store the actual user ID of anonymous authors.

But first, let's understand how Slack bots works.

Slack Bot Architecture

When a Slack user, within a Slack workspace, interacts with a bot (e.g. with a slash command) an event is sent to Slack's regional servers which then relays the event to the bot's backend server.

The event usually contains identifiable information about the user, team and the specific payload (e.g. an anonymous message).

That is, both Slack and the bot's backend know precisely who interacts with it (otherwise it wouldn't be able to function).

This raises two questions:

1. Can a Slack bot function without saving identifiable information about a user that interacts with it?

2. Can a user's Slack workspace admin know he interacted with a specific bot?

How OpenSay Handles User IDs

User interactions with OpenSay can be with stateless or stateful.

A stateless interaction allows OpenSay to work properly without storing anything about the originator of the interaction.

An example of a stateless interaction is when a Slack user uses OpenSay to post (or reply) anonymously and clicks on the Hide reply pseudonym checkbox:

In this case, no data is stored about the user and any reply by the same original poster (OP) can't be linked back to her.

However, in the stateful scenario where a user doesn't check the Hide rpely pseudonym checkbox, any reply by her would indicate that the message is from the OP:

Can we be stateful without holding users' IDs? Yes we can!

Ephemeral Uniqueness

This is a bit technical so feel free to skim through.

We researched various technologies, from secure enclaves, to zero-knowledge cryptographic accumulators only to settle for a rather simple, yet robust, solution: a rotating cryptographic pepper.

We create a per-thread unique and ephemeral identifier for the user with:

Where pepper is rotated every week and stored as a Cloudflare Worker Secret (i.e. isn't stored with the database, if an attacker is somehow able to dump our database, she couldn't decipher the peppered user ids). Past peppers aren't stored.

Slack Logs

Slack allows workspace admins to view access logs (e.g. when a person sign ins to Slack) and to export raw logs of messages.

We recommend using OpenSay when other members of the team are active on Slack, to avoid any possible correlation.

While Slack admins can see who installed an app, they can't see who interacted with the app because only messages (and not interactions) are stored in the export logs (we verified it for Slack Pro and Enterprise. We highly doubt this policy would change in the future - because of privacy regulations such as GDPR and CCPA).

Finally, please note that this is not Signal nor TOR. Everything you do with OpenSay passes through Slack and we don't know what data is actually being held by them and may be accessible to law enforcment agencies. Please don't do anything illegal 🙏🏻.

Comments and Thoughts

We're constantly striving to improve OpenSay and would very much appreciate your feedback. What could be better? Which feature is missing?

We welcome comments and thoughts on the tweet below, and kindly ask for a like, retweet or a follow to help us spread the word. Thank you!

Overview of Privacy with AnonymityBot and @SlackHQ - learn how we use cryptography to never store the actual ID of anonymous authorshttps://t.co/kxvM9GJhYy

— OpenSay (@OpenSayHQ) March 16, 2022