Honest threat model.

1. Scope and framing

OxPulse Chat is a browser-native WebRTC messenger. The cryptographic core is DTLS-SRTP for the transport layer plus SFrame AES_128_GCM_SHA256 (RFC 9605 suite 0x0004) for end-to-end protection of media and in-call chat. The SFrame ratchet key is established peer-to-peer over a pre-negotiated DataChannel and is independent of DTLS — compromise of the DTLS-SRTP transport key does not yield SFrame plaintext. Both 1:1 and group calls use the same ratchet; the epoch advances on every membership change. Wire payloads are CBOR+zstd, sealed inside AEAD before they touch any relay. The anti-censorship transport is TURN-on-:443, VLESS/Reality with ML-KEM-768 post-quantum key exchange, and 5-way SNI rotation.

Browser caveat — transit_only fallback. SFrame requires Insertable Streams (RTCRtpScriptTransform or createEncodedStreams). Browsers without either API fall back to transit_only mode: the call still completes, but only DTLS-SRTP protects it on the wire — the SFrame end-to-end layer is absent. The UI surfaces a yellow E2E badge in this mode. Treat transit_only as transport-confidential but operator-trusted, not E2EE.

The edge nodes — partner-edge TURN/SFU relays — are operated by third parties running the open-source oxpulse-partner-edge bundle (AGPL-3.0). Every payload that arrives at a relay is already SRTP-encrypted. Relay operators cannot read content and cannot modify it without the modification being detected by DTLS+AEAD.

Network model. This is a federated mesh, not a decentralized one. A control plane exists at api.oxpulse.chat. Partner nodes register using a ptkn_<token> issued by OxPulse; the orchestrator daemon on the motherly host auto-provisions AmneziaWG peers, opens iptables rules, and upserts Prometheus scrape targets. Operators are identifiable to the control plane by registration token and WireGuard public key. The cryptographic boundary — operators forwarding only ciphertext — is the load-bearing privacy claim; the network topology is federated, not anonymous. This distinction matters: the control plane is an additional threat surface that §2 Tier 2 and §2 Tier 3 models do not fully cover. See §5a "What about the control plane?" below.

2. Adversaries we model

We consider three tiers in increasing capability.

Tier 1: passive network observer

Profile. An ISP, IXP, or national backbone carrier that can see packet headers, TCP/TLS metadata, and timing. Can perform DPI on unencrypted or weakly-obfuscated traffic. Can block ports, throttle protocol signatures, or poison DNS. Cannot break standard TLS 1.3 or actively intercept without detection.

Examples. Rostelecom/ТСПУ (Russia), Arvan Cloud (Iran), China Unicom peering. Also: a VPN provider logging connection metadata, a coffee-shop network operator running shallow DPI.

Capabilities. Port blocking (UDP blocked at national boundary, port 80/443 selectively throttled), JA3/JA4 TLS fingerprinting, traffic-volume correlation, DNS hijacking.

Not capable of. Breaking TLS 1.3 session keys, decrypting DTLS-SRTP payload, injecting packets without detection (passive only), cracking ML-KEM-768.

Tier 2: nation-state active adversary

Profile. A well-resourced state actor with both passive monitoring capability and the ability to act on it — IP blacklisting, DNS poisoning, active TCP reset injection, AiTM proxies for known TLS hosts, deployment of bespoke DPI research. Operates at national-scale infrastructure level. May selectively target individuals identified through metadata correlation.

Examples. РФ ТСПУ enforcement apparatus, Great Firewall of China, Iranian FATA/ISP control regime.

Capabilities. Everything in Tier 1, plus: active TCP RST injection, IP null-routing, selective HTTPS MITM for registered domain targets (using state-issued CAs in the browser trust store), JA3/JA4 clustering to detect novel protocols within days of deployment, DNS-over-HTTPS blocking, running their own TURN servers to observe relay traffic patterns.

Not capable of. Breaking TLS 1.3 or DTLS with properly-negotiated session keys (no known attack at time of writing), forging DTLS handshakes without access to private keys, decrypting SFrame content without the ratchet key material.

Tier 3: compromised partner-edge operator

Profile. A partner running an oxpulse-partner-edge node who is malicious, coerced, or has been compelled by local law enforcement to log or intercept traffic. Has full access to their relay infrastructure. May hand over logs, attempt traffic correlation between ingress and egress connections, or deny service to users routing through their node.

