Channel Monitor — Security
What OmniGest stores, how it's encrypted, and how to revoke access.
What gets stored in the database
When you complete /monitor_setup, OmniGest stores these fields in the monitor_sessions table:
| Field | Content | Encryption |
|---|---|---|
api_id |
Your Telegram API id (numeric) | Plaintext |
api_hash_encrypted |
Your Telegram API hash (32 hex) | Fernet (AES-128-CBC + HMAC-SHA256) |
session_string_encrypted |
Full Telethon session string | Fernet |
phone_last4 |
Last 4 digits of the secondary number | Plaintext (UX only) |
status |
active / revoked / banned / flood_wait | Plaintext |
Fernet encryption uses the same ENCRYPTION_KEY that protects other secrets in OmniGest (e.g., clone bot tokens, affiliate app secrets). It's rotated only by the operator, never via UI.
What OmniGest never stores
- Your SMS code — never touches the bot. You type it locally in
generate_monitor_session.py. - Your 2FA password — same as above.
- Raw product images — only URLs are cached (24h TTL).
- Your secondary account's contacts, message history, or profile data beyond what's needed for scraping.
Threat model: what if my session string leaks
A Telethon session_string is equivalent to a password for your Telegram account. Someone with it can:
- Read your inbox as you.
- Send messages as you.
- Access groups and channels you're in.
This is why we strongly recommend a secondary account — not your personal one. If a breach happens, you lose the secondary, not your identity.
Mitigations already in place:
- Encrypted at rest (Fernet).
- Not transmitted in plaintext over the wire (DM wizard uses Telegram's MTProto encryption).
- Code handling the session string has no logging — it's never written to disk outside the DB.
How to revoke access
You control the session string. To kill it immediately:
- Open Telegram on your phone with the secondary account.
- Settings → Devices → Active sessions.
- Find the session created by the session generator (usually named "Telethon" or similar).
- Tap it → Terminate session.
OmniGest detects revocation at the next scrape (within 1 hour):
- Marks
monitor_sessions.status = 'revoked'. - Stops scraping for that owner.
- Sends you an alert DM: "🚨 Your monitor session has been revoked. Regenerate with
scripts/generate_monitor_session.pyand/monitor_setup."
You can also remove the monitor data voluntarily:
/monitor_sources del @channel1
/monitor_sources del @channel2
…and the admin can flip MONITOR_ENABLED=false in .env to stop everything without deleting DB rows.
Multi-tenant isolation
Every database query in Channel Monitor takes owner_id as an explicit parameter. Callback handlers verify callback.from_user.id == candidate.owner_id before doing anything. A cross-owner access attempt is logged as a security warning and rejected. You will never see someone else's candidates or destinations.
GDPR and retention
- Candidates in final state (
sent,ignored,expired) are auto-deleted after 30 days. - Product image cache is deleted after 7 days.
- No image bytes are persisted — only URLs.
- On account deletion, all
monitor_*rows for the owner are removed (cascade).
Legal note on scraping
By providing your Telegram account for scraping, you accept responsibility for compliance with Telegram's Terms of Service. The secondary account reads public channel posts at a very low rate (once per hour per source). This is usually within acceptable limits, but Telegram can change its policy at any time. We recommend:
- Use a secondary account.
- Don't scrape more than ~10 channels total.
- Don't combine with other heavy Telethon usage on the same account.