securebit-chat/CHANGELOG.md

# Changelog

## v5.7.2 — Documentation, and a version that keeps itself honest

No changes to the protocol or to how messages are protected.

### Fixed

- The version shown in the application header was written as a literal and had
  fallen behind, displaying v5.6.0 while running 5.7.1. It now comes from
  `package.json`, so it cannot drift again, and a test fails the build if anyone
  reintroduces a hard-coded one. The same test checks that `meta.json`, the README
  badge and the changelog agree with each other before a release goes out.

### Changed

- Documentation reorganised. Everything technical now lives in `doc/`, with an
  index at `doc/README.md`. The root keeps only what belongs there by convention:
  `README.md`, `SECURITY.md`, `CHANGELOG.md` and `LICENSE`.
- `SECURITY.md` rewritten. It described a release line three major versions old
  and made claims the software does not make. It now states what is guaranteed,
  what is not, and how to report a problem.
- `SECURITY_DISCLAIMER.md` and `RESPONSIBLE_USE.md` merged into
  `doc/USE-POLICY.md`, which says plainly what the software cannot protect
  against instead of listing generic advice.
- `doc/CRYPTOGRAPHY.md` and `doc/ARCHITECTURE.md` rewritten to describe the
  current design, including the Double Ratchet, and to quote real values taken
  from the source rather than restated approximations.
- WebRTC call tuning notes moved to `doc/CALLS.md` and rewritten. The obsolete
  `docs/` directory, which held a working document full of stale line numbers,
  has been removed.
- `doc/CONTRIBUTING.md` now records what recent bugs taught us about writing
  tests that can actually fail.

## v5.7.1 — Forward secrecy now engages for both sides of a chat

The Double Ratchet introduced in 5.7.0 was only taking effect for the peer who
joined a conversation; the peer who created the invitation stayed on the
previous per-session key scheme. Both sides now negotiate and run it, so a
conversation is protected symmetrically end to end.

If you installed 5.7.0, updating is worthwhile — it is what makes per-message
forward secrecy apply to your whole conversation rather than one direction of it.

### Internal

- The ratchet's test suites now construct the peer's public key exactly as the
  handshake delivers it (exported and re-imported, non-extractable) rather than
  reusing a locally generated one. Locally generated public keys are always
  extractable in WebCrypto, so the earlier tests exercised a key shape the app
  never actually produces.

## v5.7.0 — Double Ratchet: forward secrecy for every message

Sessions previously derived one set of keys during the handshake and used them
for the whole conversation. This release adds the Double Ratchet (Signal's
design) on top of that, so protection no longer rests on a single set of keys
lasting the entire chat.

### Added

- **A separate key for every message.** Each message key is derived from a chain
  key through a one-way function and discarded immediately after use, so keys
  that exist now cannot be used to reconstruct earlier ones.
- **A Diffie–Hellman step on every change of direction.** Each reply introduces a
  fresh ECDH key pair and mixes a new shared secret into the root key. A session
  therefore re-keys itself continuously as the conversation goes back and forth.
- **Bounded handling of out-of-order messages.** Keys for messages that have not
  arrived yet are held so they can still be read, with firm limits on how many
  are kept (512 per chain, 1024 in total, expiring after five minutes) and a
  fixed ceiling on how far ahead a message number may jump.

The ratchet required no change to the handshake. Both peers already hold each
other's authenticated ECDH public key, and the safety code compared during
verification covers exactly those keys. The ratchet's root is derived from the
existing shared secret through its own branch of the key schedule, keeping it
separate from the session's other keys.

### Compatibility

Support is advertised in the invitation and the response and used only when both
sides have it. A peer on an earlier release negotiates it away and the session
runs on the previous scheme — with no server in the design there is no way to
update both ends at once, and connecting with the earlier protection is better
than not connecting. The security panel shows which of the two is actually in
use, rather than what the client is capable of.

One behaviour worth knowing: the peer who joins has no sending chain until the
inviting peer's first message arrives — that is inherent to the ratchet, since
both sides derive it from the same exchange. The app sends a presence update from
both sides as soon as verification completes, so those first frames use the
session keys and everything afterwards is ratcheted.

### Improved

- **Connection setup on restrictive networks.** Gathering network candidates only
  finishes once every configured STUN/TURN server has replied or timed out, which
  behind a VPN or a strict firewall may not happen at all. Setup now proceeds as
  soon as there are usable candidates and only keeps waiting while there are
  none, up to a longer ceiling. A network that genuinely yields nothing now
  explains what to try instead of failing without explanation.

## v5.6.2 — Restore connectivity after the 5.6.1 key-handling change

5.6.1 changed how the shared secret is handled in memory and missed a matching
adjustment to key generation, which prevented sessions from being established.
Anyone on 5.6.1 should update.

