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:

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

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.

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.