Threat-model report
This report is for product readers, then developers and security reviewers. It says what the Glitr client addresses against its own goal, and what is still missing against an ideal messenger. It is not an audit, not a theorem, and not a score against another app. Implementation findings with IDs live on the security-audit report — in-house review, not an independent audit.
| Field | Value |
|---|---|
| Date | 3 October 2026 |
| Subject | Glitr product (whatsup + in-process stack) |
| Audience | Product / exec readers, then developers and security reviewers |
| Status | Research report — not an audit |
| Not claimed | Formal verification of the messenger; anonymity; nation-state safety |
Jump to: Executive summary · Glitr bar · Ideal bar · You may say / may not
Path pages: Assets and attackers, Platforms, Git mailbox, Live links, Tor, Devices and storage, Residual risk. Library models: Verification report. In-house findings: Security audit.
How to read the words
| Word | Meaning |
|---|---|
| Documented | Stated as product behavior |
| Mitigated | A control exists for that attacker and that asset |
| Partial | A control exists and is incomplete, platform-specific, or easy to bypass |
| Open | No product control, or the control is not a claimed path |
| Out of reach | The property conflicts with a shipped path (git-host metadata, WebRTC ICE without a mixnet) |
These words are not proofs. They are not the formal-verification words (Tested / Modeled / Type-checked).
Two bars, labeled as such:
- Glitr bar — protect message content from the host; do not expect the host to be unaware that you chat.
- Ideal bar — properties a theoretically maximal messenger would have. Many are Open or physically hard. Listing them is the point.
The roadmap lists features that would make a messenger as strong as it can be. This page does not score Glitr against Signal, WhatsApp, or any other product. The leftover catalog stays on Residual risk.
Executive summary
Addressed (Glitr bar). api-core runs in process. There is no Glitr account server and no Glitr chat host. Message bodies, attachment bytes, git-brokered SDP, and live file bytes use the recipient cascade (AES → Signal → PQXDH, then RSA hybrid → ML-KEM). Sealed mailbox folders use Argon2id then AES-GCM. There is no phone-number directory. Each contact has one protocol session shared across git, WebRTC, and onion. Native desktop and TUI can send git HTTPS through Tor SOCKS and pair over a hidden service. A dedicated threat-model draft exists. Four handshake / crypto libraries have models — not the messenger.
Outstanding (Glitr bar). Git tokens may still persist in glitr:connect. A user-supplied CORS proxy still sees git HTTP. Live WebRTC uses public STUN; ICE can leak IPs. Pair now (wu1:) and onion (on1:) invites are plaintext out of band. Live typing, receipts, and call signaling are DTLS-only. The messenger is closed-source and unaudited. A git host still sees activity, access, and IPs.
Ideal bar in one sentence. A maximal messenger would also need anonymity, sealed metadata, audited open source, disappearing messages, hardware-backed keys, mixnet or PIR delivery, reproducible builds, and a compromised-endpoint story Glitr does not claim. No messenger reaches that bar. The list below is a gap map, not a launch checklist.
The app is shared for testing and demo. Do not put sensitive details in it.
Glitr bar
Protect message content from the host. Do not expect the host to be unaware that you chat.
Roadmap rows marked done are not upgraded here when the threat model already calls them Partial (git SDP is cascaded; Pair now and onion invites are still plaintext).
Transport
| Property | Status | Evidence | Where |
|---|---|---|---|
| No Glitr chat or account server | Mitigated | In-process api-core; glitr.io is docs | Architecture |
| Git mailbox you own | Documented | Push / poll through a host you choose | Git mailbox |
| Live WebRTC is peer-to-peer | Documented | Data channel after ICE; STUN is still public | Live links |
| Native onion live path | Partial | Arti after login; browser does not link it; mobile is not a claimed path | Tor |
| Git over Tor SOCKS | Partial | Native desktop / TUI only | Tor |
| Offline delivery | Partial | Git-URL contacts only. Pair now and onion have no mailbox fallback | Network |
| Host metadata / IPs / collaborators | Documented | Expected on this bar | Encryption visibility |
| Host terms of service | Open | A generic host may throttle, block, or close the repo | Git hosts |
Encryption
| Property | Status | Evidence | Where |
|---|---|---|---|
| Recipient cascade on bodies and files | Mitigated | Same stack on git outbound, live chat, live file bytes | Architecture |
| Git-brokered SDP cascaded | Mitigated | Inner offer/answer encrypted to the contact | Live links |
| Pair now / onion invite confidentiality | Partial | Plaintext wu1: / on1: QR or paste | Live links, Tor |
| Live control frames | Partial | Typing, receipts, call signaling are DTLS-only | Live links |
| Keys per contact | Mitigated | One ProtocolSession (Signal + PQXDH) per contact | Data structures |
| Password at rest | Mitigated | Argon2id (19 MiB, t=2, p=1) → AES-256-GCM on sealed types | Devices and storage |
| Forward secrecy as a product claim | Partial | Double Ratchet is documented in libraries; the messenger is unaudited | Cryptography |
| Deniable authentication | Open | Not claimed on product crypto pages | Roadmap |
Identity
| Property | Status | Evidence | Where |
|---|---|---|---|
| No registration / no phone directory | Mitigated | No Glitr account | What Glitr is |
| TOFU + safety number | Partial | Hello Store / Match / Mismatch; no global PKI | Assets and attackers |
| You hold keys and tokens | Partial | No full key-management UX; GUI stores the connect password | Devices and storage |
Platforms
| Property | Status | Evidence | Where |
|---|---|---|---|
| Desktop identity keys | Mitigated | Real RSA keygen | Platforms |
| TUI does not persist the encryption password | Mitigated | Merge leaves password as it was | Platforms |
| Web first-run identity | Mitigated | WebCrypto RSA-4096; no shared demo keys | Platforms, Security audit |
| GUI password persist | Mitigated | Unlock password not written; tokens may still | Devices and storage |
| Web git path | Partial | No default public proxy; user-supplied proxy still sees git HTTP | Git mailbox |
| Mobile as a product path | Open | Nightly spike; Tor not claimed | Platforms |
Trust documentation
| Property | Status | Evidence | Where |
|---|---|---|---|
| Product threat-model draft | Documented | This folder | Threat model |
| Library formal verification | Documented | Four libraries; messenger not claimed | Formal verification |
| Independent audit of the messenger | Open | Closed-source; none done. In-house review does not close this row | Residual risk, Security audit |
| Open source of the messenger | Partial | signal-protocol is public; the rest is not | Architecture |
Ideal bar
Properties a theoretically maximal messenger would have. Status here is versus that ideal, so a Glitr Mitigated row on the first bar is often Partial or Open on this one.
No messenger reaches this bar. This list is a gap map, not a launch checklist.
Confidentiality and keys
| Property | Status vs ideal | Glitr today |
|---|---|---|
| Hardware-backed / unextractable long-term keys | Open | Software keys in process memory and sealed files |
| No shared demo identity keys | Mitigated | Web first-run uses WebCrypto RSA-4096 |
| Encryption password never written to disk | Mitigated | GUI and TUI do not persist the unlock password; tokens may still |
| Post-compromise security as a product claim | Partial | Library Double Ratchet; unaudited composition |
| Key-compromise impersonation resistance as a product claim | Open | Not claimed |
| Deniable authentication | Open | Roadmap: planned |
| Disappearing / unsaved messages | Open | Not in the data model |
| Screenshot / screen-security resistance | Open | Notifications and UI can show previews |
| Constant-time / side-channel story | Open | Not modeled |
| Published fuzzing of every frame parser | Partial | Some library fuzz targets; not a product program |
Metadata and anonymity
| Property | Status vs ideal | Glitr today |
|---|---|---|
| Anonymity | Open | Roadmap lists it; product docs disclaim it |
| Sealed sender / hidden correspondent graph | Open | Outbound recipientId and collaborator lists are visible |
| Sealed-sender style receipts | Open | Git readreceipts/ are intentionally readable |
| Padding, cover traffic, timing randomization | Open | Host sees sizes, dates, and how often the repo moves |
| No public STUN | Open | stun:stun.l.google.com:19302 |
| No third-party CORS proxy | Partial | Empty default; user may still paste a public proxy |
| No git-host access list | Out of reach | A clone or collaborator list is how git sharing works |
| Mixnet or PIR mailbox | Out of reach | A git host always sees that a mailbox is busy |
| Live media over an anonymity network | Out of reach | Live WebRTC does not ride Tor as shipped |
| Contact discovery that does not leak the social graph | Partial | No phone-number directory; adding a git URL still names a peer |
Transport and groups
| Property | Status vs ideal | Glitr today |
|---|---|---|
| Encrypted out-of-band pairing | Open | wu1: / on1: are plaintext QR or paste |
| Cascade on live control frames | Open | Typing, receipts, call signaling are DTLS-only |
| Group protocol with membership secrecy | Open | Fan-out: one outbound copy per member; host can count them |
| Offline fallback on every contact kind | Partial | Git-URL only |
| First-party mailbox free of generic git ToS risk | Open | A later possibility; not something this model waits on |
| WebRTC without ICE address leakage | Out of reach | Ordinary ICE; no mixnet in the messenger bundle |
Device and supply chain
| Property | Status vs ideal | Glitr today |
|---|---|---|
| Open source of the messenger | Partial | Signal library only |
| Reproducible builds / binary and WASM transparency | Open | Not claimed |
| SRI on every web fetch | Open | Service worker pins caches; esm.sh still a remote |
No document::eval / CDN trust | Open | WebView bridge and GitHub Pages / esm.sh |
| Independent audit + ongoing program + bug bounty | Open | None |
| Formal verification of product send / poll / merge | Open | Library models only |
| Mobile as a claimed, entitled path | Open | Nightly spike |
| Multi-device merge with a second factor | Open | Live pair exchanges public mailbox rows; long-term secrets stay off the DC |
| Compromised-endpoint resistance (enclave, attestation) | Open | Residual for any app that decrypts on the device |
| Memory-safe language | Documented | Rust cores. That is not an audit |
Policy and operations
| Property | Status vs ideal | Glitr today |
|---|---|---|
| Host-policy independence | Open | Generic git hosts may close a mailbox |
| Sealed local receipts and signaling files | Open | Coordination rows stay readable so peers can work without your password |
| Nation-state “safe forever” | Open | Not a product target |
A compromised endpoint, a hostile OS, or a host who already has the encryption password ends the Glitr bar and the ideal bar. Residual risk keeps that leftover.
You may say / you may not
What you can say in a review without treating this page as an audit.
You may say
- Message content is cascaded to the contact so a git host is not reading “see you at 6.”
- Sealed mailbox folders need the connect password.
- There is no Glitr chat server and no Glitr account.
- A dedicated product threat-model draft exists, including this report.
- Four libraries have production tests and symbolic models. The messenger does not claim formal verification.
- Native builds can send git through Tor SOCKS and chat on an onion link. The browser does not run Arti.
- Neither the TUI nor the GUI persist path writes the encryption password. Git tokens may still persist on the GUI path.
You may not say
- Glitr is the theoretically most secure messenger, or close to that bar.
- The messenger is formally verified, audited, or anonymous.
- Closing Critical audit rows means Medium findings (CSP, STUN, …) are fixed.
- DTLS is enough for chat bodies or files.
- Pair now or onion QR invites are confidential.
- ProVerif covers the git host, a CORS proxy, or a stolen device.
- Roadmap “done” on secure signaling means every introduction is encrypted.
- Rust, a cascade stack, or library proofs make a stolen unlocked session safe.
FAQ sentence: Glitr aims to keep message content from the host. It does not hide that you chat. The ideal-messenger list is a gap map. The app is a demo. Do not put sensitive details in it.
Start of this folder: Threat model. Leftover catalog: Residual risk. Library report: Verification report.