CallControls (the in-room bar) reads io.lotus.room_quality and hides the camera / screenshare buttons when allow_camera / allow_screenshare are false, and gates screenshare behind a "Share your screen?" confirmation. The persistent CallStatus bar — which is rendered app-wide for the whole call (Router.tsx:192 → CallStatusRenderer) — renders the same Video and ScreenShare buttons with no room-policy check and no confirmation, calling control.toggleScreenshare() straight away. So the client-side "audio-only room" / "no screensharing" enforcement is trivially bypassed by using the status bar instead of the call bar, and a single mis-click there starts a screenshare with no confirm.
How to trigger
in a room with Room Settings → Call Permissions → Allow Screen Sharing off, join the call and click the screenshare icon in the top call-status bar.
Suggested fix
hoist the roomQuality lookup into a shared hook and apply the same showCamera/showScreenshare gating plus the share-confirm dialog in features/call-status/CallControl.tsx.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** medium · **Type:** bug · **Confidence:** high
**Location:** `src/app/features/call-status/CallControl.tsx:300-307`, `src/app/features/call/CallControls.tsx:110-118,403-418`
### Problem
`CallControls` (the in-room bar) reads `io.lotus.room_quality` and hides the camera / screenshare buttons when `allow_camera` / `allow_screenshare` are `false`, and gates screenshare behind a "Share your screen?" confirmation. The persistent `CallStatus` bar — which is rendered app-wide for the whole call (`Router.tsx:192` → `CallStatusRenderer`) — renders the same Video and ScreenShare buttons with **no** room-policy check and **no** confirmation, calling `control.toggleScreenshare()` straight away. So the client-side "audio-only room" / "no screensharing" enforcement is trivially bypassed by using the status bar instead of the call bar, and a single mis-click there starts a screenshare with no confirm.
### How to trigger
in a room with Room Settings → Call Permissions → Allow Screen Sharing off, join the call and click the screenshare icon in the top call-status bar.
### Suggested fix
hoist the `roomQuality` lookup into a shared hook and apply the same `showCamera`/`showScreenshare` gating plus the share-confirm dialog in `features/call-status/CallControl.tsx`.
---
_Filed from the September 2026 client audit (branch `lotus` @ 4bea4895)._
jared
added this to the Audit 2026-09 · Medium & Low milestone 2026-09-12 01:50:57 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: medium · Type: bug · Confidence: high
Location:
src/app/features/call-status/CallControl.tsx:300-307,src/app/features/call/CallControls.tsx:110-118,403-418Problem
CallControls(the in-room bar) readsio.lotus.room_qualityand hides the camera / screenshare buttons whenallow_camera/allow_screensharearefalse, and gates screenshare behind a "Share your screen?" confirmation. The persistentCallStatusbar — which is rendered app-wide for the whole call (Router.tsx:192→CallStatusRenderer) — renders the same Video and ScreenShare buttons with no room-policy check and no confirmation, callingcontrol.toggleScreenshare()straight away. So the client-side "audio-only room" / "no screensharing" enforcement is trivially bypassed by using the status bar instead of the call bar, and a single mis-click there starts a screenshare with no confirm.How to trigger
in a room with Room Settings → Call Permissions → Allow Screen Sharing off, join the call and click the screenshare icon in the top call-status bar.
Suggested fix
hoist the
roomQualitylookup into a shared hook and apply the sameshowCamera/showScreensharegating plus the share-confirm dialog infeatures/call-status/CallControl.tsx.Filed from the September 2026 client audit (branch
lotus@4bea4895).