extant2000/flamenet-messenger-android

Files

T

Paul HittandClaude Fable 5.1 4dd544083c Remove machine-writing tells from comments and docs

Emoji markers, markdown bold inside code comments, and em-dashes are
gone from source comments, string literals, scripts, Gradle files and
the markdown docs. Counted before and after:

  emoji markers   2680 -> 1 (the emoji picker's own list, which is the feature)
  em-dashes       2490 -> 9 (table placeholders and fenced code)

Two warning glyphs in user-facing strings in ChatScreens.kt are removed
as well; the sentences say the same thing without them. Two backtick
test names carried an em-dash and now carry a comma.

Nothing else changed. 1208 tests pass, counted from the result XML.
The three obfs4 interop tests are opted out with OBFS4_INTEROP_OPTOUT=1
for this run, as their own message instructs when no bridge is set up.

CONTRIBUTING gets a four-line rule so it does not grow back.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

2026-09-08 18:52:12 -04:00

2.1 KiB

Raw Blame History

Security

Reporting a vulnerability

Email security@flamenetmessenger.com. Please do not open a public issue for anything affecting confidentiality or authentication. We acknowledge within 72 hours.

Status

Not independently audited. This Android app has been reviewed in-house and is covered by the JVM unit suites plus on-device instrumentation, alongside the shared 253-check relay conformance suite and cross-platform interop tests that run the real engine on both sides.

An internal adversarial audit on 2026-08-29 found and fixed a family of sender-attribution flaws: the ratchet authenticates a device, and the user id inside a sealed envelope is a claim its author chooses, the two were not bound. Devices now bind to their user on first proven use, control traffic (delivery keys, avatars) is refused from an unproven sender, and the key-transparency log head is verified against a pinned issuer key. Finding that class of bug in-house is a reason to expect more from outside review, not fewer.

What the app protects, and what it cannot

Private keys are generated on the device and live in the Android Keystore, which never hands out key material. Message history is sealed at rest. The app defends against a malicious or compromised relay reading messages, and against a passive adversary recording traffic to decrypt after a quantum computer exists (when both ends publish a post-quantum identity, the safety number says which guarantee it covers).

It does not defend against:

A compromised device. Malware with your unlock reads plaintext. The app lock is a speed bump against someone holding your unlocked phone, not encryption.
Metadata. The relay sees who is addressed and when. Sealed sender removes the sender from the stored row, not from the network connection.
Your correspondent. Anything you send can be screenshotted, kept, or repeated by the person you sent it to.

Verifying what you run

Every byte of the shipped APK's contents reproduces from this source; only the randomized signing block differs. See docs/REPRODUCIBLE.md in the relay repo and scripts/verify-build.py in the Android repo.