Transparency Portal

Judicium is a Discord anti-bot and security system designed to protect servers from scammers, fake bots, and raiders.

Core Features

Judicium requests minimal permissions necessary for effective protection. Here's what we use:

Exact Data Structures

Below is exactly what Judicium stores for each detection type:

Banned User Entry (scammers.json)

{
  "USER_ID": {
    "uid": 123456789,
    "username": "detected_username",
    "ban_type": "Image Detection",
    "reason": "Phishing scam image",
    "manual": false,
    "timestamp": "2024-01-15T10:30:00Z"
  }
}

What's stored: Only the 6 fields above. Nothing else. No IP, no email, no DMs, no message history.

Scam Image Hash Entry

ID: 1  Hash: a1b2c3d4e5f6g7h8i9j0

What's stored: Only the perceptual hash, and only for images detected as a scam. Clean images are not stored. Not the image, not the URL it came from, not who uploaded it. Just the 20-character hash.

Malicious Link Entry

ID: 1  Link: sus-crypto-withdraw.com

What's stored: Only the domain/URL. Not access logs, not click counts, not user referrers.

Real-Time Message Processing (Not Stored)

When you send a message:

1. Message enters bot's memory
2. Checked against hash/link/keyword databases (in RAM)
3. If threat detected → user is banned, message is deleted
4. If safe → message is immediately discarded from bot memory
5. Result: Message never written to disk

Zero permanent message logging. This is guaranteed by code design.

What Data We Collect

• Image hashes: 20-char perceptual hash, saved only when an image is detected as a scam (not the actual image)
• Banned user entries: 6 fields: uid, username, ban_type, reason, manual flag, timestamp
• Malicious links: Domain/URL string only
• Scam keywords: Text patterns for OCR detection
• Message content: Analyzed in RAM, discarded after check (not persisted)
• Judicium command history Commands you run with Judicium is stored.

What We Don't Collect

• Full message text (ever persisted to disk)
• User DMs or private channel content
• IP addresses or connection data
• Email or any contact information
• Full images, and hashes of images that were not detected
• Server configs or channel settings
• Bot command history (except Judicium)

Data Retention Policy

• Scam image hashes: Indefinite (needed for ongoing protection)
• Banned user database: Indefinite (global blacklist)
• Malicious links: Indefinite (prevents re-use of known scam domains)
• Real-time message analysis: 0 seconds (deleted from memory immediately after scan)

Important: The only way data persists is if you're banned. You can request removal by appealing in our support server.

Data Security

All data is encrypted in transit. We use industry-standard practices to protect information from unauthorized access. We do not sell or share user data with third parties.

Judicium maintains two ban databases with different purposes. The public database is shared across servers for protection. The internal database tracks full details for appeal and audit purposes.

Public Database (scammers.json)

This is the database shared globally to protect all Judicium-protected servers. It's minimal by design:

{
  "123456789": {
    "uid": 123456789,
    "username": "detected_scammer",
    "ban_type": "Image Detection",
    "reason": "Phishing scam",
    "manual": false,
    "timestamp": "2024-01-15T10:30:00Z"
  }
}

Fields: 6
Size per entry: ~150 bytes
Purpose: Cross-server protection blacklist
Access: Loaded into RAM on startup
                

Internal Database (kept private, server-side only)

This is our internal audit log with full context. It's NOT shared or publicized:

{
  "123456789": {
    "ban_id": "aBc1-dEf2-gHi3-jKl4-mNo5-pQr6",
    "uid": 123456789,
    "username": "detected_scammer",
    "msg_id": 987654321,               // Discord message ID
    "sim": 0.94,                       // Similarity score (0-1)
    "server_id": 555444333222,         // Where it was caught
    "ban_type": "Image Detection",
    "reason": "Phishing scam",
    "manual": false,
    "timestamp": "2024-01-15T10:30:00Z",
    "history": [...],                  // Previous bans if re-offender
    "roles_backup": {...},             // User's roles (for appeal restoration)
    "is_sl": false,
    "source": "Judicium MB"
  }
}

Fields: 13 (vs 6 in public)
Size per entry: ~500-1000 bytes
Purpose: Internal auditing, appeals, debugging
Access: Server-side only, not broadcast
            

Side-by-Side Comparison

