[GH-ISSUE #8701] [Feature] Capture WebRTC peer-connection and data-channel metadata as read-only Evidence #7514

New issue

Open

opened 2026-11-03 00:30:27 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 00:30:27 +00:00

Owner

Originally created by @jayykernel on GitHub (Nov 2, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8701

Problem

Web applications increasingly use WebRTC for real-time media and peer-to-peer data exchange. Ordinary HTTP/HAR and WebSocket evidence does not explain the peer-connection lifecycle, negotiated media/data-channel structure, ICE connectivity choices or the relationship between signaling and the resulting peer connection.

Proposed outcome

Add an opt-in, passive WebRTC inspection capability for an explicitly selected browser target.

Inventory peer-connection creation and lifecycle transitions, including connection and ICE gathering states where exposed by the browser.
Record non-payload metadata for transceivers, media kinds, directions, codecs, RTP header extensions and data-channel configuration.
Capture ICE candidate type/protocol and selected-pair metadata, while redacting IP addresses, mDNS hostnames, usernames, passwords, fingerprints and other identifying or credential-like values by default.
Correlate peer-connection events with observed signaling requests/WebSocket events using timestamps and explicit confidence; do not assume a signaling message belongs to a connection without evidence.
Preserve browser version, target/origin, capture interval, unavailable fields and partial event coverage.
Compare two captures to identify changes in negotiated capabilities and connection lifecycle.

Safety and privacy boundary

Do not capture audio/video frames, data-channel payloads, SDP secrets, ICE credentials or raw network packet contents. Do not create connections, alter negotiation, inject scripts into the page, or force renegotiation. Collection must be passive, opt-in and bounded.

Acceptance criteria

Owned fixtures cover offer/answer lifecycle, ICE state changes, multiple transceivers, data channels and failed/partial negotiation.
Sensitive candidate and SDP fields are redacted before persistence; tests assert that secrets and identifying addresses are absent.
CLI/MCP Evidence retains target, origin, timestamps, provenance and explicit coverage limitations.
Correlation to signaling evidence is labeled as observed or inferred, never silently asserted.
Documentation states supported browser/provider versions and collection limitations.

Scope

A focused browser-observation feature under the website reverse-engineering direction (#774). This is not a packet sniffer, media recorder, TURN/STUN scanner or WebRTC security-testing tool.

Originally created by @jayykernel on GitHub (Nov 2, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8701 ## Problem Web applications increasingly use WebRTC for real-time media and peer-to-peer data exchange. Ordinary HTTP/HAR and WebSocket evidence does not explain the peer-connection lifecycle, negotiated media/data-channel structure, ICE connectivity choices or the relationship between signaling and the resulting peer connection. ## Proposed outcome Add an opt-in, passive WebRTC inspection capability for an explicitly selected browser target. - Inventory peer-connection creation and lifecycle transitions, including connection and ICE gathering states where exposed by the browser. - Record non-payload metadata for transceivers, media kinds, directions, codecs, RTP header extensions and data-channel configuration. - Capture ICE candidate type/protocol and selected-pair metadata, while redacting IP addresses, mDNS hostnames, usernames, passwords, fingerprints and other identifying or credential-like values by default. - Correlate peer-connection events with observed signaling requests/WebSocket events using timestamps and explicit confidence; do not assume a signaling message belongs to a connection without evidence. - Preserve browser version, target/origin, capture interval, unavailable fields and partial event coverage. - Compare two captures to identify changes in negotiated capabilities and connection lifecycle. ## Safety and privacy boundary Do not capture audio/video frames, data-channel payloads, SDP secrets, ICE credentials or raw network packet contents. Do not create connections, alter negotiation, inject scripts into the page, or force renegotiation. Collection must be passive, opt-in and bounded. ## Acceptance criteria - [ ] Owned fixtures cover offer/answer lifecycle, ICE state changes, multiple transceivers, data channels and failed/partial negotiation. - [ ] Sensitive candidate and SDP fields are redacted before persistence; tests assert that secrets and identifying addresses are absent. - [ ] CLI/MCP Evidence retains target, origin, timestamps, provenance and explicit coverage limitations. - [ ] Correlation to signaling evidence is labeled as observed or inferred, never silently asserted. - [ ] Documentation states supported browser/provider versions and collection limitations. ## Scope A focused browser-observation feature under the website reverse-engineering direction (#774). This is not a packet sniffer, media recorder, TURN/STUN scanner or WebRTC security-testing tool.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#7514

No description provided.

Rows
Columns