Examples. A relay operator in a jurisdiction that compels assistance to law enforcement. An operator who turns hostile after registration. An operator whose server is silently compromised by a third party.

Capabilities. Full access to SRTP-encrypted traffic flowing through their relay. Connection timing and volume metadata for sessions touching their node. Ability to disconnect users or selectively degrade service. Ability to hand connection logs (IP pairs, timestamps, byte counts, room IDs) to a requesting authority.

Not capable of. Reading message content or hearing call audio (SFrame AEAD prevents this). Forging messages to participants (AEAD authentication). Injecting content into a room (participants will see authentication failures). Exposing forward-secret key material from past sessions (ratchet advance destroys previous epoch keys).

3. What we defend

3.1 Content confidentiality

Every message and every media frame is encrypted end-to-end before leaving the sender's browser. The chain (full SFrame path, used on any browser with Insertable Streams support):

1. Application message serialized to CBOR.
2. CBOR payload sealed with the SFrame AEAD — AES_128_GCM_SHA256 (RFC 9605 suite 0x0004) — using a ratchet-derived key. The SFrame header (epoch + sender index + counter) is bound as AEAD additional data. The signaling server, the SFU, and every partner-edge relay see only the sealed ciphertext.
3. The sealed AEAD payload is the WebRTC DataChannel or SRTP frame payload — the DTLS-SRTP layer wraps it again for transport confidentiality and packet authentication.

Two layers, two keys, two trust domains. DTLS-SRTP is negotiated per peer pair via the WebRTC stack; the SFrame ratchet key is established independently over a pre-negotiated key-exchange DataChannel (chat-keyex, id 1), authenticated by a session commit derived from the join secret and the host's public key. The SFrame layer remains confidential even if the DTLS-SRTP transport key is later disclosed.

SFU path (group calls). The SFU (oxpulse-sfu-kit, built on str0m) is deliberately key-agnostic. It terminates DTLS-SRTP per peer in order to unwrap RTP headers for routing, but never participates in the SFrame key exchange and therefore never holds an SFrame key. The SFU forwards SFrame ciphertext payloads opaquely between peers. A partner-edge operator running Wireshark on their own relay confirms the same: the forwarded payloads are opaque.

Library. Custom SFrame + ratchet implementation (sframe-ratchet, Apache 2.0). Per-peer FrameCryptor web workers; each call uses a fresh ephemeral SFrame identity independent of the device's long-term Ed25519 identity key.

Against whom this holds. All three adversary tiers. Even a coerced operator cannot produce plaintext from a lawful request. What they can hand over is connection metadata (see §3.5).

Browser fallback. Browsers that expose neither RTCRtpScriptTransform nor createEncodedStreams (older Safari, restricted embedded WebViews) drop into transit_only mode: DTLS-SRTP still encrypts the wire, but the SFrame end-to-end layer is absent. The UI shows a yellow E2E badge. In this mode a malicious SFU or relay operator could read media; treat the session as transport-confidential, not E2EE. Modern Chrome, Firefox, and Safari 17+ all run the full SFrame path.

Known limitation. If an endpoint (user's browser or device) is already compromised before the session — malware with DOM access, a hostile extension — content is readable there. This is out of scope; see §4.2.

3.2 Forward secrecy

The ratchet advances on every epoch rotation (member join, leave, or explicit re-key). Key material from epoch N is destroyed once epoch N+1 is established. A party who records encrypted traffic and later obtains a session key for epoch N cannot decrypt traffic from epoch N+1 or any prior epoch using only that key.

Against whom this holds. An operator who retroactively receives a subpoena for recorded traffic gets ciphertext they cannot decrypt with the current key. A state actor who later compels a user device gets keys for post-compromise sessions only.

Known limitation. "Retroactive" here means across epoch boundaries. Within a single epoch, all traffic sealed under that epoch's key is decryptable if that key is compromised. We do not implement per-message forward secrecy (Signal's Double Ratchet does this at the message level; our ratchet operates at epoch granularity). This is noted in open work (§7).

3.3 Transport under DPI (Tier 1 and Tier 2)

The anti-censorship transport stack:

