The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. Browser capture permission is not consent for a particular remote viewer. The app displays viewer identity and capture scope, and stop propagates immediately from either side.
Abuse controls must bound both attackers and data collection. Prefer short-lived, coarse, explainable signals while preserving recovery and appeal for shared networks, weak links, and assistive tools.
Make the implementation decisions explicit
Start from facts the data and protocol can guarantee, then decide what the interface may promise. Each rule below needs an owner, a bound, and a compatibility policy rather than an oral convention from one review.
- Reverify the peer capability, prefer the current tab, disclose system audio, show persistent status and viewer count, then atomically end the session when the track ends.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Use explicit capability negotiation so older clients receive an explained fallback instead of a half-working state.
The delivery standard for Threat Modeling Screen Sharing Before, During, and After Capture is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Failure paths that are easy to miss
Prioritize faults that silently preserve false facts: the interface looks recovered while a queue, permission, or counter has diverged. The defect often appears only on the next action.
- If B refreshes while A still says sharing, the privacy state is false; encoding in a hidden tab can expose the screen and waste power with no viewer.
- A stale response arriving after a new task can overwrite healthy state or restart cancelled work without version fencing.
- An untested fallback receives all traffic during a primary failure and becomes the slower, more expensive bottleneck.
How to verify it before release
Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.
- Cover viewer refresh, close, network loss, trust revoke, system stop, and sharer crash; both UIs and tracks must converge within a defined deadline.
- Disconnect, change networks, and recover mid-operation; reconcile endpoint state, persistence, and resource counts.
- Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.
The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.