LotusGuild/cinny
3
0
Fork 0
Code Issues 27 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

Optional setting: don't cache media from encrypted rooms on this device #149

New Issue
Closed
opened 2026-09-17 16:52:00 -04:00 by jared · 1 comment
jared commented 2026-09-17 16:52:00 -04:00
Owner
Copy Link
Copy Source

Verify first how decrypted E2EE attachments are stored (Cache Storage via the service worker's authenticated-media path? in-memory blob URLs?). If they persist in Cache Storage, add Settings → Privacy → "Don't keep media from encrypted rooms on this device" (default off — it costs bandwidth and CPU to re-download and re-decrypt on every view). When on: E2EE media is served from memory only and evicted on room switch; thumbnails included. Device-local setting (excluded from settings sync).

Verify first how decrypted E2EE attachments are stored (Cache Storage via the service worker's authenticated-media path? in-memory blob URLs?). If they persist in Cache Storage, add **Settings → Privacy → "Don't keep media from encrypted rooms on this device"** (default **off** — it costs bandwidth and CPU to re-download and re-decrypt on every view). When on: E2EE media is served from memory only and evicted on room switch; thumbnails included. Device-local setting (excluded from settings sync).
jared added this to the Features 2026-Q4 milestone 2026-09-17 16:52:00 -04:00
jared added the enhancementpriority: mediumsecurityarea: media labels 2026-09-17 16:52:00 -04:00
jared self-assigned this 2026-09-17 16:52:00 -04:00
jared commented 2026-09-19 23:06:52 -04:00
Author
Owner
Copy Link
Copy Source

Verified how E2EE attachments are stored before building anything:

  • The service worker only proxies media requests with the auth header (fetch(event.request) / cache: 'default'); it has no caches.open() — nothing goes into Cache Storage.
  • The app has no IndexedDB media store either (the only IDB the app opens itself is the opt-in search index, already wiped on logout).
  • downloadEncryptedMedia() fetches the ciphertext and decrypts it in memory (decryptFile → Blob → URL.createObjectURL via useObjectURL); the plaintext lives only in a blob URL for the component's lifetime and is revoked on unmount.

So the only thing that can persist on disk is the browser's ordinary HTTP cache holding the encrypted bytes of /_matrix/client/v1/media/download/... responses, which are useless without the room key — Synapse serves them Cache-Control: public, max-age=86400, immutable, the same as any other media. A setting that turns that off would cost a re-download + re-decrypt on every view for no privacy gain (the plaintext was never on disk).

Closing as "already the case": decrypted E2EE media is memory-only today. If a device-local ciphertext cache opt-out is still wanted for threat models where the room key could later leak from the same device, say so and I'll add a cache: 'no-store' switch — but note it wouldn't change what a forensic read of the disk yields (only ciphertext either way).

Verified how E2EE attachments are stored before building anything: - The service worker only **proxies** media requests with the auth header (`fetch(event.request)` / `cache: 'default'`); it has no `caches.open()` — nothing goes into Cache Storage. - The app has no IndexedDB media store either (the only IDB the app opens itself is the opt-in search index, already wiped on logout). - `downloadEncryptedMedia()` fetches the **ciphertext** and decrypts it in memory (`decryptFile` → `Blob` → `URL.createObjectURL` via `useObjectURL`); the plaintext lives only in a blob URL for the component's lifetime and is revoked on unmount. So the only thing that can persist on disk is the browser's ordinary HTTP cache holding the *encrypted* bytes of `/_matrix/client/v1/media/download/...` responses, which are useless without the room key — Synapse serves them `Cache-Control: public, max-age=86400, immutable`, the same as any other media. A setting that turns that off would cost a re-download + re-decrypt on every view for no privacy gain (the plaintext was never on disk). Closing as "already the case": decrypted E2EE media is memory-only today. If a device-local *ciphertext* cache opt-out is still wanted for threat models where the room key could later leak from the same device, say so and I'll add a `cache: 'no-store'` switch — but note it wouldn't change what a forensic read of the disk yields (only ciphertext either way).
jared closed this issue 2026-09-19 23:06:52 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
a11y
Accessibility: keyboard, screen reader, contrast, motion
 area: appearance
Client area: appearance
 area: auth-session
Client area: auth-session
 area: build-ci
Client area: build-ci
 area: calls
Client area: calls
 area: desktop
Client area: desktop
 area: media
Client area: media
 area: messaging
Client area: messaging
 area: mobile
Client area: mobile
 area: moderation
Client area: moderation
 area: navigation
Client area: navigation
 area: notifications
Client area: notifications
 area: settings
Client area: settings
 area: threads
Client area: threads
 bug
Something is not working
 dependencies
Third-party package versions and advisories
 docs
README / LOTUS_* docs wrong or missing
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 needs-human-review
performance
Re-render storms, leaks, heavy work on hot paths
 planning
priority: critical
Data loss, security hole, or crash on a main path
 priority: high
Broken feature or serious usability problem
 priority: low
Minor issue or polish
 priority: medium
Wrong behaviour in an edge case or notable degradation
 qa
Manual QA: shipped, needs a human in a real environment
 question
More information is needed
 research
security
XSS, unsafe URLs, data leaks, auth/session
 tech-debt
Code health, dead code, fragile patterns
 ux
Usability or visual inconsistency
 wontfix
This won't be fixed
No labels area: media enhancement priority: medium security
Milestone
No items
No Milestone Features 2026-Q4
Projects
Clear projects
No projects
Assignees
Clear assignees
cole (Cole Keller) jared (Jared Vititoe) nathan (Nathan Vititoe)
No Assignees jared
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: LotusGuild/cinny#149