• TURN-on-:443 (TCP). All WebRTC traffic tunnels through TURN relay over TCP port 443. From a passive observer, this looks like HTTPS traffic to a known TURN server. Port-blocking regimes that block UDP 3478 or STUN cannot see through this without fingerprinting the TLS handshake.
• VLESS/Reality + ML-KEM-768. When TURN:443 alone is insufficient, the TURN connection is further wrapped in a VLESS tunnel using the xray Reality protocol. This uses a borrowed TLS handshake from a legitimate TLS 1.3 destination (one of five SNI rotation targets) so that the JA3/JA4 signature matches a real non-suspicious connection. ML-KEM-768 provides post-quantum key exchange for the tunnel, meaning future quantum-capable adversaries who record today's traffic cannot decrypt it later.
• 5-way SNI rotation. The five SNI targets are rotated to diversify TLS fingerprint clustering. A passive observer who sees a burst of connections to one SNI cannot immediately fingerprint the pattern.

This stack has operated on Russian mobile networks under ТСПУ enforcement since 2025 and on Iranian 3G networks during periods of active throttling. Tested with tc-netem at 1 KB/s sustained throughput.

Against whom this holds. Tier 1 (passive ISP) and known-configuration Tier 2 (ТСПУ, GFW baseline policy, Iranian port-blocking). Connections continue at reduced quality even when video is suspended.

Against whom this does not hold. A Tier 2 adversary deploying bespoke traffic analysis against VLESS/Reality specifically: e.g., timing-based detection of the borrowed TLS handshake pattern, or fingerprinting of Reality's specific xtls-rprx-vision frame structure. This is an active research area and current Reality obfuscation provides meaningful but not absolute resistance. See §7.

3.4 Operator-untrusted relay design

The protocol is designed so that relay operators never need to be trusted with content. The oxpulse-partner-edge code is AGPL-3.0 published. An operator can verify:

• The SFU forwarder (str0m-based) forwards SRTP frames without inspecting payload.
• The coturn TURN relay handles ICE and allocation without logging media content.
• Beyond the explicit registration heartbeat to our control plane, no data is reported back to us.
• The xray/Caddy tunnel carries opaque DTLS, not plaintext.

This means the operator's trust relationship with users is limited to: connection metadata (IP pairs, room IDs, timestamps, session duration, byte counts). That is documented explicitly to users and to operators (see §5.2 for the subpoena scenario).

Coercion. If an operator is coerced, they can hand over connection logs. They cannot hand over message content. They can deny service to their users. They cannot silently redirect or eavesdrop on content — any attempt to modify SRTP frames breaks AEAD authentication and is visible to participants as an error.

3.5 Metadata and what we do not defend

We defend content. We do not fully defend metadata.

A partner-edge operator has:

• Connection pairs: which IP connected to their relay, when, for how long.
• Room IDs (not decryptable, but correlatable if the same room ID appears on multiple relays or on the signaling server).
• Byte-count and timing information sufficient for traffic-volume correlation.

Our signaling server (operated by us) has:

• The same room ID and timing metadata.
• ICE candidates (IP addresses of participants, potentially including real IPs before TURN allocation).
• No message content, no media, no key material.

This is the honest metadata surface. It is broader than Signal's sealed-sender design (see §7 for where sealed-sender-equivalent is in the backlog).

4. What we do not defend

This section is deliberately blunt. Threat models that bury their limits in footnotes are dishonest.

4.1 Anonymity and traffic-analysis correlation

We do not provide anonymity. We are not a mixnet. We do not implement cover traffic or padding at the network level.

A global passive adversary who observes both the user's connection to a TURN relay and the relay's forwarded traffic to other participants can, in principle, correlate ingress and egress by timing and volume. This is the same attack class used against Tor hidden services and against low-latency anonymity networks generally. At 1 KB/s with variable message timing, the correlation signal is weaker than at broadband speeds — but it exists and we do not claim to defeat it.

If your threat model requires strong anonymity — if you are a source who needs the recipient to not know your IP, or a dissident whose network position must be hidden from a global adversary — use Tor or a mixnet on top of OxPulse. We are a content-encryption and DPI-evasion tool, not an anonymity tool.

The distinction is: a passive ISP-level observer cannot read your messages and cannot tell what application you are running (VLESS/Reality obfuscates the protocol). A global adversary correlating both ends of a relay connection can establish that you are communicating with the same call session as another IP. We defend the first; we do not defend the second.