Key agreement is unchanged on the wire, so 5.6.0 sessions remain compatible.

### Internal

- Added an end-to-end test that drives the real key generator and derivation
  rather than constructing its own keys, which is what allowed the mismatch
  through.

## v5.6.1 — Hardening pass

A review of the client produced a set of improvements to how the session is
verified, how peer input is handled and what the app stores. Updating is
recommended.

### Improved — verification and peer input

- **The safety-code comparison is now the only route to a verified session.**
  Verification state is set in exactly one place, and the checks that guard it
  cannot be reached around.
- **Control messages are honoured only after verification.** Reconnection
  signalling, call setup, message deletion and delivery receipts all wait until
  both people have compared the safety code. The verification exchange itself
  continues to work beforehand, as it must.
- **A single path for incoming chat content.** An older, weaker inbound code path
  was retired so that everything shown in a conversation has been authenticated.

### Improved — accuracy of what the app reports

- **The security panel now measures what it displays.** Several checks previously
  reported a fixed result; they now exercise the subsystem they describe and can
  report a failure. As a result the score reflects the session more precisely,
  and may read lower than before on the same connection.
- **Forward-secrecy reporting matches reality.** In 5.6.1 the panel reported the
  session-level guarantee accurately rather than implying per-message protection;
  5.7.0 adds the per-message protection itself.
- **Clearer memory-handling semantics.** Operations that cannot clear a value in
  JavaScript — immutable strings, non-extractable keys — now say so instead of
  reporting success.

### Improved — what stays on the device

- **Invitation data is no longer kept in local storage.** An unused
  reference-based QR path wrote session invitation details to local storage
  without removing them; the path has been removed and existing entries are
  cleared on first launch after updating.
- **Ephemeral messages stay ephemeral.** View-once and disappearing messages no
  longer place their text in system notifications, where the operating system
  would retain it beyond the app's control. Ordinary messages are unchanged.

### Improved — hardening

- **Shared-secret handling in memory.** The value is derived into a buffer that is
  overwritten once it is no longer needed.
- **Scanned QR codes are decompressed with a size limit,** so a malformed or
  hostile code cannot exhaust memory.
- **Voice notes are validated before being accepted automatically.** Only genuine
  audio types within a size limit skip the consent prompt; anything else goes
  through the normal confirmation, which also bounds how much a peer can send
  unattended.
- **The master-password prompt now comes from the app's own interface** rather
  than a browser dialog.
- **Clearer handling of DTLS fingerprints,** with the local and remote values kept
  separate and reported accurately.

## v5.6.0 — Survive a dropped connection

A chat no longer dies when the network moves under it. Switching Wi-Fi → LTE,
a NAT rebind, a lift, a tunnel: the session now repairs its own network path and
the messages you typed meanwhile go out when it comes back.

This is done without adding any server. An ICE restart renegotiates *only* the
transport path; the DTLS handshake, the session keys and the SCTP association
carrying the data channel all sit above ICE and survive it. So the renegotiation
SDP travels over the existing end-to-end encrypted, SAS-verified channel — there
is still no signalling service anywhere in the design, and an attacker who cannot
already decrypt the session cannot inject a reconnection.

### Added

- **Automatic session recovery.** A broken path is repaired in place with an
  in-band ICE restart, retried with a 1/2/4/8/15/30 s backoff for up to two
  minutes. Keys, SAS verification and message history are all preserved — no
  re-handshake, no comparing codes again.
- **Liveness detection that understands sleeping devices.** A data channel keeps
  reporting `readyState: 'open'` long after the path underneath it has died — the
  classic Wi-Fi → LTE switch, where nothing closes and nothing errors, packets
  just stop. Silence alone is deliberately not treated as death, because a
  browser freezes a backgrounded tab outright and a healthy peer then answers
  nothing at all. What survives that freeze is ICE consent, which the browser
  runs in its network stack rather than on the page's thread — so a connected ICE
  state means a silent peer is asleep, not gone, and the session is left alone.
  Only when ICE itself is degraded does an unanswered probe end the session.
- **Recovery is given up promptly when it cannot possibly work.** Every route out
  of a broken path runs over the data channel, so if nothing at all has reached
  us since the drop, no further attempt can succeed. Likewise an ICE agent left
  bound to a network that is gone — every candidate times out, every restart ends
  with zero candidate pairs — cannot be repaired by restarting it. Both are now
  recognised in seconds instead of being retried for two minutes.
- **A session that cannot be recovered is closed, not left half-alive.** When the
  path is gone for good, the chat is ended and its data wiped — keys, queued
  messages and transcript together. There is deliberately no manual fallback: a
  conversation whose transport is gone should not leave its plaintext sitting in
  a tab, and starting a fresh one is a single, honest step.
