CI / Build & Quality Checks (push) Successful in 1m54s
CI / Docker image build & smoke test (push) Skipped
CI / Secret scan (gitleaks) (push) Successful in 13s
CI / Trigger Desktop Build (push) Successful in 7s
CI / Playwright smoke (e2e) (push) Successful in 9m15s
Room widgets were limited to display-only capabilities because the driver
couldn't serve anything else. Now:
- classifyWidgetCapabilities: display caps are still granted silently; reading
or sending events/state in the widget's OWN room is offered to the user;
everything else (other rooms' timelines, to-device, account data, uploads,
user directory, delayed events) stays denied. Writing protected state
(power levels, join rules, encryption, membership, ACLs, widgets, …) is
never offered, and the driver refuses it again at send time.
- WidgetPermissionPrompt names the widget, the host that runs it and who added
it; each request in plain words ("Send messages of type m.text in this
room · as you"); reading is pre-ticked, sending is not; Deny / Escape grant
nothing extra. "Remember my choice" stores it per viewer (localStorage),
tied to the widget URL, so a changed URL asks again.
- GeneralWidgetDriver implements sendEvent / readRoomTimeline / readRoomState
/ readEventRelations, each refusing any room but the widget's own;
RoomWidgetView feeds the room's live (decrypted) events and state updates,
which ClientWidgetApi forwards only if the widget holds the capability.
Verified in Chromium with a cross-origin test widget against a local Synapse:
power-levels and timeline:* requests are never shown; after allowing
send+read the widget's message lands on the server, its power-levels write
is rejected, it receives live messages, and after a reload the remembered
choice skips the prompt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA