Standards comparison
Research, not an audit
These pages are research and development and may not match the live app. Do not treat this as an audit. Shared for testing and demo only. Please use responsibly.
This page is a coverage / gap map. It compares the draft in-house review in this folder (and the Glitr bar it checks) to common security frameworks, named protocol specs, and typical third-party audit process expectations.
It is not a compliance certificate, an ASVS score, an SSDF attestation, or a claim that Glitr matches Signal-app wire formats. It does not close the roadmap row for regular security audits. Catalog and method stay on Findings and Methodology.
Jump to: Process maturity · OWASP ASVS · OWASP MASVS · NIST SSDF · Protocol conformance · Summary
Status words on this page
| Word | Meaning |
|---|---|
| Covered | This folder or a linked control page already addresses the row with code-backed evidence |
| Partial | Some control exists; residual, platform gap, or honesty limit remains |
| Not assessed | Outside the static review method (dynamic test, lab, firm engagement) |
| N/A (architecture) | Control assumes a Glitr account/chat server or classic multi-tenant web auth; api-core is in-process |
These words are not proofs and do not upgrade GLITR-2026-010 (independent audit still Open).
Audit-process maturity
How this folder differs from a typical third-party messenger security assessment.
| Expectation | Typical third-party audit | This folder |
|---|---|---|
| Independence | External firm; engagement letter | In-house / AI-assisted notes |
| Method | Static + dynamic + often adversarial | Static review of workspace source, schemas, and tests |
| Severity | Often CVSS or a firm rubric | Custom Critical–Info by shipped-path impact (Methodology) |
| Scope lock | Tagged release or pinned commit | Current tree; not release-locked |
| Formal verification | Separate workstream if commissioned | Library ProVerif only; messenger not modeled (Verification report) |
| Remediation verification | Re-test after fixes | Draft catalog drops fixed rows; no signed re-test letter |
| Citation rule | Attestation language in a signed report | May cite as draft in-house review; may not as independent audit, pentest, or reason to put sensitive details in the demo |
Difference. A green Critical/High section here is an in-house static snapshot. It is not the same artifact as an independent firm report with dynamic testing against a live host.
Framework gap analysis
Glitr is a client-only messenger: no Glitr account server and no Glitr chat host. Many classic “server authentication / session / multi-tenant” ASVS rows are N/A (architecture). Where a row maps onto a shipped path, the Evidence column points at this folder or the product threat model.
OWASP ASVS (selected)
Selected Application Security Verification Standard families relevant to a client messenger and its PWA/native shells. Not a full ASVS checklist.
| ASVS family (selected) | Status | Evidence / difference |
|---|---|---|
| V2 Authentication (account passwords, MFA, credential recovery) | N/A (architecture) | No Glitr accounts. Unlock password is local mailbox seal, not server login (Client and storage). |
| V3 Session management (server sessions, cookies, logout) | N/A (architecture) | In-process api-core Session for process lifetime; no remote session cookie model. |
| V6 Cryptography (algorithms, key management, RNG reliance) | Partial | Cascade v3 fail-closed, signed SPKs, OTPK pool (GLITR-2026-014). Concurrent-init is custom, not Signal-spec (GLITR-2026-001). Side-channel lab Not assessed. |
| V8 Data protection at rest / in transit | Partial | Argon2id → AES-GCM mailbox seal; password/tokens scrubbed from glitr:connect (GLITR-2026-013). Git host still sees metadata (GLITR-2026-008). |
| V9 Communications (TLS, cert pinning, sensitive transport) | Partial | Git/WebRTC use platform TLS and peer DTLS; live path may use public STUN / direct ICE even when Tor signaling is on (GLITR-2026-003). Anonymity not claimed. |
| V14 Configuration (headers, CSP, secure defaults) | Partial | Production PWA injects CSP; isomorphic-git same-origin (GLITR-2026-020). unsafe-eval kept for Dioxus bridges (GLITR-2026-006). Hosted deploy headers Not assessed. |
| Input / output encoding (XSS-style injection into chat UI) | Covered | Chat text is an escaped text node (GLITR-2026-012). |
| Authorization between local UI and peer-facing routes | Covered | require_local / RequestSource::Peer reviewed in Methodology. |
| Push / notification subscription hygiene | Covered | No Web Push surface in whatsup (GLITR-2026-016). |
OWASP MASVS (selected)
Mobile Application Security Verification Standard rows that apply to Tauri / mobile shells. Desktop WebKit and mobile Arti paths are first-class in this product.
| MASVS theme (selected) | Status | Evidence / difference |
|---|---|---|
| Storage (secrets not in clear app prefs) | Partial | Unlock password and git tokens not persisted in glitr:connect (GLITR-2026-013). MLS export JSON is secret material if left unsealed (GLITR-2026-022). |
| Crypto | Partial | Same cascade bar as ASVS V6; library models do not prove the assembled messenger (Formal verification). |
| Network | Partial | Tor SOCKS / onion pairing on native; ICE/media may still be direct (GLITR-2026-003). |
| Platform / WebView bridge | Partial | document::eval bridges and CSP unsafe-eval (GLITR-2026-006). Linux WebKit auto-allows camera/mic (GLITR-2026-004). |
| Resilience / anti-tamper | Not assessed | No rooted-device, debugger, or binary-integrity program in this review. |
| Tor client trust on mobile | Partial | Mobile Arti storage uses dangerously_trust_everyone (GLITR-2026-005). |
NIST SSDF (high-level)
Secure Software Development Framework practices are about process, not algorithm choice. Mapping is coarse on purpose.
| SSDF practice area | Status | Evidence / difference |
|---|---|---|
| Prepare the organization (roles, secure design intent) | Partial | Product threat model + STRIDE language; not an org SSDF program. |
| Protect the software (trusted components, supply chain) | Partial | Vendored isomorphic-git same-origin (GLITR-2026-020). Reproducible builds Not assessed. |
| Produce well-secured software (design review, code review, testing) | Partial | This in-house static review + library tests/ProVerif. Product fuzzing and dynamic pentest Not assessed (Methodology). |
| Respond to vulnerabilities (intake, disclosure, patch verification) | Partial | Remediation maps fixes to IDs. No public CVE program or independent re-test claimed. Independent audit remains Open (GLITR-2026-010). |
Protocol conformance
Named specs and product expectations versus what Glitr ships. This section synthesizes existing audit pages; it does not re-run a code review.
Signal Protocol / Double Ratchet / prekeys
| Standard expectation | Spec-faithful X3DH/PQXDH + Double Ratchet session setup, including documented concurrent-init / glare behavior; one-time prekeys consumed so they cannot be reused by every fetcher. |
| Glitr behavior | Cascade embeds Signal (and PQXDH) under MLS and outer RSA+ML-KEM. Signed SPKs verified; OTPK pool and rotate-prekeys exist (GLITR-2026-014). |
| Difference / honesty | Not Signal-app wire compatible. Dual first-message glare uses a custom lexicographic initiator yield (maybe_yield_initiator) — not a Signal-spec procedure (GLITR-2026-001). Git mailbox cannot burn OTPKs for every fetcher (Residual risk). |
PQXDH / ML-KEM hybrid
| Standard expectation | PQXDH composition with post-quantum KEM; clear trust boundary between library proofs and product wiring. |
| Glitr behavior | PQXDH + ML-KEM-1024 hybrid in the cascade stack; library ProVerif / pinned lattice proofs on handshake crates. |
| Difference / honesty | Library models are a Dolev–Yao network attacker with honest endpoints. They do not model the git host, CORS proxy, or stolen unlocked device (Verification report). |
RFC 9420 MLS
| Standard expectation | MLS groups with epoch advancement, key-package lifecycle, and (for group PCS claims) member update/remove. |
| Glitr behavior | Pairwise MLS is a thin RFC 9420 suite-1 façade over mls-rs, required for cascade session establishment. Group chat uses N-party GroupSession with per-member outer seals (MLS pairwise review; GLITR-2026-002). |
| Difference / honesty | Pairwise MLS is defense-in-depth, not a substitute for claiming full TreeKEM group PCS without the group path. Formal-verify badges in the mls repo remain stubs. BasicCredential only; no external join. |
Tor / anonymity product expectations
| Standard expectation | “Tor on” often read as path anonymity for signaling and media. |
| Glitr behavior | Native Tor: SOCKS for git, onion pairing / live signaling when tor+webrtc prefs allow (Tor). |
| Difference / honesty | ICE/STUN/media may still use public or direct paths (GLITR-2026-003). Browser does not run Arti. Anonymity is out of scope as a product claim (Security audit). |
STRIDE (threat-model relationship)
| Standard expectation | STRIDE catalogs spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege against assets. |
| Glitr behavior | Product attackers and STRIDE mapping live in the threat model; this folder checks whether shipped code matches that intent. |
| Difference / honesty | This page does not re-run STRIDE. Threat-model Open / leftover rows are not closed by an in-house findings ID unless the catalog says so. |
Out-of-band invites
| Standard expectation | Pairing material treated as confidential introduction secrets when the threat model requires it. |
| Glitr behavior | wu1: / on1: invites are plaintext out of band (GLITR-2026-009). |
| Difference / honesty | Accepted residual. Do not claim Pair now or onion QR invites are confidential (Report). |
Summary
| Lens | Closest standard | Glitr stance in one line |
|---|---|---|
| Process maturity | Typical third-party appsec engagement | Static in-house draft; not independent; no CVSS; no dynamic pentest |
| Application controls | OWASP ASVS (selected) | Client-only architecture makes many auth/session rows N/A; crypto/data/comms/CSP are Partial with named residuals |
| Mobile / shell | OWASP MASVS (selected) | Storage hygiene positives; WebView/Tor/WebKit platform lows remain |
| Secure development | NIST SSDF (high-level) | Threat model + this review + library tests; SSDF program and independent response not claimed |
| Handshake / ratchet | Signal-spec / PQXDH | Used inside cascade; not wire-compatible; custom concurrent-init; OTPK burn incomplete on git |
| Groups | RFC 9420 MLS | Pairwise façade + N-party GroupSession; stub formal-verify badges |
| Anonymity | Tor product expectations | Onion/SOCKS help; ICE/media may still leak; anonymity not claimed |
Honesty gaps to keep visible
- Independent messenger audit: Open (GLITR-2026-010).
- Concurrent-init: custom product rule, not Signal-spec (GLITR-2026-001).
- Tor ≠ anonymous live media (GLITR-2026-003).
- Git host metadata and OTPK burn limits (GLITR-2026-008; Residual risk).
- Plaintext OOB invites (GLITR-2026-009).
Honesty rule
You may cite this page as a standards coverage map for the draft in-house review. You may not cite it as ASVS/MASVS/SSDF certification, Signal or MLS conformance attestation, a pentest report, or a substitute for an independent audit.
Start of this folder: Security audit. Method: Methodology. Dated view: Report.