- **Store-and-forward while reconnecting.** Messages typed during a repair are
  queued and delivered when the path returns, in order. A send that races a
  still-settling path is re-queued rather than marked failed.
- **The conversation stays on screen** during a repair, with a "Restoring
  connection…" state, instead of dropping you back to the connect screen.
- **A device with no network holds the session open.** Five minutes underground
  no longer costs a session: the give-up deadline does not run while this device
  has no connectivity, and recovery retries the moment the radio returns or the
  tab comes back to the foreground.
- `tests/session-recovery.test.mjs` covers the state machine, the backoff, the
  offline hold and the identity check below.

### Security

- **A reconnection cannot re-point a session at a different peer.** The DTLS
  fingerprint in an incoming restart offer or answer is checked against the
  fingerprint of the live, already-verified session *before* anything is applied
  to the peer connection. A mismatch aborts recovery. If there is no live
  fingerprint to compare against, the restart is refused rather than trusted.
- Only the side that created the original offer may drive a restart; the other
  side asks. With no signalling server there is no referee to resolve glare.
- Calls cannot be placed onto a path that is mid-repair, where the media
  renegotiation would race the ICE restart on the same connection.

### Fixed

- **Every inbound heartbeat threw a `TypeError`.** `handleHeartbeat()` was
  dispatched to but never defined, so peer liveness was never actually observed.
- **Heartbeats were sent every 5 minutes, not the intended interval** — the send
  was folded into the general maintenance cycle, far too coarse to notice a dead
  path. It now runs on its own timer, and answering one no longer requires the
  peer to have finished verifying: the two sides confirm a SAS code at different
  moments, and for that whole window one of them could not reply and was being
  declared dead on a healthy connection.
- **The answering side never started its watchdog.** `ondatachannel` can hand over
  a channel that is already open, so the `open` event had been dispatched before
  the handler was assigned and never fired — leaving that side with no heartbeat,
  no liveness watchdog and no file-transfer init. The peer whose network was fine
  kept showing "connected" indefinitely because nothing was running to notice.
- **A failed send no longer fails silently.** Sending on a channel that was not
  ready simply returned: the text stayed in the box, nothing was transmitted and
  nothing said why.
- **A transient `disconnected` no longer tears down the session.** ICE reports it
  routinely and the browser usually recovers unaided; it is now given a grace
  window before a restart is spent, and it never clears verification on its own.
- A reconnected session no longer re-announces "secure connection established" —
  it is the same session resuming, and no handshake took place.
- Liveness bookkeeping can no longer throw ahead of message routing, where the
  surrounding catch would have swallowed it and silently dropped every inbound
  message.

## v5.5.4 — Fix the desktop download buttons

### Fixed

- **The download buttons still led to a dead GitHub page.** 5.5.3 updated one of the two places these links live; the platforms menu on the connection screen has its own `DOWNLOADS` table, and it was missed. It still pointed at 0.1.0.
- The stale links used `/releases/latest/download/<file>`. GitHub resolves `latest` by redirecting to the newest tag, so once 0.3.0 shipped, a link written for 0.1.0 became `/releases/download/v0.3.0/SecureBit.Chat_0.1.0_x64-setup.exe` — a file that never existed under that tag. The button navigated to GitHub and downloaded nothing, which is why it looked like a working link that simply did nothing.

### Added

- `tests/desktop-download-links.test.mjs`, which fails the build if any source drifts: it requires every file to derive its URLs from one `DESKTOP_VERSION` constant, forbids `/releases/latest/download/` and hardcoded versions in filenames, and fetches each generated URL to prove the release asset is really there. Set `SKIP_NETWORK=1` to skip the fetches offline.

## v5.5.3 — Desktop downloads point at 0.3.0

### Fixed

- **The desktop download buttons still offered 0.1.0.** Windows, macOS and Linux now link to the current 0.3.0 release, which is the first with in-app updates, voice-note parity and the verification fixes.
- The release version was repeated across three URLs in two different forms (two resolving through `/releases/latest/`, one pinned to a tag), which is how they drifted out of date. It is now a single constant, and the tag is pinned deliberately: filenames carry the version, so a `latest` link breaks as soon as a newer release exists, whereas a pinned tag keeps serving a working installer.

## v5.5.2 — Fix security level in the header

### Fixed

- **Header showed "Secure undefined%".** Moving `getRealSecurityLevel()` onto the connection manager in v5.5.1 made it reachable for the first time, so the header started calling it instead of falling through to `calculateAndReportSecurityLevel()`. It returned only per-feature booleans — no `level`, no `score` — and the header renders those two fields directly. It now runs the same verified scoring as every other consumer and merges the feature flags on top, so all callers see one consistent number. A regression test pins the shape for every branch of the header's fallback chain.

