Security
How a table's audio is kept apart
Scout holds private conversations belonging to groups who have nothing to do with each other. This page describes the boundaries that keep them separate, and is specific enough to be argued with.
Scout is not released. What follows describes how the software is built and what it will do when it runs. Where something is designed and not yet implemented, this page says so rather than using the future tense to blur the two.
Audio is encrypted between your table and Scout
Discord voice now requires end-to-end encryption, and Scout speaks that protocol rather than working around it. In practice:
- Every voice channel has its own encryption keys. One table's keys cannot decrypt another table's audio, and that is a property of the cryptography rather than of our code being careful.
- Each table's audio travels on its own connection. The shared connection to Discord carries only control information, meaning who joined which channel, and never audio.
Discord refuses to let a bot into a voice channel at all unless it can do this. We verified that by testing it: a build without the encryption support is turned away by the server, not merely warned.
Each table's recordings are stored separately
A recording is written under an address belonging to its table, and the part of Scout that handles a session is given a handle that cannot reach outside that table. Writing to the wrong table is not something to be careful about; it is something the code cannot express.
Storage is deliberately not shared between tables even where sharing would be cheaper. Identical audio recorded at two tables is stored twice. That costs us money and buys something worth more: deleting one table's data can never affect another's.
Recordings are verified, not assumed
Every piece of audio is stored with a fingerprint of its own contents, checked as it is written. A recording that does not match its fingerprint is refused rather than stored.
Each fragment also carries its position and timing, which means Scout can tell the difference between a quiet moment, a fragment that arrived late, and one that never arrived at all. Systems that do not track this cannot distinguish those, and quietly present a damaged recording as a complete one.
That is not a hypothetical. While building this we found a defect in a widely used library that was silently discarding a few percent of all audio, and it had gone unnoticed because it looked exactly like ordinary network trouble. We could only find it because we were counting. The fix has been contributed back to that library.
What we deliberately cannot do
- Read a channel nobody added. Scout starts able to read no messages at all, and each channel is added one at a time by the person running the game. It can never read direct messages, and it cannot be pointed at a channel Discord has not already given it access to. See Privacy.
- Record without asking. A session does not start until everyone present has answered.
- Speak as a character. Scout can talk, and what it says is directed at the person running the game. It does not perform your character and never rolls for you.
Imported history is quarantined before it is used
A table can ask Scout to read back over its existing channel history. That material gets stricter handling than anything recorded live, because it is the least consented data in the system: it contains people who never met Scout, guests present once, players who have left, and possibly people who were children at the time.
It therefore lands in a quarantine that is not part of the campaign record and not retrievable. Nothing is extracted from it until each speaker is identified and their consent state established. The remainder is deleted rather than merely set aside, and where somebody cannot be reached, deleting their material is the default rather than keeping it pending contact.
Credentials
Scout's own secrets are resolved from the environment or an operating system keychain rather than being written into configuration files, and a build refuses to accept a secret written literally into config when running in an automated environment.
What is not built yet
Said plainly, because a security page that lists only strengths is not describing a real system.
- Recordings are not yet encrypted at rest by us, beyond the encryption the storage provider applies. The design keeps the keys separable and revocable so this can be added, and it is not there today.
- There is no formal data protection assessment yet. It is required before anyone outside the project is invited, and it is not written.
- Scout has not been penetration tested.
Telling us about a problem
If you find a security issue, contact us through the address on the front page and give us a reasonable chance to fix it before publishing. We will not pursue anyone who reports something in good faith. A named contact and a disclosure timetable will appear here before Scout is offered publicly.