* docs: correct inaccurate privacy and metadata claims
Several documented guarantees did not match the implementation. These
matter more than ordinary doc drift: someone deciding whether to carry
this phone to a protest reads these sentences as the threat model.
- Peer IDs were described as "short ephemeral IDs derived per session"
that "rotate periodically" and "prevent tracking". They are the first
8 bytes of the Noise static key fingerprint, stable across sessions
and reboots, and replaced only by a panic wipe. Corrected in the
whitepaper (§3, §8), IdentityModels, and BitchatProtocol, whose
header notes claimed "no persistent identifiers in protocol headers"
while every header carries exactly one.
- "No plaintext message content is ever written to disk" was false for
accepted media, which is stored unsealed under the platform's
data-protection class. Narrowed to what actually holds.
- Padding was described as applying to all packets but fragments. Only
noiseEncrypted and noiseHandshake frames are padded; the pad bytes
equal the pad length rather than being random; and because that
length must fit one byte, a frame needing over 255 bytes of padding
is emitted unpadded. Documented in the whitepaper (§4.1) and
MessagePadding.
- The gossip archive window is 6 hours in production, not the
15 minutes claimed in PRIVACY_POLICY.md and the privacy assessment.
The 15-minute figure is the struct default that BLEService overrides.
- The privacy assessment credited iOS BLE address randomization without
noting that stable app-layer identifiers defeat it.
The whitepaper's future-work list now names the changes these
corrections imply: rotating on-air identity, padding for non-Noise
types, and making the announce neighbor list optional.
No behavior change; comments and documentation only.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: correct the same claims in the README
The README repeats two of the claims corrected elsewhere in this PR, and
it is the document people actually read before deciding to trust the app.
- "no persistent identifiers" is the inverse of what the mesh does; it
now points at the whitepaper's identity and metadata sections.
- "end-to-end encryption with forward secrecy" holds for live Noise
sessions but not for sealed store-and-forward mail, which the
whitepaper already flags as its main cryptographic trade-off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Split-out safe half of #1437 (the kind-1402 wire migration stays held for Android coordination). Docs (README/WHITEPAPER/PRIVACY_POLICY/privacy-assessment) now describe the actual proprietary DM construction — kind 1059 gift wrap carrying XChaCha20-Poly1305 with a 24-byte nonce, base64url v2: framing, and an HKDF that borrows the nip44-v2 info label but is not the NIP-44 key schedule — instead of claiming NIP-17/44/59.
Hardens the existing legacy inbound path: 64 KiB ciphertext cap before decode (~46x the largest producible legacy envelope), outer kind/recipient-tag/signature binding, tagless kind-13 seal binding, unsigned kind-14 inner binding, inner tags restricted to the two shapes deployed clients emit (verified against every historical iOS release and a fixture frozen from Android production), SecRandomCopyBytes failure now throws, non-UTF-8 plaintext now throws instead of returning empty. Adds frozen cross-platform fixtures with hash-pinned generators; interop-reviewed with no rejection surface for deployed clients.
Replaces the share-extension handoff that auto-sent shared text/URLs into the current channel with a validated, single-slot 24h envelope that shows the destination and a bounded preview and requires an explicit tap to copy into the composer — it never sends. Rejects malformed/oversized/control-character/non-HTTP(S)/expired payloads (including bidi-override U+202E), and clears on consume/cancel/expiry/panic.
Rebased onto main with Persian strings added for all new keys (30-locale coverage verified), plus a panic-recovery clear so an envelope staged during an interrupted wipe cannot survive relaunch.
* Make panic wipe deterministic and device-bound
* Scope install markers to iOS
* Harden panic recovery and service shutdown
* Invalidate queued BLE ingress during panic
* Harden panic keychain and media cleanup
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: jack <jack@deck.local>
Centralize PTT and voice audio-session ownership, harden courier/bridge/outbox delivery and recovery, correct location and delivery-state races, add privacy/release metadata, and ship reproducible universal Arti slices with Release CI coverage.
Validated by the full iOS suite, repeated audio/fragment/performance regressions, BitFoundation tests, strict lint and dead-code analysis, universal iOS Release builds, and iOS/macOS archives.
Vendored arti.xcframework rebuilt from source (Rust 1.96.0, normalized
archive metadata for reproducible hashes). New ARTI-BINARY-PROVENANCE.md
records toolchain, rebuild steps, and a SHA256 manifest for every file
in the xcframework. A new CI workflow turns that policy into a gate:
PRs must keep the binary matching the manifest, and binary changes must
ship with source/lockfile/build-script evidence.
Also raises TorManager.awaitReady's default timeout from 25s to 75s to
match the bootstrap monitor deadline - a shorter wait reported "not
ready" while Arti was still legitimately bootstrapping, silently
stranding queued relay work.
Privacy policy, Tor integration doc, and privacy assessment updated to
match the current implementation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Explains no data collection, no servers, no tracking
- Documents local-only storage including identity key for favorites
- Details encryption methods and user rights
- Emphasizes privacy-first philosophy
- Written in plain language for accessibility