## v5.5.1 — Security audit fixes

A security review of the transport and verification layers. Every item below is a
fix to how untrusted peer input is handled; no features changed.

### Security

- **SAS verification can no longer be bypassed.** `verification_both_confirmed` is an unauthenticated frame that arrives on a channel that is not yet trusted, but it was accepted as proof that both sides had compared their codes — so a peer who completed the signalling exchange could send it right after the data channel opened and drive the other side to a "verified" session while the user never looked at the code. It is now only an *acknowledgement*: it is refused unless this side has already confirmed locally, and `_setVerifiedStatus()` independently rejects any SAS-based transition without a local confirmation. Holding ECDH-derived keys was never sufficient proof of identity — a MITM has those too.
- **Unauthenticated frames can no longer be injected into the chat.** A bare `{type:"message"}` JSON frame, a raw non-JSON text frame, and a binary frame were each decoded and rendered in the chat, bypassing decryption, the HMAC check and the verification gate — the injected text was visually indistinguishable from a genuine message. Chat content now reaches the UI only through the authenticated `enhanced_message` path; everything else is dropped and logged.
- **A peer can no longer supply the verification code.** `sas_code` announcements were adopted verbatim when no local SAS had been derived yet, which would have shown the user a number chosen by the other end. The announcement may now only corroborate the locally derived code; a missing or mismatching code aborts the session.
- **File transfers are gated on verification in both directions.** File control frames (`file_transfer_start`, `file_chunk`, …) are written straight to the data channel by the transfer system, so they never passed through the send path's verification gate on receipt. Sending was already gated; receiving now is too, so an unverified peer cannot open transfers, push chunks or drive transfer state before the SAS has been compared. User consent remains required on top of this.
- **Anti-replay is actually enforced.** The sequence-number and AAD validators were defined on the wrong class (`SecureKeyStorage` instead of the connection manager), so every call site silently failed and the sliding replay window never ran. They now live on the manager, the live chat path validates the authenticated sequence number of each message, and a missing or non-numeric sequence number fails closed instead of sailing through the range checks.
- **Stale sequence numbers are rejected** rather than logged and decrypted anyway.
- **Tighter CSP.** `connect-src` and `img-src` no longer allow arbitrary `https:` hosts (nothing in the app talks to a third party), and `base-uri 'none'` is set. This removes the exfiltration channel an injection would otherwise have.
- The SAS is no longer written to logs, and the peer-announced code is compared in constant time on every path.
- Fixed `SecureMasterKeyManager.isUnlocked()` testing a field renamed long ago, so it never actually gated anything.

### Added

- Regression tests covering the verification gate and inbound frame authentication (`tests/verification-gate.test.mjs`, `tests/inbound-frame-authentication.test.mjs`).

## v5.5.0 — Encrypted voice & video calls

SecureBit now supports **end-to-end encrypted voice and video calls** — the "5.5 Secure Voice & Calls" roadmap milestone.

### Added

- **Voice & video calls.** Start a call from the chat header (phone / camera buttons). Audio and video tracks ride the **same RTCPeerConnection as the chat**, bundled onto one **DTLS-SRTP** transport — so media is end-to-end encrypted with the very connection that in-person **SAS verification** authenticated. Call setup (SDP offer/answer) is renegotiated **in-band over the verified data channel**, never through a signalling server, so the media's DTLS fingerprints are authenticated end-to-end too. There is no server that can see or MITM a call.
- **Verification-gated.** Calls are only permitted once a session is **connected and SAS-verified**; the manager rejects call signalling otherwise. The header call buttons stay disabled until then.
- **In-call controls.** Mute / unmute, camera on/off (turning the camera on during a voice call upgrades it to video in-band), front/back camera flip, minimize-to-widget (chat stays usable) and hang up. Incoming calls show an accept / decline prompt.
- **Adaptive audio codec.** Opus tuned for real-world links — in-band FEC, DTX and RED redundancy (RED preferred first where the browser advertises it) keep speech intelligible under 15–20% packet loss. Audio is bandwidth-prioritised and is **never** throttled by the network controller.
- **Adaptive video codec.** VP9 / AV1 single-encoding **SVC** (with H.264 / VP8 fallback), so video degrades gracefully by spatial/temporal layer on a weak link. A runtime `NetworkAdaptationController` reads `getStats()` every second and trims video bitrate on loss/RTT, recovering as the link clears — no renegotiation, no track restart.
- **Live connection-quality indicator.** Excellent → Good → Fair → Weak, surfaced in the voice overlay, video top bar and minimized widget. Codec tunables and their rationale are documented in [`doc/CALLS.md`](doc/CALLS.md).

### Security

- Media inherits the session's DTLS-SRTP encryption; SDP is exchanged only over the ECDH + SAS-authenticated data channel. No new ICE or signalling server is introduced — calls reuse the existing verified transport.