Field	Public	Internal	Why the difference?
uid	✓	✓	Both need user ID
username	✓	✓	For identification
ban_type	✓	✓	Public needs threat type
reason	✓	✓	Transparency in both
timestamp	✓	✓	Both track when
manual	✓	✓	Appeal eligibility
ban_id	✗	✓	Internal audit reference
msg_id	✗	✓	Evidence trail
server_id	✗	✓	Where caught (internal)
sim	✗	✓	Detection confidence
history	✗	✓	Repeat offender tracking
roles_backup	✗	✓	Appeal restoration data
source	✓	✓	Our source of the blacklist

Ban ID V2 Generation

Internal ban IDs are cryptographically random, not sequential:

def generate_ban_id() -> str:
    chars = string.ascii_letters + string.digits  # a-z, A-Z, 0-9
    return '-'.join(''.join(random.choices(chars, k=4)) for _ in range(6))

Result: aBc1-dEf2-gHi3-jKl4-mNo5-pQr6

Format: XXXX-XXXX-XXXX-XXXX-XXXX-XXXX (6 groups of 4 random alphanumeric)
Uniqueness: Regenerates if collision detected
Purpose: Appeal reference code (internal only, never shared)
            

Key Privacy Difference

Public database is loaded into RAM for fast lookups across servers. Every 50 servers has a copy for protection.

Internal database is server-side only. It contains sensitive audit data that never leaves our infrastructure. The message ID, similarity score, and role backups are used for appeals and debugging—not shared with anyone.

How Image Detection Works (Privacy-Respecting)

We use perceptual hashing, not facial recognition or content analysis:

User uploads image → Hash algorithm processes image → 20-char hash generated → 
Hash compared to known scams → Original image discarded from memory
            

Privacy benefit: We never store the actual image. When an image is detected as a scam, we store only a mathematical fingerprint. Images that are not detected are not stored. The image cannot be reconstructed from the hash.

What Never Touches Disk

Messages, links, and images are checked against our threat databases entirely in memory. If nothing matches, everything is discarded immediately. Nothing below is ever written to disk:

• Individual message content
• Full images (only hashes)
• User conversation history
• DM content
• Attachment metadata
• Voice/video channel activity
• User IP addresses

Legacy Ban IDs (V1)

A small number of older records (23 total) still use a legacy sequential Ban ID system rather than the random ID generation described in the Database Structure section above. These IDs are just incrementing numbers—no user data is encoded in them. If you were blacklisted under a V1 ID, contact staff and they can look it up for you.

Token Encryption (Hardened Fernet with Key Management)

Your refresh token is encrypted using a hardened implementation of Fernet symmetric encryption, with key versioning, expiration, and integrity verification:

Encryption Algorithm: Fernet (AES-128-CBC + HMAC-SHA256)
Key Storage: Server-side only, restricted file permissions (0o600)
Token Expiration: 90 days (configurable)
Integrity: SHA256 hash + HMAC comparison on every decrypt

Security Properties:
  Authenticated encryption (detects tampering)
  HMAC timing-safe comparison (prevents timing attacks)
  Token expiration enforced on every access
  Key never transmitted (server-side only)
  All operations logged for audit
            

Key Generation & Management

The encryption key is automatically generated on first run with cryptographically secure random data. Keys are stored server-side with restricted file permissions and never exposed.

Audit Logging

All token operations (encryption, decryption, expiration, tampering detection) are logged for security monitoring. User IDs are hashed in these logs — the full user ID only exists in memory during the operation itself.

What is /rejoin?

The /rejoin command allows users who have been removed or banned from a server to request re-entry. It uses Discord's OAuth2 guilds.join scope to add users back to servers they left or were removed from.

How /rejoin Works

The process involves three steps and uses stateful OAuth2 flow for security:

Step-by-Step Process:

1. User runs /rejoin command with server ID
2. Bot generates random state token (16 bytes hex)
3. Bot creates OAuth2 authorization URL with guilds.join scope
4. User clicks link → Discord asks for authorization
5. User authorizes → Discord redirects to OAUTH_REDIRECT_URI
6. Frontend captures redirect URL from browser
7. Bot extracts authorization code from URL
8. Bot exchanges code for access token (with guilds.join scope)
9. Bot calls Discord API: POST /guilds/{guild_id}/members/{user_id}
10. User is added to server
11. Session token cleaned up
                

