IranTalk context pack: Context pack: safety / بستهٔ زمینه: امنیت
It holds the threat model, the "Before you switch on a radio" page and the logging table.
Built from the signed list version 1 (issued 2026-10-01, valid until 2026-10-31).
Project key fingerprint: (not generated yet)
Farsi first, then English. Source: https://docs.irantalk.com/ai

===== fa: پیش از روشن کردن رادیو =====

# پیش از روشن کردن رادیو

در پایان این صفحه می‌دانید دستگاه، نام و رادیویتان چه چیزی را لو می‌دهد، و IranTalk دربارهٔ شما چه چیزی را نگه می‌دارد و چه چیزی را نه.

بی‌اینترنت

## ۱. دستگاه مدرک است

دستگاه LoRa یک مدرک فیزیکی است. پیش از خرید تصمیم بگیرید چه کسی بداند آن را دارید. اگر می‌توانید، دستگاه را جایی که می‌خوابید نگه ندارید و از آن‌جا ارسال نکنید.

## ۲. نام و هویت

1. هرگز نام واقعی خود را در نام نمایشی یا اعلان‌ها نگذارید.
2. اگر برای کارهای مختلف از یک دستگاه استفاده می‌کنید، برای هر کار یک هویت جدا بسازید.
3. پیش از آن‌که لازم شود، یاد بگیرید هویت را چطور پشتیبان بگیرید و چطور پاک کنید.

## ۳. رادیو

Reticulum محتوا و مسیر پیام‌ها را پنهان می‌کند، **نه** این واقعیت را که دستگاهی روی LoRa ارسال می‌کند. محل یک فرستندهٔ رادیویی را می‌توان پیدا کرد.

1. کم ارسال کنید.
2. کم اعلان (announce) بفرستید.
3. آنتن را بلندتر بگذارید تا با توان کمتر برد بیشتری داشته باشید.

## ۴. بررسی

پیش از استفاده از هر نشانی، اثر انگشت را بررسی کنید: [بررسی اثر انگشت و فهرست امضاشده](/start/verify). اثر انگشت اشتباه یعنی متوقف شوید.

## ۵. ما دربارهٔ شما چه می‌دانیم

ما حساب کاربری نداریم. این جدول همهٔ چیزی است که سرورهای ما نگه می‌دارند. اگر حکم دادگاهی برسد، همین است که وجود دارد.

| سرویس | چه چیزی نگه داشته می‌شود | چه مدت |
|---|---|---|
| سایت، راهنما، داشبورد | شمارش‌های کلی؛ شمارنده‌های محدودیت نرخ فقط در حافظه | ۲۴ ساعت / ذخیره نمی‌شود |
| درخواست پل | هیچ چیز قابل شناسایی | — |
| ثبت گره (برای گره‌داران خارج از ایران) | هش هویت، نشانی‌ها، ردهٔ منطقه، سابقهٔ تأیید | تا کنار گذاشتن گره + ۹۰ روز |
| صندوق گزارش | هش فرستنده، زمان، محتوا | ۷ روز / ۳۰ روز پس از پایان رسیدگی |
| Reticulum و LXMF | گزارش‌های سطح notice | ۷ روز |
| اتاق گفتگو (RRC) | فقط هشدارها: نه ورود و خروج، نه نام مستعار، نه پیام؛ فهرست اتاق‌ها (نام، موضوع، هش گردانندگان) | تا حذف اتاق |
| Matrix | آنچه سرور برای کار کردن لازم دارد؛ بدون گزارش IP پس از ۲۴ ساعت | طبق تنظیمات نگهداری |
| MQTT | بدون گزارش IP کاربران | — |

## ۶. آنچه نمی‌توانیم از آن محافظت کنیم

- دستگاهی که از قبل آلوده شده است.
- کسی که رادیوی شما را ردیابی می‌کند (بخش ۳).
- در اتاق‌های گفتگو، سرورِ اتاق پیام‌ها را می‌بیند. پیام‌های مستقیم (Ratspeak، Sideband) سرتاسر رمزنگاری شده‌اند؛ اتاق‌ها نه.
- ناشناس ماندن در برابر کسی که کل اینترنت را تماشا می‌کند.

===== en: Before you switch on a radio =====

# Before you switch on a radio

By the end of this page you will know what your device, your name and your radio give away, and what IranTalk keeps about you and what it does not.