## v5.4.5 — Encrypted voice messages

SecureBit now supports **end-to-end encrypted voice messages**, sent over the same secure transfer channel as files.

### Added

- **Voice messages.** Record a note in the browser and send it over the existing chunked, AES-GCM-encrypted file-transfer pipeline, so it inherits the same per-file session key and SHA-256 integrity check. Audio is captured as raw PCM and encoded to **WAV**, so it plays back on every platform — including iOS/Safari. Duration and a downsampled waveform travel as unsigned presentation metadata; the audio bytes stay integrity-protected by the signed file hash.
- Voice notes are **auto-accepted** on the receiver (no consent prompt) and played **inline** from an in-memory blob — nothing is written to disk. The bubble shows an upload/download progress ring, a seekable waveform, play/pause and duration, and the usual Encrypted/Decrypted status.
- **Composer.** A mic button records a note with a live waveform and timer plus discard / send controls. On desktop the mic and send buttons sit side by side; on mobile the mic swaps to a send button as soon as you type text.

### Changed

- Content Security Policy `media-src` now allows `blob:` so recorded and received audio can be played back.
- Version scheme moved to the 5.x line (Desktop Edition = **5.0**). The roadmap gains a **5.5 "Secure Voice & Calls"** milestone (encrypted voice messages, audio calls, video calls); later milestones shift accordingly.

## v4.9.0 — Full redesign + reworked offline mode

A ground-up visual redesign of the whole application surface — landing page, "Why unique" / partners / roadmap / community sections, connection setup, in-chat header, real-time security verification report, file transfer, and the PWA install / update / offline / install-guide dialogs.

Offline experience reworked with store-and-forward over the live P2P channel:

- Messages sent while offline are queued (single ✓) and transmitted on reconnect, preserving their original send time.
- Messages to an offline peer stay at one check until that peer returns; the offline client holds them back and surfaces them on reconnect with a notice.
- WhatsApp-style per-message delivery status (sending → sent → delivered, plus a "not sent" state) via an authenticated delivery-receipt control message.
- Browser offline state no longer leaks into the P2P connection indicator.

Resilient file transfer: per-chunk segmented progress, receiver-driven retransmission of missing chunks with auto-resume after a connection blip, corrected receive rate limits, and automatic save on completion.

## v4.8.21 — Redesigned chat surface

A full visual refresh of the connected chat experience, ported from the SecureBit Chat design. No protocol, crypto or message-handling changes — only the presentation layer of the chat screen.

### Changed

- **Message bubbles** redesigned: tighter dark surface (`#0f0f11` canvas, `#26262b` sent / `#161618` received), asymmetric corner radii, monospace timestamps, and a compact per-message status row showing **Encrypted** / **Decrypted** with a lock glyph.
- **View-once** now uses a Telegram-style blurred cover with an SVG grain overlay and a centered "View once · tap to reveal" prompt; after reveal it shows a "Viewed once" tag and still burns after the sender-chosen window.
- **Disappearing timers** render a live `mm:ss` countdown in the message meta in brand orange.
- **Composer** rebuilt: inline `Send files` / `Code` / `View once` / `Timer` chips with active states, inline time-picker rows (view-once: Off/5s/10s/30s/1m, timer: Off/5s/30s/1m/1h/24h), an auto-growing message field, an "Encrypted on your device" affordance, a live character counter, and an orange send button.
- **Handshake summary** card at the top of a verified chat (collapsible): transport / cipher / key-exchange / integrity facts plus the safety number (key fingerprint).
- Fonts are mapped to the self-hosted **Inter** + system monospace stack rather than loading Google Fonts, preserving the look without an external request from a privacy-focused client.

## v4.8.20 — Secure chat tools: completed, fixed and polished

Completes the messaging controls introduced in v4.8.14 and fixes the bug that made them appear broken for recipients. All per-message options travel inside the encrypted message envelope (never in the sanitized text), so message content cannot spoof or corrupt them.

### Fixed

- **Per-message metadata was silently dropped for recipients.** `NotificationIntegration` wrapped both `webrtcManager.onMessage` and `webrtcManager.deliverMessageToUI` with two-argument shims that called the originals without the third argument (`meta`). With notifications enabled, every received message lost its `meta`, so view-once, disappearing timers and unsend all failed on the recipient side. Both wrappers now forward all arguments (`...rest`). Added `tests/notification-meta-forwarding.test.mjs`.
- **Chat would not open after SAS** (regression from the initial wiring): the composer props were threaded into the wrong component (`EnhancedConnectionSetup` instead of `EnhancedChatInterface`), throwing `ReferenceError: nowTick` on the verified-state re-render. Props are now on the chat component.

### Changed

