zebra report

volume modem chatroom  ·  e2e encrypted  ·  webrtc carrier  ·  unturf

identity

passphrase mode = group; pubkey mode = 1-to-1 ECDH.

room (passphrase mode)

no room key

PBKDF2-SHA256 (600k iter) of passphrase + literal salt "zebra-report-v1" → 256-bit AES-GCM group key.

room (pubkey mode)

your public key (click to copy):

generating…

carrier

tx gain:
0%
rx energy:
—

a 440/441 Hz stereo carrier is generated locally. each frame swings the output gain MARK (0.80) ↔ SPACE (0.20) per bit. the modulated audio is the outbound WebRTC track for every connected peer. mic stays off.

peer connection (WebRTC)

disconnected — start audio first, then pick a role below
stuck on the same LAN? host candidates as .local?

modern browsers anonymize host IPs as .local mDNS names for privacy. if a router blocks multicast (common on guest Wi-Fi, sometimes consumer defaults), peers cannot resolve each other's .local addresses & host candidates fail. workaround: turn off the obfuscation.

Firefox: about:config → set media.peerconnection.ice.obfuscate_host_addresses to false.
Chromium: chrome://flags/#enable-webrtc-hide-local-ips-with-mdns → set to Disabled.
reload the page after toggling, then retry.

auto-connect · signaling relay (no copy-paste)

both peers type the same rendezvous code and click connect. SDP is exchanged automatically through proxy.uncloseai.com — encrypted with the code first, so the relay only ever sees ciphertext. this is just the connection bootstrap; pick a room passphrase above for the chat content itself.

not connected to relay

— or exchange manually (offline / no relay reachable) —

role A · start a new connection

step 1: click, then share the link with your peer (Signal, SMS, anywhere). They open it on their device.

step 4: paste the answer link (or raw SDP) your peer sends back:

role B · join an existing connection

step 2: paste the offer link (or raw SDP) you received:

step 3: share this answer link back to your peer.

each browser modulates its own outbound audio track (no mic). incoming peer audio is decoded in-page via AudioWorklet, no native daemon required. Wireshark sees only encrypted SRTP — chat content lives in audio amplitude transitions inside that stream.

handshake

not yet measured
idle
negotiated baud: —

OFFER and READY frames travel at fixed ZEBRA_BAUD_HANDSHAKE = 50. each peer measures its own scheduling jitter, broadcasts a max baud, room settles on min(all).

chat

peers in room:

none yet

log:

about

The protocol's data path is audio amplitude inside an encrypted WebRTC SRTP stream. The signaling channel (SDP / ICE) is exchanged once at connection setup — it contains no chat content. Every subsequent bit travels as a MARK/SPACE swing in the carrier audio.

threat model · what this protects against · what it doesn't

Protects against: a network-level observer (Wireshark, IDS, DPI) reading chat content. The bits are inside the SRTP audio payload, which is end-to-end encrypted by WebRTC, then additionally encrypted at the app layer (AES-GCM via passphrase or ECDH).

Does not protect against: (1) other same-UID processes that can poll PulseAudio or record the monitor source on either peer's machine — that is the attack surface this whole project documents; (2) an endpoint compromise of either peer's machine; (3) traffic-analysis correlation against the encrypted SRTP flow.

Mitigation for defenders: require a capability for same-UID PulseAudio reads. The current Linux audio IPC trust model grants every same-UID process unrestricted access — the defect whitepaper documents this.