Plain language. What we collect, what we keep, who can see it.

This is the consolidated privacy policy for ott-dungeon.com and Off The Traxx as a community. It's the single page you can point to instead of cross-referencing six other documents. Specific details (vetting retention, incident retention, what gets shared with other venues) are still covered in depth in the policies they belong to — those are linked below.

We've written this in plain language because legal-speak in a privacy policy is usually a sign that someone is hiding something. We're not.

What we collect

When you visit the site

Standard web logs (IP address, browser type, pages visited, timestamps) for security and troubleshooting. We don't use third-party analytics or tracking pixels. We use the cookies Joomla needs to remember you're logged in; we don't use any others.

When you create an account

Username, email address, and a password (hashed; we cannot see the plaintext). Your stated date of birth, used to confirm you're 21+. Whatever you choose to put on your profile.

When you apply for membership

Through the vetting form: scene name, email, the US state you live in, any other legal names you've used, the references you list (each one's name, how to reach them, and how they know you), and optional notes. Through ID verification: your legal first name, last name, and date of birth (and, for the in-person path, your address).

Your legal name, date of birth, address and other legal names are encrypted at rest using AES-256-GCM; on the site, only vetters with active group membership can open them, and every decryption is logged. For approved members, we also copy the month and day of your birthday (not the year) so the site can mark it; that copy isn't encrypted. For each reference you list, we also make a record for vetters to work from. The contact detail on that record is encrypted, and so are the answers a reference gives on the response form. The reference's name and how they know you are not. Whether they'd recommend you (yes, no or unsure) is also kept unencrypted, so vetters can see it at a glance.

The rest of what you type on the form is not encrypted. Your scene name and email are also your account details (see "When you create an account"). Your state, your optional notes and the reference list exactly as you typed it, including each reference's contact detail, are stored as plain text, so each contact detail you list is held twice: once encrypted and once not. Vetters' own notes and reasoning about your application aren't encrypted either. On the site, only vetters can see your state, notes and reference list, or what vetters wrote. That's access control, not encryption: someone with direct access to the database could read them.

You choose how your ID is verified, and the two paths keep different amounts of data:

• In person. The vetter looks at your ID, records the verified data, and hands it straight back. No image or scan is made — nothing leaves the room.
• Online, through Didit.me. You complete the check on Didit's secure hosted flow, uploading your ID and a selfie to Didit, not to us — no image of your ID ever reaches our servers. Once Didit confirms the result, we pull only your verified legal first name, last name, and date of birth (we deliberately do not capture your address from the online check) and store them encrypted, exactly like the in-person path. We then send Didit a "process and purge" request to delete its copy of your ID image, selfie, and extracted data for that session (on by default; a scheduled retention window is the backstop). What Didit collects, and how long it holds it before that purge, is governed by Didit's own privacy policy.

We run a check on the U.S. National Sex Offender Public Registry (NSOPW.gov) against your verified legal name. If there's a hit, we keep a record of the flag, the disposition (cleared, discuss, decline), and the vetter's reasoning. If there's no hit, we keep a record that the check was performed and came back clean. These records aren't encrypted.

When you file an incident report