Security Measures

  State Token Protection
  └─ Random 16-byte hex state token
  └─ Prevents CSRF attacks
  └─ Verified on callback

  Session Expiration
  └─ Tokens expire after 5 minutes
  └─ Prevents token reuse/hijacking
  └─ Timestamp verified on submission

  User Validation
  └─ Blacklisted users (rats) cannot rejoin
  └─ User ID verified against state token
  └─ Guild existence verified before OAuth

  Rate Limiting
  └─ Can only initiate one rejoin per 60 seconds
  └─ Prevents brute force attempts

  Scope Limitation
  └─ Only requests guilds.join, identify, offline_access
  └─ No access to DMs, messages, or guild data
  └─ Access token used only for guild membership

  Token Cleanup
  └─ State tokens deleted after use
  └─ Expired sessions automatically pruned
                

Privacy & Data Handling

What is collected:

During /rejoin flow:
├─ User ID (temporary, used only for this session)
├─ Guild ID (the server being rejoined)
├─ State token (16-byte random value)
├─ Timestamp (session creation time)
└─ Authorization code (immediately exchanged for token)

After rejoin completes:
├─ Session data deleted from memory
├─ State token removed
├─ Authorization code discarded
└─ Access token NOT stored (only used once to add user)

Long-term storage:
└─ NONE - No permanent record of rejoin requests
└─ Discord's audit log records the add member action
└─ User is simply a normal member of the guild
                

Potential Privacy Concerns & Why We're Transparent

The guilds.join scope is powerful and has been misused by malicious bots. Here's why we use it responsibly:

  Concern: Bots could add users to servers without consent
  Mitigation: 
  └─ User explicitly clicks authorize button
  └─ Discord shows explicit permission prompt
  └─ User can revoke access anytime in Discord settings
  └─ We only use it when user requests /rejoin

 Concern: Access tokens could be stolen/misused
 Mitigation:
  └─ Tokens are NOT stored anywhere
  └─ Used once and immediately discarded
  └─ Sent over HTTPS only
  └─ Expire after 5 minutes if not used
  └─ Can only add user to guild they requested

 Concern: User data could be exfiltrated
 Mitigation:
  └─ We only request guilds.join, identify, offline_access
  └─ We don't request message history, DM access, etc.
  └─ We only call: POST /guilds/{id}/members/{id}
  └─ No other API calls made with this token

 Concern: Offline access token misuse
 Mitigation:
  └─ Offline token requested but never stored
  └─ If stored, would only allow guild.join scope
  └─ User can revoke in Discord settings anytime
  └─ Token rotates if user re-authorizes
                

User Control

You have full control over your authorization:

To revoke access:
1. Go to User Settings → Authorized Apps
2. Find "Judicium" in the list
3. Click "Revoke" next to its entry
4. Confirm revocation

Effect:
├─ OAuth token becomes invalid
├─ Judicium can no longer use guilds.join
├─ You can still use /rejoin (new auth flow)
└─ Takes effect immediately
                

We believe in open communication with our community. This portal is updated regularly as our features evolve. If you have questions not covered here, please reach out. Source code available on request for independent security audits.

Judicium runs the following AI models on messages and images in protected servers. Text and image checks run in real time, and results are used only for the detection decision.

Image Models

#	Model ID (HuggingFace)	Stored As	Purpose
1	Falconsai/nsfw_image_detection	nsfw_falconsai	Primary NSFW image classifier (pipeline)
2	google/vit-base-patch16-224	image_classifier	General image classification (gore heuristic and "safe category" fast-pass)
3	openai/clip-vit-base-patch32	clip_processor + clip_model	CSAM detection (child-safety prompts), gore detection (weighted 0.6 in the gore ensemble), and cross-modal verification

Text Models

#	Model ID (HuggingFace)	Stored As	Purpose
4	unitary/toxic-bert	text_nsfw	Toxic / offensive text detection
5	michellejieli/NSFW_text_classifier	text_abuse	NSFW text classification

What Is Kept

Image hashes are saved only when an image is detected as a scam. Clean images are not stored, and model inputs and outputs for clean content are discarded after the check.

How long each type of data is kept.

• Cases, server blacklists, scammer records, ban records, exploit attempt records, MSID records, snapshots, user history, and audit logs are kept until they are removed manually. They are not automatically deleted.
• Bot logs, debug logs, console logs, token audit logs, and daily analytics are deleted automatically after 365 days. Only entries older than 365 days are removed. Newer entries remain.
• Rotated bot log backups are deleted automatically when their last write is over 365 days old.
• Message contents are deleted from Discord when a moderation action purges a user's messages. The bot does not keep a separate copy of message contents in its logs.