4.2 Endpoint compromise

If malware has DOM-level access to the user's browser at the time of a call, the attacker can read messages and hear audio before encryption. This is out of scope for the same reason it is out of scope for Signal, iMessage, and every other end-to-end encrypted messenger — encryption cannot protect data from code running in the same process.

This includes: malicious browser extensions with content-script access to the tab, OS-level keyloggers, screen-capture malware, compromised browser binary. Defense against these threats requires endpoint security and is outside our architecture.

4.3 Bespoke DPI fingerprinting research

VLESS/Reality provides strong resistance against generic DPI and known fingerprinting signatures. It does not provide guaranteed resistance against a state actor conducting dedicated research into Reality's specific traffic patterns.

The SNI-borrowing technique in Reality relies on the borrowed connection's TLS 1.3 parameters being indistinguishable from the real server. A sufficiently motivated adversary with extended traffic samples may identify behavioral differences (response timing, packet size distributions, server-side fingerprint of the real destination). This is an open research problem, not a solved one. We monitor Reality deployment status and plan additional obfuscation layers (see §7).

4.4 Rubber-hose and legal coercion of participants

If a call participant is compelled to produce key material — through legal process, physical coercion, or device seizure — forward secrecy limits exposure to the current and future epochs from that participant's device. Past epochs are not recoverable. But the participant's current session state can be extracted under sufficient coercion. This is the same limitation as every E2EE system, including Signal.

4.5 Metadata subpoena

A lawful subpoena to us (the OxPulse Chat operator) can obtain: room IDs, connection timestamps, ICE candidate IP addresses logged during session setup, byte-count telemetry. It cannot obtain message content or media. We log the minimum necessary for abuse prevention and compliance; the default partner-edge log policy is no-content logging.

A subpoena to a partner-edge operator can obtain whatever that operator logs on their infrastructure, which is scoped to connection metadata per the no-log partner policy. Operators must agree to the operator terms, which prohibit content logging. However, we cannot technically enforce this — we cannot see inside a partner's deployment. Compliance customers who require stronger guarantees run on dedicated infrastructure (either their own partner-edge node or our first-party hosted tier with a BAA/DPA in place).

5. Concrete scenarios

These are not hypothetical. They describe real usage patterns and what the stack does and does not protect in each.

Scenario 1: Tehran journalist on 3G under active DPI

Setup. A journalist in Tehran is trying to reach a source outside Iran on an Iranian mobile network. The network actively blocks VPNs and throttles foreign HTTPS traffic. Signal voice fails. Telegram video is blocked.

What works. OxPulse routes through TURN-on-:443 via a partner-edge node outside Iran. The TURN connection is wrapped in VLESS/Reality with SNI borrowed from a neutral target not on the Iranian blocklist. The Reality TLS handshake is indistinguishable from a normal TLS connection to that SNI at shallow inspection depth. At 1 KB/s, audio-only continues via Codec2-1200 at 1.2 kbps. In-call chat continues at ~100 bytes per message. Video is suspended and the client shows a status indicator rather than an error.

What does not work. If Iranian DPI operators specifically target the TURN relay's IP and null-route it, the call drops. The client retries via a different partner-edge node from the rotation pool; recovery takes 10–30 seconds. If all registered partner-edge nodes in the rotation are null-routed, service is unavailable. We maintain a pool of partner-edge nodes in diverse jurisdictions to make complete blackout harder; we cannot make it impossible.

What we do not claim. A global adversary correlating the journalist's 3G IP with the partner-edge relay's outbound connection can establish that the journalist used that relay at that time. We do not protect against this. The content of the call is not accessible to that adversary.

Scenario 2: Subpoena to a partner-edge operator

Setup. Law enforcement in the partner operator's jurisdiction issues a lawful subpoena requesting "all data related to communications with room ID X on date Y."

What the operator can hand over. Connection logs: which IP addresses connected to their relay during session X, session start/end timestamps, total bytes transferred per connection. Room ID X as a correlation identifier.

What the operator cannot hand over. Message content. Call audio or video. Encryption keys. Participant identities (OxPulse uses anonymous device IDs — no account, no name, no email tied to a room session in the default configuration).

What our signaling server holds. Room IDs, ICE candidates (participant IPs during session setup), session timestamps. A subpoena to us yields the same scoped metadata.

