mirror of
https://github.com/permissionlesstech/bitchat.git
synced 2026-11-08 08:01:49 +00:00
e89fcbd7c4
* Document why rotating the service UUID does not work PEER-ID-ROTATION.md §2 lists "hiding that bitchat is in use" as a non-goal and says the service UUID is "tracked separately." Nothing tracked it, so the idea keeps coming back without its constraints. This is that document. The conclusion is negative and worth writing down: hiding that bitchat is running is not achievable for an open-source app that supports discovery between strangers. Two independent reasons, either sufficient. iOS requires background scanners to name the exact UUIDs they want, so any value a stranger can pre-compute to find us, an adversary running the same source derives identically — stranger discovery (G4) and invisibility to a code-reading adversary are mutually exclusive in one advertisement. And mechanically, third-party iOS apps cannot control advertisement contents at all, cannot change advertised services while backgrounded, and have their UUID collapsed into a 128-bit overflow bitmask in the background anyway — so the real exposure is foreground, where iOS permits rotation least. Also recorded: every comparable deployment (Exposure Notification, Find My, Fast Pair, Eddystone-EID) and every comparable mesh app (Bridgefy, Berty, qaul, Meshtastic) fixes the identifier and rotates the payload, if anything; Briar is the only structurally different answer and it gets there by not broadcasting. What survives any UUID change, ranked by how cheaply it can be used — GATT connect-and-probe is decisive at ~3.7s/device on a Raspberry Pi, and is invariant under rotation because app detection is a lookup, not a discrimination problem. Three ways rotation would make things actively worse (shrunken anonymity set, the restoration stale-identifier trap, anti-tracking standardisation surfacing us as an "unknown tracker"). And what is actually available instead, with peer-ID rotation ranked first because it targets the far larger exposure: identifying a specific person, not merely a bitchat user. Two load-bearing claims are undocumented by Apple and flagged for device verification rather than asserted (§6). RF-fingerprinting is deliberately described as a targeted tool rather than a dragnet; an earlier draft overstated it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Correct the foreground-rotation reading; drop the DULT claim Section 2.2 closed by saying rotation's value would sit where iOS permits it least, which reverses the section's own argument. The only mechanical constraint it cites on changing the UUID applies while backgrounded; the foreground is precisely where CoreBluetooth allows stopping advertising, swapping the service and starting again, a cycle BLEService+LinkLayerPeripheralRole already runs. Retitled from "forecloses" to "constrains", rewrote the closing passage, and softened the "two independent reasons" framing, since independence was the point of the objection. The conclusion is unchanged: foreground rotation defeats a stale-list scanner but not an adversary running the public derivation, and connect-and-probe identifies us regardless. Section 5's third downside claimed anti-tracking standardisation might flag us as an unknown tracker. DULT scopes to small location-tracking accessories identified by a specific service-data UUID, and platform alerts cover conformant tags rather than arbitrary advertisers; the spec also mandates address rotation for those accessories, which makes rotation a requirement of it rather than a trigger for it. Dropped, and the section is now two ways. Nothing else referenced it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>