The report itself (description, who it's about, when/where, witnesses, desired outcome, attachments) — all encrypted at rest. If you give your name or a contact (email, Signal, etc.) we keep those encrypted too. A few details aren't encrypted: the tick boxes for who we may contact, the kind of report, how anonymous you chose to be, and which kind of contact you gave. Neither is what the response team adds: its notes, which member's account the report is linked to, and the record of what was decided and done. On the site, only the response team can open a report. That's access control, not encryption: someone with direct access to the database could read those details.

Anonymous reports store no name or contact. Every report, anonymous or not, keeps a scrambled fingerprint of the IP address it came from, made with our encryption key, never the address itself. Someone with only the database can't work out the address from it, but could tell that two records came from the same internet connection, which could link an anonymous report to an account that used that connection. The report's copy is wiped with the rest of its contents; the audit log keeps the same fingerprint on its record of the report coming in.

JPEG, PNG and WebP photos have their EXIF metadata stripped before storage to prevent inadvertent disclosure of location, device, or timestamp. Other files, including GIF and HEIC photos, PDFs, audio and video, are stored as you send them, and so is a photo if stripping it fails. The report form explains how to scrub a file first.

When you participate as a vetter or response-team member

Audit log entries for every sensitive action you take (decrypting a field, changing a status, recording a decision, downloading an attachment) — including your user ID, the action, the timestamp, any reason you gave, and a hash (not the content) of what was affected. This is how we maintain accountability over data access.

When you attend events

At public events (munches, wet munches, dinners), we don't collect anything beyond a sign-in if the venue requires it. At events that take RSVPs on this site, organizers see the guest list and the staff roster for that event, by scene name only. At private events, the people working a shift at that event can see the list from the day before until the morning after. A private venue's address is shown only to people with a place and to organizers, and we store venue addresses encrypted. You can turn off event reminder emails; we still email you about your own places. When you arrive, the organizers or the people working that event can check you in; we keep that you arrived, when, and who checked you in; it's never used against you, and it's deleted with the event's RSVPs. If you keep an avoid list, it stays private at events too: once you have a place, the event page tells you (and only you) if someone on your list is also coming, and the organizers and the people working the door see only that two people shouldn't be paired — never who asked or why, never on a printed list and never in an email. We do not maintain face-recognition databases, surveillance footage at events, or any photo records without explicit permission.

When you use Messenger, groups and Community Call

Members can talk to each other on the site in three ways: Messenger, groups, and Community Call. Unlike the sensitive parts of your vetting file, none of this is encrypted at rest. Messages, posts, photos and call records are ordinary database records, like forum posts, so the Super Users who run the site could read them in the database. There's no screen on the site that lets staff browse your conversations.

Deleting your account deletes what you put into them, with the few exceptions in "Please delete my data" below.

Messenger. Members and staff can use it. If you've applied, you can use it only to talk with the mentor assigned to you, while your application is open. You can message people you've connected with (you asked and they accepted). Approved members can also message staff, and staff can message approved members, without connecting first. Members can also join community rooms, start private group chats of 3 to 8 people (each person accepts the invitation first), and play games.

• What we keep. What you send (text, photos, voice and video clips, reactions), who it went to, when, and how far you've read. Your connections, including requests, declines and ones you ended. Bookmarks and reminders you set, your quiet hours and your availability setting. For games with other members: the game, each move, who made it and when. For solo games: your saved game, and a receipt for each move (when, and what kind of move) that is deleted after 24 hours. Solo Blackjack also keeps your play-money balance between visits. Messenger doesn't record your IP address or browser.
• Drafts. A message you've started but not sent is stored encrypted. After 24 hours it's no longer shown or used. The encrypted copy is deleted when you clear the draft, the next time you save a draft, when you switch drafts off, or when you delete your account.
• Editing and unsending. For five minutes after you send a message, you can edit or unsend it, unless someone has reported it. We keep a record that you did, and a fingerprint (a hash) of the original text, not the text itself. Unsending also deletes the message's photos and clips. "Forget" on a solo game deletes the saved game; its move receipts go after 24 hours, like all solo receipts.
• Photos. Location and camera details (EXIF and GPS) are stripped when you upload a photo. Photos are shown only to people who can open that chat.
• Who sees it. A direct message: the people in that conversation. A private group chat: its members. A room post: everyone who has joined that room, including people who join later.
• Reports. If you report a message, Messenger's moderators see your report, that you made it, and the one message or photo you reported, not the rest of the conversation. The moderators are the Super Users, plus anyone we give the moderator permission to. A moderator never sees a report about themselves. We log each time a moderator opens a report or views its photo or clip, and what they decide; that record is kept with the report. When a report comes in, the Incident Response Team and the moderators get an email that says only that a report is waiting: no names, no message and no link. Neither you nor the person you reported gets it. A room or group post that a moderator hides disappears for members but stays in the database.
• Your avoid list. Adding someone ends any connection between you, hides you from each other in member search, and hides each other's posts in community rooms. Staff, and a mentor assigned to you, can still message you.
• Notifications. Messenger sends members no emails or push notifications; its only emails are the report alerts to staff described above. If you switch on browser notifications, they say only "You have new messages."

Groups. OTT Groups replaced our old groups system (GroupJive) in October 2026.

• Who sees what. Approved members see the list of groups, with each group's name and category, unless a group is hidden; then only its members know it exists. Only a group's current members see its photos and videos, its recent forum topics, its Messenger room, and who else is in it and their roles. The exception is a group whose owner has made it public: any approved member may then see who is in it, including on members' cards in the member directory. Otherwise the directory shows you a group on another member's card only if you're in that group too. Guests and applicants see none of this.
• What we keep. Your membership: when you asked or were invited, who approved you, your role, and when you left. Leaving marks your membership as ended; it isn't deleted. Invitations, reports, and a log of who did what to whom in the group. Photos and other pictures you add: as in Messenger, location and camera details (EXIF and GPS) are stripped when you upload them. The cover pictures we copied across from GroupJive in October 2026 didn't go through that step, but we've checked them, and none of them carried location or camera details.
• Group leaders. A group's owner, co-owners and moderators see requests to join, pending invitations, hidden photos and the group's reports, except safety reports (see "Reports" below). Site managers can see and do everything a leader can, in every group.
• Reports. When you report a group, you choose what it's about. A safety concern goes to the Incident Response Team and the site managers, never to the group's leaders. The team gets an email that says only that a report is waiting (no group, no details and no link), and reads the report on a staff page. Team members who lead that group don't see it there, unless they're also site managers. Any other report (member conduct, spam or something else) goes to the group's leaders and the site managers. Every report is deleted 365 days after it's closed. A group report isn't an incident report: it isn't encrypted, and the team can't reply to you through it. To report something about a person, or to hear back from us, use the incident report form.
• Email. Group email notices are off unless you switch them on. Each one names the group and the item: for an invitation, the group; for a forum post, the topic's subject.
• Videos. A group can show YouTube videos and linked video files. When you open a group page with one, your browser connects to YouTube (through its privacy-enhanced player, youtube-nocookie.com) or to the site hosting the file.
• The old system. We copied group names, descriptions, owners, memberships and cover photos across from GroupJive. GroupJive's own records are still in our database; we haven't deleted them yet.

Community Call. Approved members can join Community Call, a video call of up to 10 people. It runs on PlugNmeet Cloud (see "What we share"). In a call you're shown by your site username, and the name shown can't be changed. Your camera and microphone start off. Community Call has no chat, screen sharing or recording, and nothing in it is transcribed or sent to an AI service.

• What we keep. Who joined which call, when, and as a member or a moderator. Whether you allow call invitations.
• Your avoid list. You can't be in a call with someone on your avoid list, or with someone who has you on theirs. If one of you is already in the call, the other is told only that it's unavailable. If you add someone to your list while you're both in a call, the call ends for everyone. Nobody is told why.

How long we keep it

Who has access

Access is restricted by user group, not by job title:

• Vetters group. Can decrypt the encrypted parts of applicants' and members' vetting files, except the sealed letter, for as long as those files are kept, whatever the application's status. Every decryption is audit-logged with the vetter's user ID and the time.
• Incident Response Team group. Can decrypt incident-report content and download attachments. Same audit pattern. They also read the safety reports members file about groups, and get the no-details email when a Messenger report comes in.
• Super Users. Have database access by virtue of running the site, but the encryption key is a separate secret (stored outside the database). A database leak alone does not expose encrypted content. It does expose what isn't encrypted, including: Messenger messages, group content and call records; your scene name, email, state, optional notes and the reference list from your application form; whether each reference would recommend you; the month and day of an approved member's birthday; the kind of ID and where it was issued, from an in-person check; registry-check records, including any offense category, jurisdiction, conviction date and registry link; who filed a community note about an applicant, and whether it vouched for them, raised a concern or just passed on information (the note itself is encrypted); vetters' notes; the outcome you asked for in an appeal of a vetting decision; the scrambled IP fingerprints described under "When you file an incident report"; and, on incident reports, the kind of report, how anonymous the reporter chose to be, the response team's notes, the contact-permission tick boxes, which member a report is linked to, what was decided, and appeals against incident decisions.
• Messenger moderators. The Super Users, plus anyone we give the moderator permission to. They see reports and the one message or photo each report is about, not your conversations. A moderator never sees a report about themselves, and each time one opens a report is logged.
• Group leaders. A group's owner, co-owners and moderators see that group's requests to join, pending invitations, hidden photos and reports, except safety reports.
• Other members. Cannot see any vetting data, incident reports, or audit log entries. The forum, calendar, and class material are visible to members but contain no vetting or incident information. What other members see in Messenger, groups and Community Call is set out under "When you use Messenger, groups and Community Call".

Super Users do NOT automatically belong to the Vetters or Response Team groups. Those memberships are granted explicitly and revoked when someone steps back from those roles.

Companies that run the site for us

A few companies handle data so the site can run at all. They work for us under their own terms; none of them is a data partner.

• Our web host, CloudAccess.net, stores the site, its database and its backups. It also runs our email inboxes, such as This email address is being protected from spambots. You need JavaScript enabled to view it. and This email address is being protected from spambots. You need JavaScript enabled to view it., so it holds the emails you send us there.
• Cloudflare sits in front of the site, protecting it from attacks and serving pages faster. Every visit passes through it, so it sees your IP address and the pages you load, and it handles everything sent between your browser and the site, including what you type into forms, under Cloudflare's privacy policy.
• Amazon Simple Email Service (Amazon SES), run by Amazon Web Services, sends every email our site sends, from Amazon's US East (Ohio) region. To deliver an email, Amazon handles who it's to and what it says. For reference requests, and for the reminders a vetter sends an applicant about their references, we attach a few labels of our own (the kind of email and our reference numbers for it, never a name or address) so Amazon can tell us whether the email arrived; Amazon removes them before delivery. Only vetters see those results. For email, that's all Amazon gets from us. Amazon keeps its own delivery records under Amazon's privacy notice, and it may stop sending to an address that has bounced or marked mail as spam.

Some features also use a service of their own: Didit for online ID checks (see "When you apply for membership"), and Anthropic, PlugNmeet Cloud and, if you link your account, Discord (see "What we share").

What we share

The default is: nothing. We don't sell data, we don't share with advertisers, we don't have data partnerships with other venues. Apart from the companies that run the site for us (see the section above), there are six specific exceptions:

Cross-venue safety alerts

If an incident outcome was revocation for credible-safety-risk behavior, we may share the fact of the ban and the general nature of the concern with vetters at other venues we have established relationships with. We don't share unilaterally; the receiving vetter has agreed in advance to be reachable for safety conversations. We share only what's necessary — not the reporter's identity, not the full names beyond what's needed for identification, not the specifics of what happened. The subject is told if their information has been included in such an alert. Full policy is in the incident-reporting policy.

Mandatory reporting

Idaho law (I.C. § 16-1605) makes essentially every adult a mandated reporter for child abuse, abandonment, or neglect. If a report we receive includes information that triggers this obligation, we report that part to authorities. The law is not optional, and we cannot promise confidentiality on something the law won't let us keep confidential. If you're worried this might apply to a report you're considering, ask us before you file — we'll be honest with you about it.

Legal compulsion

If a court orders us to produce records (subpoena, search warrant), we comply with what the law requires. We don't volunteer information to police about your data, and we tell you (where legally allowed) if law enforcement has requested records about you. Our records can be subpoenaed; we cannot prevent that.

AI features

A few optional features use Claude, an AI service run by Anthropic. When you use one, what you type is sent to Anthropic so it can write the reply:

• Ask OTT, the question box on the site, and /ask in our Discord. Your question goes, with the conversation so far and our public pages.
• Rehearsal, the members' practice room. The practice conversation goes a turn at a time, and when you finish, it goes once more to be scored.
• Yes/No/Maybe's AI helpers, only if you have switched them on in your Yes/No/Maybe settings. What you type into a helper goes, or the item names from your lists when you ask for a summary. A summary that covers someone else's list only runs if they have switched the helpers on too.

We never send your username, real name, email address or any other account detail with it. If you type those into the box yourself, they go with the rest, so please don't.

Ask OTT keeps questions and answers, from the site and from Discord, for 90 days so we can see where our pages fall short. Nothing that identifies you is attached: no name, no account, no IP address. After 90 days they are deleted automatically. Rehearsal deletes a practice session when it ends or expires, unless you choose to save it to your journal. Yes/No/Maybe keeps nothing the AI writes.

Staff can switch each of these features off for everyone. Once one is off, nothing new is sent (a Rehearsal practice already under way can run to its end).

Anthropic is a company in the United States. It deletes what we send it within 30 days, unless its automated safety systems flag it as breaking Anthropic's usage policy, when it can keep it for up to two years, or the law requires it to keep it longer. See Anthropic's data-retention page.

Community Call video (PlugNmeet Cloud)

Community Call runs on PlugNmeet Cloud, a video-call service run by MynaParrot SL in Spain. When you join a call, your browser connects straight to PlugNmeet Cloud and loads the call screen from it. So while you're in a call, PlugNmeet Cloud handles your audio and video, your username, your IP address and your device details. From us, it gets the call's name, your username, a random number used for that one call (not your account number), and whether you're a moderator. Apart from your username, it never gets your email address, legal name or any other account detail from us. Recording, transcription and analytics are switched off. What PlugNmeet Cloud keeps about a call, and for how long, is governed by its own privacy policy, which doesn't say how long it keeps call data.

Our Discord server (if you link your account)

Our Discord server runs on Discord, a chat service run by Discord Inc. in the United States. Linking your site account to it is optional, and only approved members can. You get a one-time code on the site and give it to our bot, Bob, with /link in Discord.

• What we keep. Your Discord user ID and username, with your site account, when you linked, and when you last used Bob. To stop commands being overused, we also note which command you ran and when, never what you typed.
• What Discord gets from us. Bob gives your Discord account the server roles we've matched to your groups on the site, and takes them away within a day once they no longer match. Anyone in our Discord server can see your roles there. When you link, Bob posts a welcome in the server's general channel that mentions you and says you've linked your account; it carries nothing else from the site. Bob's replies to /ask, /glossary and /story are shown only to you, but Discord carries them; /story shows you numbers from your own site record. What you type into /ask also goes to Anthropic (see "AI features").
• Unlinking. "Unlink my Discord" on the site deletes the link (your Discord user ID and username) straight away, and Bob takes your roles off at the same moment. If Discord can't be reached just then, we keep only your Discord user ID, with nothing that ties it to your site account, until your roles are off, for 7 days at most. Deleting your account does the same, and also deletes the notes of which bot commands you used.

What Discord keeps, and for how long, is governed by Discord's privacy policy.

Your rights

You can ask us, at any time:

• What do you have on file about me? Email This email address is being protected from spambots. You need JavaScript enabled to view it. (for vetting records) or This email address is being protected from spambots. You need JavaScript enabled to view it. (for incident records). We'll tell you, within what we can share without compromising other people's privacy.
• Please correct this information. If something on file is inaccurate, tell us and we'll correct it. Some records can't be retroactively changed (e.g. the original application form is preserved as-submitted), but we'll annotate corrections.
• Please delete my data. We will, where we can. Some records have to stay — if a report led to actions involving other members, some record has to stay so we can explain why those actions were taken. We'll be specific about what we deleted and what we kept. Deleting your account also deletes what you've put into Messenger, groups and Community Call: your messages, posts, photos, clips, reactions, game records, group memberships and call records. A few things stay: a report you filed, without your name, so the moderators can still act on it; a closed report about you, as the record of what the moderators decided; a cover or logo you added to a group, without your name; and the other person's own messages in a conversation with you. Where you appear in someone else's game or group, you're shown as "Former member". While an incident about you is open, or a Messenger report about you is open, we keep all of it until it's closed, and then delete it.
• I want to take a break / withdraw entirely. Email This email address is being protected from spambots. You need JavaScript enabled to view it.. We have a withdrawal process that handles both temporary pauses and permanent departures.

If you're filing an appeal of a vetting decision, that's a separate process — see the decline email or the vetting page for how appeals work.

How we protect what we keep

Sensitive fields (legal name, DOB, address, other legal names, the contact detail on each reference record, what references tell us (apart from whether they'd recommend you), incident-report content, incident attachments) are encrypted at rest using AES-256-GCM. The encryption key lives outside the database — in a file readable only by the web server — so a database leak alone does not expose encrypted content. The encryption happens on our server, not end-to-end: the site decrypts these fields to show them to the people allowed to see them.

Some vetting and incident details are not encrypted and are protected by access control alone, among them the reference list and notes you type on the application form, whether each reference would recommend you, the copy of an approved member's birthday, registry-check records, vetters' notes, and the response team's notes and contact-permission tick boxes on incident reports. The Super Users entry under "Who has access" above gives the fuller list.

Encrypted attachments are stored in a directory that explicitly denies HTTP access. JPEG, PNG and WebP image attachments are re-encoded at upload time so location and device details are stripped before storage. Other files, including GIF and HEIC photos, are stored as sent, and so is a photo if re-encoding it fails.

Messenger messages, photos and clips, group content and call records are not encrypted at rest; they're ordinary database records, like forum posts. Unsent Messenger drafts are the exception: they're encrypted, and hidden after 24 hours (see "Drafts" above). Messenger and group photos have location and device details stripped at upload.

For online ID verification, the document images never reach our servers at all — they're handled entirely by the verification provider (Didit), and we ask the provider to delete its copy once the check is done. We store only the verified text fields (name, date of birth), encrypted like the in-person details.

Every time staff decrypt vetting or incident information, it's logged. The audit log records who decrypted what and when. Some screens (incident reports, community notes and staff observations) also ask why and record the answer. If you ever wonder whether your data has been looked at, you can ask — we'll show you the audit log entries. Some things are decrypted without an entry in that log: a private venue's address, when it's shown to people with a place and to organizers; your own Messenger drafts, when they're shown to you; and a contact detail the site decrypts to send an email, such as a reference's email address or a reporter's contact for an update on their report.

We are not perfect security professionals running a hardened infrastructure; we are a small community running a Joomla site with care. We've done the work to make sure that the parts that handle sensitive data are designed for the harms we're worried about (data leak exposing applicants, an insider going on a fishing expedition, hosts wiping our config file). If you have a security concern or have spotted a flaw, email us — we'd rather hear it from you than from an incident.

Cookies and tracking

We use the cookies Joomla needs to remember you're logged in and to maintain your session. We don't use third-party analytics, advertising trackers, or fingerprinting. Two exceptions load content from other companies. Groups can show YouTube videos, through YouTube's privacy-enhanced player (youtube-nocookie.com); opening a group page with one connects your browser to YouTube, and playing it is covered by Google's privacy policy. Community Call's screen is loaded from PlugNmeet Cloud (see "What we share").

Changes to this policy

If this policy changes in any meaningful way, we'll post a notice in the members-only section of the site at least 30 days before the change takes effect. The current version always lives at this URL. Cosmetic edits (typos, clarification) don't trigger a notice but the change date below moves.

Questions

Email This email address is being protected from spambots. You need JavaScript enabled to view it. for vetting-data questions, This email address is being protected from spambots. You need JavaScript enabled to view it. for incident-related questions, or our general contact channel for anything else.

Last updated: 2026-10-27.