Compliance-track customers. Operators running OxPulse under a BAA (healthcare) or customer DPA configure audit logging that is richer — including session participant counts, session duration, and compliance events — but still not message content. The audit trail is specifically scoped for compliance reporting, not surveillance. This is documented in the compliance posture section of docs/strategy/POSITIONING.md §4b.

Scenario 3: Global passive adversary correlating ingress and egress

Setup. An adversary with access to traffic at multiple IXPs attempts to correlate a specific user's IP address with a specific partner-edge relay's forwarded connections, using timing and volume fingerprinting.

What happens. If the adversary observes both the user's ISP uplink and the partner-edge relay's uplink/downlink, they can correlate sessions by timing and byte count with accuracy that depends on how much entropy is in the traffic pattern. At 1 KB/s sustained audio-only, packets are small and regular — the correlation signal is cleaner than for bursty HTTP traffic. At higher bandwidth (video), there is more noise.

Our position. We do not protect against this. This attack class requires significant infrastructure access and is characteristic of Tier 2 nation-state adversaries conducting targeted surveillance of known individuals. Our anti-censorship layer protects connectivity and content. It does not protect against traffic-analysis correlation by an adversary with multi-point network access.

Mitigation path. Cover traffic (padding messages to fixed timing intervals) and onion routing through multiple relay hops would partially mitigate this. Both are in the research backlog (§7). Neither is in the current stack.

Scenario 4: Endpoint malware on user's laptop

Setup. A user's laptop is compromised with malware that has browser extension access or OS-level keystroke / screen capture capability.

What happens. The attacker can read decrypted messages in the browser DOM, capture audio via OS-level audio hooks before it reaches WebRTC, and exfiltrate session key material from browser memory.

Our position. This is out of scope. No end-to-end encrypted system protects against an attacker with access to the endpoint where decryption occurs. This is the same boundary as Signal, WhatsApp, and iMessage. Mitigation is endpoint security: device management, EDR, browser hardening.

We note this explicitly because some users conflate "E2EE" with "secure against a device that is already compromised." It is not.

5a. What about the control plane?

The previous sections model compromised partner-edge operators (Tier 3) and nation-state network adversaries (Tier 2). Neither explicitly addresses a compromise or coercion of the control plane itself.

What a compromised api.oxpulse.chat could do:

• Issue fake ptkn_* registration tokens to operators who do not exist or are attacker-controlled. This would insert attacker nodes into the federated mesh, giving them traffic relay access (connection metadata, relay timing) but still not call content — SFrame encryption holds regardless of relay identity.
• Publish forged AmneziaWG peer configurations that route partner-node-to-partner-node traffic through attacker infrastructure, enabling traffic-correlation attacks at scale.
• Deny registration to legitimate operators, degrading network availability.
• Poison Prometheus scrape targets, making the network appear healthier or unhealthier than it is.

What a compromised control plane could NOT do:

• Read message content or call audio. Content keys are ephemeral and generated in participants' browsers; they are never transmitted to or held by the control plane.
• Forge authenticated SFrame messages (AEAD prevents this regardless of network position).
• Retroactively decrypt past sessions (forward secrecy holds at the call layer).

Blast radius vs. a compromised partner-edge operator. A single compromised operator node affects users who route through that node. A compromised control plane is a larger blast radius: it can affect the entire operator mesh. This is the honest trade-off of federated design with a centralized control plane. We have not designed a decentralized alternative to the control plane; if we do, it will be documented here.

Current mitigations. The control plane is a hardened first-party service. Partner-edge nodes pin the control plane's TLS certificate; a MITM-substituted control plane with a different cert would be rejected. The AmneziaWG mesh uses per-node key pairs; the control plane distributes public keys but cannot impersonate peers without private key access.

6. Comparison with adjacent tools

The goal here is accuracy, not marketing. Where a competitor is stronger on a given axis, we say so.

Notes on specific comparisons:

Signal vs OxPulse. Signal's message-level Double Ratchet provides stronger per-message forward secrecy than our epoch-level ratchet. Signal's audit record (external audits 2016, 2024) is more established than ours. Signal has no group video and no self-hosting story. Signal voice is blocked in Russia — OxPulse is not (tested).