- **Code blocks** now include lightweight, dependency-free syntax highlighting (comments, strings, numbers, keywords) rendered via React nodes — no `innerHTML`, no remote scripts. Enabling code mode expands the input (monospace, 8 rows) for comfortable entry. Copying a block auto-clears the clipboard after ~30s.
- **View-once** is now configurable: the sender picks how long the message stays visible after the peer opens it (5s / 15s / 30s / 1m) via `meta.onceTtl` (clamped 1s–1h).
- **Disappearing timer** uses a duration picker (Off / 30s / 5m / 1h) instead of click-cycling.
- **Composer toolbar** moved next to the "Send files" control; borderless buttons with the brand-orange (`accent-orange`) active state; time pickers open upward and are sized for mobile readability.
- Sender bubble background lightened to `rgba(249, 115, 22, 0.05)`.

### Removed

- **Panic wipe** button. Disconnecting already wipes keys and clears session state, so a separate panic control was redundant.

## v4.8.15 — Fix: chat would not open after SAS in v4.8.14

### Fixed

- The secure chat failed to open after both peers confirmed the SAS code: the message list and composer (in `EnhancedChatInterface`) referenced `nowTick`, `onUnsendMessage` and the new composer props, but those were threaded into the sibling `EnhancedConnectionSetup` component by mistake. At runtime this threw `ReferenceError: Can't find variable: nowTick` during the verified-state re-render, so the chat never rendered. The new props are now destructured and passed on `EnhancedChatInterface`, where the chat UI actually lives. No behavioural change to the v4.8.14 features otherwise.

## v4.8.14 — Secure chat tools: code blocks, view-once, disappearing, unsend, panic

Adds privacy-focused messaging controls. Per-message metadata (id, view-once, timer) travels **inside the encrypted message envelope**, never in the sanitized text, so message content cannot spoof or corrupt these controls. The unsend/delete signal travels over the authenticated DTLS control channel like other system messages.

### Added

- **Code blocks.** A composer button wraps the message in a fenced block; both peers render it as a monospace code window with a copy button. The marker travels as ordinary text, and the window is built from already-sanitized text via React nodes only (no `dangerouslySetInnerHTML`), so there is no new XSS surface.
- **Clipboard auto-clear.** Copying a code block clears the clipboard after ~30s — only when it can confirm the clipboard still holds the copied value, or cannot read it back, so a later copy is never clobbered.
- **View-once messages.** The recipient sees a blurred bubble that reveals on tap and is then wiped. Honestly cooperative (a malicious client or a screenshot can still capture it) — this is hygiene, not a guarantee.
- **Disappearing messages.** An optional sticky timer (30s / 5m / 1h) auto-deletes a message on both sides, with a live countdown. The incoming timer value is clamped to [5s, 24h].
- **Unsend (delete for everyone).** Removes your message locally and asks the peer to drop it via a `message_delete` control message (`MESSAGE_TYPES.MESSAGE_DELETE`).
- **Panic wipe.** One button clears the conversation, wipes keys (`_secureWipeKeys`) and tears down the session, behind a confirm prompt.

### Security

- New per-message metadata is whitelisted and bounded by `_sanitizeMessageMeta` on both send and receive; unknown fields, wrong types and out-of-range timers are dropped.
- AAD/replay protection, the SAS verification gate and receive-side DOMPurify sanitization are unchanged.

### Tests

- Added `tests/secure-chat-features.test.mjs` covering metadata sanitization, meta delivery to the UI, and the unsend control path. Full suite: 17 files, all passing.

## v4.8.13 — Message integrity & transport hardening

Security review follow-up. The end-to-end cryptography (ECDH, AES-GCM, PBKDF2, SAS bound to DTLS fingerprints, anti-replay) was verified sound; these changes fix availability/integrity defects on the send path and tighten transport headers and logging.

### Fixed

- Outgoing messages were silently rejected by an over-broad keyword blocklist in `_validateInputData`. Plain words such as "constructor", "global", "document.", "prototype", or the literal text "javascript:" caused `sendSecureMessage` to throw, so legitimate messages never reached the peer. The blocklist provided no real protection: XSS is enforced at the rendering boundary by the receive-side DOMPurify pass and by `sanitizeMessage()` before encryption. The send-path blocklist was removed.
- `_sanitizeInputString` collapsed all whitespace (`/\s+/g` to a single space), destroying multi-line messages and code snippets (`"a\nb\nc"` became `"a b c"`). Newlines, tabs and indentation are now preserved; only control characters are stripped and runs of 3+ blank lines are collapsed to two.
- AAD validation failures logged the raw AAD string, which carried `sessionId` and `keyFingerprint`. Both the message and file-message validators now log only the AAD length.

### Security

