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, contact information for the references you list, and optional notes. Through ID verification: your legal first name, last name, and date of birth (and, for the in-person path, your address). All of these are encrypted at rest using AES-256-GCM; only vetters with active group membership can decrypt them, and every decryption is logged.
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.
When you file an incident report
The report itself (description, when/where, witnesses, desired outcome, attachments, contact permissions) — all encrypted at rest. If you provide a contact (email, Signal, etc.) we keep that encrypted too. Anonymous reports have no identity fields stored. Photo and image attachments have their EXIF metadata stripped before storage to prevent inadvertent disclosure of location, device, or timestamp.
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, your stated reason, 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 private events, organizers may track RSVPs internally. We do not maintain face-recognition databases, surveillance footage at events, or any photo records without explicit permission.
How long we keep it
| Category | Retention |
|---|---|
| Web logs | 30 days (default Joomla setting; rotated automatically) |
| Account data (username, email, hashed password) | As long as your account exists, plus the standard period after deletion that Joomla retains for audit |
| Encrypted PII (legal name, DOB, address) | Approved members: as long as you're a member, plus 12 months. Declined applicants: encrypted fields purged 90 days after the decline. |
| Online ID-verification session (Didit) | The provider's copy of your ID image, selfie, and extracted fields is purged right after the check (“process and purge”, on by default); a scheduled retention window is the backstop. We retain only the verified name + date of birth, encrypted, under the row above. |
| Registry-check records | Kept indefinitely (the institutional record of "we checked"). Annual re-runs add new records; old ones aren't deleted. |
| Incident report contents (encrypted) | 3 years after the incident is closed, then the encrypted content is wiped. Decision outcome + audit kept indefinitely. |
| Audit log | Indefinitely. This is the accountability record for who saw what when. |
| Vetting decision + reasoning | Indefinitely. Future vetters need the context if you reapply. |
| Forum posts | As long as your account exists, unless you delete the post yourself or a moderator removes it. |
Who has access
Access is restricted by user group, not by job title:
- Vetters group. Can decrypt PII for active applications. Every decryption is audit-logged with the vetter's user ID and stated reason.
- Incident Response Team group. Can decrypt incident-report content and download attachments. Same audit pattern.
- 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.
- 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.
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.
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. Three 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.
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) orThis 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.
- 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, reference contact info, 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.
Encrypted attachments are stored in a directory that explicitly denies HTTP access. Image attachments have their EXIF/metadata re-encoded out at upload time so location and device details are stripped before storage.
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 everything else.
Every decryption is logged. The audit log records who decrypted what, when, and the reason they typed. If you ever wonder whether your data has been looked at, you can ask — we'll show you the audit log entries.
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. Embedded YouTube videos or similar (if we add them) would be the rare exception and we'd note them.
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
Last updated: 2026-06-09.