No internet

## 1. The device is evidence

A LoRa device is physical evidence. Decide before you buy it who may know you have it. If you can, do not keep it, or transmit from, where you sleep.

## 2. Name and identity

1. Never put your real name in a display name or an announce.
2. If you use one device for different things, make a separate identity for each.
3. Learn how to back up and how to wipe an identity before you need to.

## 3. The radio

Reticulum hides the content and the route of messages, **not** the fact that a device is transmitting on LoRa. A radio transmitter can be located.

1. Transmit little.
2. Announce rarely.
3. Put the antenna higher, so that less power reaches further.

## 4. Verification

Before using any address, check the fingerprint: [Check the fingerprint and the signed list](/start/verify). A wrong fingerprint means stop.

## 5. What we know about you

We have no user accounts. This table is everything our servers keep. If a court order arrives, this is what exists.

| Service | What is kept | How long |
|---|---|---|
| Site, guides, dashboard | aggregate counts; rate-limit counters in memory only | 24 hours / not stored |
| Bridge request | nothing identifying | — |
| Node registry (operators outside Iran) | identity hash, addresses, region class, approval audit | until the node is retired + 90 days |
| Report inbox | sender hash, timestamp, payload | 7 days / 30 days after the report is closed |
| Reticulum and LXMF | notice-level logs | 7 days |
| Chat hub (RRC) | warnings only: no joins, nicknames or messages; the room list (names, topics, operator hashes) | until the room is removed |
| Matrix | what the homeserver needs to work; no IP logs beyond 24 hours | per retention configuration |
| MQTT | no client IP logging | — |

## 6. What we cannot protect you from

- A device that is already compromised.
- Someone tracking your radio (section 3).
- In chat rooms, the room's server sees the messages. Direct messages (Ratspeak, Sideband) are end-to-end encrypted; rooms are not.
- Anonymity against someone watching the whole internet.

===== docs/02-threat-model.md =====

# 02 — Threat model

## Assets we protect

| Asset | Why it matters |
|---|---|
| Identity of people inside Iran who use or run nodes | Physical safety |
| Content of messages and reports | Safety of sources and subjects |
| Availability of the connect page and entry nodes | The whole point |
| Integrity of published software, addresses and node lists | An impostor node or binary is worse than none |
| Operator identities and infrastructure | Continuity; legal exposure |

## Adversaries

**A1 — State censor (network).** Controls Iranian ISPs and the border gateway. Capabilities:
DNS poisoning, SNI/TLS filtering, protocol whitelisting (DNS/HTTP/HTTPS only during
shutdowns), IP range blocking, throttling, full shutdown. Reads any unencrypted traffic.
Can run active probes against suspected bridges.

**A2 — State security (physical).** Can detain people, seize devices, demand passwords,
and monitor RF. A LoRa handheld is physical evidence. A public list of nodes is a map.

**A3 — Impostor.** Anyone can stand up a fake "IranTalk" entry node, website or APK. Over a
blocked internet, users cannot easily tell which is real.

**A4 — Abuser / spammer.** Floods propagation nodes, Meshtastic channels or Matrix rooms;
submits garbage to the reporting channel; requests bridges in bulk to burn them.

**A5 — Hostile actor targeting operators.** Doxxing, legal pressure, DDoS, takedown
requests to hosting providers, domain seizure, phishing for operator credentials.

## What we do about it

| Threat | Control | Doc |
|---|---|---|
| Domain and IPs blocked | Multi-channel publishing; mirrors; domain rotation rule; diverse providers | 03, 06, 16 |
| Protocol whitelist | WebTunnel/Snowflake bridges that look like HTTPS; Reticulum-over-HTTPS bounty | 06 |
| Full shutdown | Tier 0: LoRa meshes, store-and-forward, gateway kits, satellite datacast | 04, 05, 09, 15 |
| Enumeration of inside users | No in-country listing; no accounts; no logs with identifiers; announces without names | 01, 12, 17 |
| Impostor nodes/binaries | Signed manifest; reproducible builds where possible; fingerprint on every channel | 10, 11 |
| Spam on the mesh | LXMF stamps/tickets, propagation node limits, Meshtastic channel keys, rate limits | 04, 05, 12 |
| Operator exposure | Separate operator identities, hardware keys, no personal details in WHOIS/registries, legal review | 17, 18 |
| Loss of the founder | Multi-maintainer keys, infra in git, documented succession | 16, 19 |