Tor vs OxPulse. Tor provides genuine network-level anonymity that we do not provide. Tor's latency (100–300 ms typical) makes real-time voice unsuitable. These are complementary, not competitive. A journalist who needs anonymity and voice communication should use OxPulse for the voice session and Tor for the metadata-sensitive parts of their operation.

Briar vs OxPulse. Briar is stronger on anonymity (Tor transport) and works on Android without internet (Bluetooth/WiFi mesh). It does not support video and requires a native app. For text-only, Tor-protected communication with offline capability, Briar is often the better choice.

Matrix/Element vs OxPulse. Matrix is fully open and federated; we are not (partner-edge only). Matrix E2EE is optional and historically has had implementation issues (known key backup vulnerabilities in older clients). Matrix has no DPI evasion. Our compliance story is more developed.

Telegram vs OxPulse. Telegram's E2EE is not default (only Secret Chats). Group chats are unencrypted on Telegram's servers. MTProto has not received the level of external audit that Signal Protocol has. Telegram is relevant as "what users actually use" in Russia/Iran, not as a security tool.

6a. Versions covered

This threat model applies to:

• oxpulse-chat at HEAD as of 2026-05-08
• oxpulse-partner-edge v0.12.10 (released 2026-05-07)
• str0m 0.18 (SFU media engine)
• axum 0.8, tokio 1 (signaling server)
• jsonwebtoken 10 with aws-lc-rs backend (FIPS-ready)
• ML-KEM-768 post-quantum key exchange on the xray-client control-plane tunnel (not on the user-data DTLS path; xray 26.x)
• AmneziaWG mesh underlay provisioned by the orchestrator daemon (added 2026-05-07, partner-edge PR #51)

7. Open work

This is the list of hardening items that are not yet implemented. OTF reviewers in particular care about what remains — a threat model that only describes what is done is incomplete.

High priority (architectural gaps)

• Per-message forward secrecy. Current ratchet advances per epoch (member join/leave). Signal's Double Ratchet advances per message. Within a session epoch, all messages are decryptable with that epoch's key. Implementing message-level ratchet advancement is on the roadmap but not scoped.
• Sealed sender equivalent. The signaling server sees which room ID a message is associated with and the ICE candidate IPs of participants. We do not implement a sealed-sender design that hides sender identity from the signaling infrastructure. This is a known gap relative to Signal's sealed-sender.
• Traffic-analysis padding. We do not pad messages to fixed-size intervals or add cover traffic. Timing and volume patterns are observable by relay operators and network observers. This is the primary remaining attack surface for traffic-correlation attacks.
• Bespoke Reality fingerprinting resistance. VLESS/Reality obfuscation is strong against known DPI signatures but not against dedicated traffic-analysis research targeting Reality specifically. Adding an additional obfuscation layer (e.g., domain fronting or pluggable transports as a fallback) is planned but not shipped.

Medium priority (implementation hardening)

• Nonce/counter rollover audit. Our AEAD uses a counter-based nonce that is strictly monotonic per epoch. On epoch rotation, seenCounters state grows unbounded (noted in docs/FOLLOWUPS.md A1). A formal audit of counter management and an explicit replay-window bound is pending.
• Partner-edge audit (third-party). The oxpulse-partner-edge code is AGPL and readable. It has not received a formal external security audit. We plan a third-party audit before v1.0 release.
• Post-quantum migration timeline. ML-KEM-768 is used for the VLESS tunnel key exchange. DTLS-SRTP does not yet use a post-quantum key exchange. NIST standardized ML-KEM in 2024 (FIPS 203); integrating it into the WebRTC DTLS handshake requires a browser-side change or a custom DTLS implementation. Timeline: v2.0 target.
• Operator log-policy enforcement. We contractually require operators not to log content. We cannot technically enforce this — we cannot audit partner deployments. A future design that makes content logging structurally impossible (rather than contractually prohibited) is preferable.

Lower priority (longer horizon)

• Steganographic fallback channel. For scenarios where OxPulse is completely blocked, a steganographic cover channel (e.g., hidden data in image traffic) is in speculative R&D. This is not a current feature. Statistical steganalysis can detect naive implementations — this is only listed as a direction, not a commitment.
• AI-vs-human attestation. Cryptographic proof that a call participant is a human (camera-attested liveness) rather than a deepfake voice synthesis system. Planned for v2.5; not relevant to the current threat model but listed because it addresses an emerging attack vector.