- Added `Strict-Transport-Security` (`max-age=63072000; includeSubDomains; preload`) to `deploy/nginx.conf` and `.htaccess`, closing the first-visit SSL-strip window that `upgrade-insecure-requests` alone does not cover.
- Added a restrictive `Permissions-Policy` (`camera=(self)` for in-page QR scanning; microphone, geolocation, payment, usb and sensors denied).

### Tests

- Added `tests/outgoing-message-integrity.test.mjs` covering keyword acceptance, multi-line/indentation preservation, control-character stripping, blank-line collapsing, and the size limit.

## v4.8.12 — Chat notification & file-transfer UI fixes

Fixes duplicated chat output and a layout overflow in the message list.

### Fixed

- A received file was announced many times in the chat instead of once. The per-transfer lock used a single `if` check, so when 3+ chunk operations queued on the same file they ran concurrently and broke assembly atomicity. The lock now serializes correctly, and file assembly is idempotent, so `File received` is shown exactly once per file.
- System messages were duplicated during connection setup (e.g. "Both parties confirmed!" and "Secure connection successfully established"). `handleVerificationBothConfirmed` now bails out if both confirmations were already recorded, so the message and the verified transition fire only once.
- The DTLS fingerprint (a long unbroken string) overflowed the chat bubble. The message text container now uses `min-w-0` so the fingerprint wraps within the bubble.
- Site header, init banner, and manifest now report the current version.

## v4.8.11 — File transfer reliability fix

Fixes file transfers that silently failed to reach the peer, and relaxes the overly strict file-type check that rejected legitimate files.

### Fixed

- File chunks are now sized so the on-the-wire message stays under the 64 KB SCTP message-size limit enforced by WebRTC. Previously each 64 KB chunk became a ~87 KB encrypted+Base64 message that exceeded this limit, so the consent handshake succeeded but no data was ever delivered — most visibly on Safari and cross-browser connections whose SDP omits `a=max-message-size`. The send chunk size is now 16 KB (~22 KB on the wire); inbound chunks up to 64 KB are still accepted for backward compatibility.

### Changed

- File-type validation is now driven by the extension allow-list, with the (client-supplied, easily spoofed) MIME type treated as an advisory signal. Files with a missing MIME type or a cross-OS MIME variant (e.g. `application/x-zip-compressed` for `.zip`, `image/jpg` for `.jpg`) are no longer rejected. Blocked executable/script extensions, a blatantly foreign MIME on a safe extension, and per-type size limits are still enforced.

## v4.8.10 — User-configurable STUN/TURN servers

Adds optional, advanced control over WebRTC connectivity for power and privacy-focused users. Public servers remain the zero-config default.

### Added

- "Advanced network settings" panel (header gear icon and the connection-creation screen) where users can supply their own STUN/TURN servers instead of the bundled public defaults.
- Allowlist-based validation of user input: only `stun:`/`stuns:`/`turn:`/`turns:` URLs with valid hosts are accepted; `javascript:`, `data:`, `http(s):`, `ws(s):`, control characters, and oversized input are rejected before anything reaches `RTCPeerConnection`.
- Optional on-device persistence, encrypted at rest with a non-extractable AES-GCM device key in IndexedDB, with an explicit save prompt and a "Forget saved" action.
- "Test servers" button that gathers ICE candidates against the entered configuration and reports STUN/TURN reachability.
- Privacy guidance in the panel: a TURN relay sees peer IPs and traffic timing (never message contents), so only a trusted/self-hosted relay improves privacy.

### Changed

- Relay-only privacy mode now lives in the advanced settings panel. The standalone relay-only toggle on the start screen was removed to declutter the initial view.
- Server selection priority: user custom servers > operator override (`config/ice-servers.js`) > built-in public defaults.

## v4.8.9 — Security hardening patch

This release closes a vulnerable dependency, removes committed TURN credentials, and tightens production logging.

### Security

- Upgraded DOMPurify from 3.4.4 to a patched release, resolving a high-severity XSS advisory (GHSA-87xg-pxx2-7hvx) in the incoming-message sanitizer.
- Upgraded the `esbuild` build dependency to clear a high-severity advisory in the toolchain. `npm audit` now reports zero vulnerabilities.
- Stopped tracking `config/ice-servers.js` (operator TURN credentials) in Git and added `config/ice-servers.example.js` as a template. Operators must rotate any previously committed credentials.
- Removed temporary debug branches from the production logger so it no longer prints error context or info/debug payloads — only an opaque error code.

### Documentation

- Updated the supported-release table in `SECURITY.md` to the v4.8.x line.
- Synchronized the version string across the header, manifest, README, and in-app initialization message.

## v4.8.8 — File transfer consent fix

This patch completes the mandatory receiver-consent gate for incoming file transfers and resolves a callback ownership conflict that caused every incoming file request to be silently auto-rejected.

