diff --git a/web/chat.html b/web/chat.html index 4693385..92ae52f 100644 --- a/web/chat.html +++ b/web/chat.html @@ -14,7 +14,18 @@ * { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: monospace; background: #fff; color: #000; - padding: 2rem; max-width: 820px; margin: 0 auto; + padding: 2rem; max-width: 1100px; margin: 0 auto; + } + /* two-panel layout: setup | chat, 50:50 on desktop, stacked on phone */ + .app { + display: grid; + grid-template-columns: 1fr 1fr; + gap: 1.75rem; + align-items: start; + } + .panel { min-width: 0; } + @media (max-width: 760px) { + .app { grid-template-columns: 1fr; } } h1 { font-family: 'chunkfiveregular', serif; @@ -159,22 +170,25 @@
volume modem chatroom · e2e encrypted · webrtc carrier · unturf
- +- a 440 Hz 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. -
.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.
-
- 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.
-
— or exchange manually (offline / no relay reachable) —
- -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:
- -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.
+
+ both peers type the same code; SDP is exchanged automatically via the relay + (encrypted with the code). chat content rides the audio carrier.
- -
- 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).
-
peers in room:
-log:
- -peers in room:
+- 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. -
-- 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. -
-