## What we accept

- Reticulum hides content and routes, not the fact that a device is transmitting on LoRa.
  RF direction-finding is a real risk inside Iran; we say so in every user guide.
- Our out-of-country servers are public and will be blocked. That is expected; it is why
  there are tiers.
- We cannot verify who is on the other end of a report. The newsroom verification process
  is editorial, not cryptographic.
- A determined state can block everything in Tier 1 and 2. Tier 0 exists for that case and
  is slower, smaller and harder.

## Non-goals

- Anonymity against a global passive adversary.
- Protecting a user whose device is already compromised.
- Defending against a court order in the hosting jurisdiction (we minimise what exists to
  be ordered, see 17).

## Changelog

- 2026-10-01 — Initial version.

===== docs/17-security-and-opsec.md =====

# 17 — Security and opsec

## Operators

- **Separate identities.** Project work uses a project email, project handles, project
  payment methods where possible. WHOIS privacy on every domain. No personal names in
  registries, commit metadata or hosting accounts beyond what the provider legally requires.
- **Hardware keys** for every provider login, Git host, Cloudflare, Coolify, Matrix admin.
  No SMS 2FA anywhere.
- **Signing keys** (11) live on hardware keys or an offline machine; never on a server.
- **Shared accounts** are forbidden; each maintainer has their own, with least privilege.
- **Devices**: full-disk encryption, auto-lock, no project credentials on phones that travel
  to high-risk jurisdictions.
- **Phishing** is the realistic attack: the project will be targeted with fake
  "Hetzner/Cloudflare/GitHub" mails. Rule: never act on a link in an email; log in from a
  bookmark.

## Servers

- SSH keys only, non-standard port optional, fail2ban, unattended security upgrades, ufw
  default deny, services bound to the minimum interface (bridge API on the private IP only).
- Tier 2 web behind Cloudflare for DDoS; Tier 1 hosts are expendable and rebuildable.
- Secrets via `sops`; `/etc/default/*` files are mode 640, root:service.
- Each box has one job; a compromise of the Matrix box must not reach the Reticulum box.

## Logging policy (published)

| Service | What we keep | How long |
|---|---|---|
| Landing/docs/dashboard | aggregate counts; rate-limiter keys in memory | 24 h / none persisted |
| Bridge request | nothing identifying | — |
| Node registry | identity hash, addresses, region class, approval audit | until retired + 90 d |
| Report inbox | sender hash, timestamp, payload | 7 d / 30 d after terminal state |
| Reticulum/LXMF | notice-level logs | 7 d |
| Chat hub (RRC) | warnings only: no joins, nicknames or messages; room registry (names, topics, operator hashes) | until the room is removed |
| Matrix | what the homeserver needs to function; no IP logs beyond 24 h | per retention config |
| MQTT | no client IP logging | — |

This table is published on the docs site. If a court order arrives, this is what exists.

## Users

The user safety guide (docs site, Farsi) covers, in this order:

1. The device is evidence; decide who knows you have it.
2. Identity hygiene: no real name in display names or announces; a new identity per role
   if needed; how to back up and how to wipe.
3. Radio hygiene: transmit less, announce rarely, antenna placement vs exposure.
4. Verification: the fingerprint, how to check the manifest, why a wrong fingerprint means
   stop.
5. What IranTalk knows about you (the logging table above) and what it cannot protect
   against (the threat model, in plain words).
6. Reporting: what to send, what to delete afterwards.
7. Asking an AI: a cloud AI sees what you ask it, like Telegram sees what you ask the bot;
   a chat with a local model is still a file on your device; the privacy ladder of docs/23
   says what never to paste.

## Incident response

- Classes: key compromise, server compromise, impostor site/binary, operator targeted,
  domain seized. Each has a runbook (`runbooks/`).
- First action in every class: post a signed notice in the Matrix announcements room and
  issue a new manifest if any address or key changed.
- Post-incident: a public write-up within 14 days unless it endangers someone.

## Changelog

- 2026-10-01 — Initial version.
- 2026-10-24 — Logging policy row for the mesh chat hub (docs/07).
- 2026-10-25 — The user safety guide gets an item on asking an AI (docs/23).