### Fixed

- Wired up the missing fourth `onIncomingFileRequest` callback in the main `setFileTransferCallbacks` call. Without it, `handleFileTransferStart` always saw `null` for the consent handler and auto-rejected every incoming file silently.
- Removed independent callback registration from `FileTransferComponent`. The component was overwriting the application-level callbacks on mount and nulling all four on unmount, which destroyed the progress, received, and error handlers whenever the panel was hidden.
- Centralized incoming-consent state (`pendingIncomingFiles`) in the root application component so consent prompts appear regardless of whether the file-transfer panel is currently visible.
- Auto-opens the file-transfer panel when an incoming request arrives so the user sees the Accept / Reject prompt immediately.
- Added `getReceivedFileObjectURL` / `revokeReceivedFileObjectURL` helpers to `EnhancedSecureWebRTCManager` so the panel can offer a download button for completed transfers without relying on captured callback closures.
- Updated `file-transfer-ui-cleanup` regression test to match the new single-owner callback architecture.

### Security

No change to the cryptographic or transport-level security model. Sender chunks are still gated behind an explicit `file_transfer_response` from the receiver before any data is transmitted.

### Verification

- `npm test` — all 14 tests pass.
- `npm run build` — clean production build.

## v4.8.7 — WebRTC manual join reliability patch

This patch improves manual WebRTC setup across separate devices and restrictive local networks.

### Fixed

- Stabilized the manual offer/answer join flow so verification waits for real transport readiness.
- Preserved generated response data during manual exchange instead of resetting the joiner screen prematurely.
- Preserved pending creator-side offer context so responses can be applied after transient ICE failures without false session-salt hijacking errors.
- Added operator ICE override support through `config/ice-servers.js`.
- Added ExpressTURN TURN/STUN configuration for relay fallback in environments where mDNS host candidates cannot connect.
- Added user-visible warning when a remote peer provides only mDNS host candidates and no `srflx` or `relay` route.
- Added safer ICE diagnostics that report candidate classes without exposing full IP addresses or TURN credentials.

### Verification

- `npm test`
- `npm run build`

## v4.8.7 — Security hardening patch release

This patch release strengthens SecureBit.chat across verification, sanitization, privacy, transport abuse resistance, cache safety, and repository hygiene.

### Security hardening

- Bound SAS verification to the actual DTLS fingerprint strings of both peers.
- Replaced regex-based chat sanitization with DOMPurify-backed sanitization.
- Made WebRTC privacy mode explicit and kept relay-only state synchronized at runtime.
- Removed production exposure of internal debug/control hooks.
- Added receiver-side rate limiting for inbound chat messages.
- Added receiver-side throttling for inbound file chunks.

### Runtime and privacy safety

- Hardened service-worker caching so only explicitly allowlisted safe assets are cached.
- Removed an untracked disconnect timer so teardown no longer leaves delayed callbacks behind.
- Preserved relay-only TURN behavior while making privacy implications clearer when relay-only mode is disabled or TURN is unavailable.

### Repository hygiene

- Stopped tracking `node_modules` in Git so platform-specific dependency binaries no longer pollute the repository or break cross-platform builds.

### Validation

- Full regression suite passes.
- Clean install succeeds with `npm ci`.
- Production build succeeds with `npm run build`.

## v4.8.7 — Security hardening release

This release consolidates several months of security, privacy, and lifecycle hardening work by the SecureBit.chat team.

### Security

- Added mandatory interactive SAS verification; passive click-through confirmation is no longer sufficient.
- Made SAS computation deterministic across peers using shared session material.
- Enforced protocol version `4.1` mismatch handling for incompatible clients.
- Added TURN relay-only privacy mode and explicit warnings when TURN is unavailable.
- Encrypted sensitive IndexedDB metadata and added safe lazy migration for legacy plaintext records.
- Added mandatory consent gating for every incoming file transfer.
- Replaced broad file acceptance with an explicit file-type allowlist and spoofing checks.
- Sanitized every incoming decrypted chat message before UI delivery.

### Reliability and resource lifecycle

- Consolidated disconnect behavior into one canonical cleanup path.
- Added cleanup for tracked timers, deferred retries, peer-disconnect scheduling, and fake/decoy traffic.
- Rejected pending sender consent promises immediately during cleanup.
- Bounded retained received-file buffers and added graceful handling for expired download handles.
- Cleared React file-transfer UI state and detached live callbacks on unmount.
- Improved reconnect hygiene and stale-session cleanup behavior.

### Maintenance

- Pinned dependency versions.
- Applied safe transitive patch/minor updates.
- Verified a clean `npm audit` result.
- Expanded regression coverage for SAS, file consent, sanitization, privacy mode, metadata encryption, cleanup, and callback lifecycle behavior.