BLOCKER: Mail reader cache keeps revoked sender image permission

kayg commented

2026-10-02 13:06:55 +00:00

Owner

Round 7b defensive review for #427. Branch: job/maillayouts, head f9f360e68f4e.

Severity: P1 privacy leak. Merge blocker. The new Mail reader cache can use a sender's old remote-image permission after the User withdraws it. The browser can then send the User's address and message-open timing to the remote image host.

Evidence:

crates/plugins/mail/src/cache/store.rs:1643 reads image permission by (owner_id, sender_address). The removal at line 1663 applies to all messages from that sender.
apps/web/src/lib/mail/MailView.svelte:917 changes that sender permission, but lines 921–928 remove and refresh only the selected message ID.
apps/web/src/lib/mail/MailView.svelte:548 restores a warmed detail and returns at line 553 without checking the current permission.
apps/web/src/lib/mail/MailReaderContent.svelte:56 passes the cached permission to the frame. apps/web/src/lib/mail/frame.ts:131 permits direct HTTPS image requests when that permission is true.

Expected: a sender permission change takes effect for every retained message from that sender before it can render. Invalidate matching pending reads too, so an older completion cannot restore the grant. Prefer a separate current permission model over keeping security decisions inside long-lived body entries. Keep the image-proxy work in #726 consistent with this rule.

Verification: a small local check used the branch's actual BoundedReaderCache. Two inert entries started with the same allowed sender state. After the selected entry was removed and replaced with the refused state, the other entry still returned remote_content_allowed: true. No network requests or hostile payloads were used. Output:

CONFIRMED: another warmed message retains revoked sender image permission.

Regression test idea: warm two messages from one synthetic sender, withdraw the sender's image permission through one message, then select the other. Assert that no remote-image request starts and that its frame uses the current permission. Include a pending prefetch completion and all three reading layouts.

Duplicate search: searched all issue states for remote images and reader cache; read #640, #641 and #726. #726 covers faithful HTML and an image proxy. It does not cover sender permission invalidation in the new reader cache.

Round 7b defensive review for #427. Branch: `job/maillayouts`, head `f9f360e68f4e`. Severity: P1 privacy leak. **Merge blocker.** The new Mail reader cache can use a sender's old remote-image permission after the User withdraws it. The browser can then send the User's address and message-open timing to the remote image host. Evidence: - `crates/plugins/mail/src/cache/store.rs:1643` reads image permission by `(owner_id, sender_address)`. The removal at line 1663 applies to all messages from that sender. - `apps/web/src/lib/mail/MailView.svelte:917` changes that sender permission, but lines 921–928 remove and refresh only the selected message ID. - `apps/web/src/lib/mail/MailView.svelte:548` restores a warmed detail and returns at line 553 without checking the current permission. - `apps/web/src/lib/mail/MailReaderContent.svelte:56` passes the cached permission to the frame. `apps/web/src/lib/mail/frame.ts:131` permits direct HTTPS image requests when that permission is true. Expected: a sender permission change takes effect for every retained message from that sender before it can render. Invalidate matching pending reads too, so an older completion cannot restore the grant. Prefer a separate current permission model over keeping security decisions inside long-lived body entries. Keep the image-proxy work in #726 consistent with this rule. Verification: a small local check used the branch's actual `BoundedReaderCache`. Two inert entries started with the same allowed sender state. After the selected entry was removed and replaced with the refused state, the other entry still returned `remote_content_allowed: true`. No network requests or hostile payloads were used. Output: ```text CONFIRMED: another warmed message retains revoked sender image permission. ``` Regression test idea: warm two messages from one synthetic sender, withdraw the sender's image permission through one message, then select the other. Assert that no remote-image request starts and that its frame uses the current permission. Include a pending prefetch completion and all three reading layouts. Duplicate search: searched all issue states for remote images and reader cache; read #640, #641 and #726. #726 covers faithful HTML and an image proxy. It does not cover sender permission invalidation in the new reader cache.

kayg referenced this issue

2026-10-02 13:11:10 +00:00

Log attachments: deleted file still shown, attachments not live, batch send not live, Log order, raw camera names #427

kayg referenced this issue

2026-10-02 13:27:45 +00:00

Log attachments: deleted file still shown, attachments not live, batch send not live, Log order, raw camera names #427

kayg referenced this issue

2026-10-02 17:33:01 +00:00

Plan: merge order and conflicts for merge round 7b #867

kayg referenced this issue

2026-10-02 17:47:27 +00:00

Mail: render HTML emails faithfully (sender layout + CSS) in a strict sandbox, with an image proxy and Load images #726

kayg commented

2026-10-02 17:47:28 +00:00

Author

Owner

Design-sync #864 corrected DESIGN §45 on job/design-sync, commit 01c9bf1f4.

Old docs/DESIGN.md:2173-2174 required consent before remote content loads. The owner comment on #726 dated 2026-10-02 supersedes that rule. DESIGN now records automatic server image-proxy loading, fetch at delivery or first sync, no cookies or Referer, size/type limits, silent tracking-pixel removal and the one default-on Settings switch. No reader Load images button or blocked notice. Sender layout and colours stay; dark adaptation is in ⋯.

#736's cache requirement stays: check current preference and access before showing retained content. Regression idea: no browser request to a remote image host; no upstream fetch on message open; tracking pixels stay absent; changing the setting affects retained content. No runtime claim or test run from this LIGHT documentation job.

Design-sync #864 corrected DESIGN §45 on `job/design-sync`, commit `01c9bf1f4`. Old docs/DESIGN.md:2173-2174 required consent before remote content loads. The owner comment on #726 dated 2026-10-02 supersedes that rule. DESIGN now records automatic server image-proxy loading, fetch at delivery or first sync, no cookies or Referer, size/type limits, silent tracking-pixel removal and the one default-on Settings switch. No reader Load images button or blocked notice. Sender layout and colours stay; dark adaptation is in ⋯. #736's cache requirement stays: check current preference and access before showing retained content. Regression idea: no browser request to a remote image host; no upstream fetch on message open; tracking pixels stay absent; changing the setting affects retained content. No runtime claim or test run from this LIGHT documentation job.

kayg referenced this issue

2026-10-02 17:47:45 +00:00

Audit: DESIGN.md versus the code (decided but missing, built differently, OPEN items built) #864

kayg referenced this issue from a commit

2026-10-02 17:48:34 +00:00

docs(design): sync sections 18, 33, 45 and 57 with later owner rules

kayg commented

2026-10-02 18:14:33 +00:00

Author

Owner

Independent read-only review of job/mailhtml-726 at
76a79589e338d17dfe3f4c503b8a6e7c8b43e075, for #726 and #736.
No build, test, server or browser was used.

P1: cached-image access differs between read paths.
crates/plugins/mail/src/routes.rs:1423 checks the current User preference,
then line 1432 calls remote::hydrate. The query at
crates/plugins/mail/src/remote.rs:413 checks owner, account and image ID but
not whether the Connected Account is enabled. The message query at
crates/plugins/mail/src/cache/store.rs:1451 also lacks that check. The
direct image route at routes.rs:1480 does require a.enabled=1.
A new detail request can thus return cached remote bytes in data URLs after
the account is disabled, while the image route refuses the same image.

Fix: use one current-access check before both image reads. Keep local message
text if that is the intended account policy. Regression idea: prepare an
owned remote image, disable its account, and read both routes. Neither may
return remote image bytes. Include another User and a missing image.

P2: another tab retains the old content preference.
apps/web/src/routes/settings/mail/MailSection.svelte:120 clears only that
JavaScript context's cache after the setting is saved. Warm selection at
apps/web/src/lib/mail/MailView.svelte:576 returns retained bodies without a
current-preference check. apps/web/src/lib/mail/frame.ts:47 ignores the
allowance argument because remote bytes are embedded. There is no preference
revision or cross-tab notification in these paths. An API preference change
also leaves the warm body intact.

Fix: keep current preference state outside cached bodies, notify readers of
changes, and fence pending work by revision. Revalidate before warm rendering.
Regression idea: warm two messages in two tabs, turn off Load remote content,
and select both messages. Include a delayed completion. The data-only CSP
prevents a direct sender request; this finding does not claim a User-IP or
message-open leak.

DESIGN §45 and #736 require current preference and access before cached
content is shown. Duplicate searches covered all states for remote, revoked
and hydrate terms. These findings extend #736; no duplicate issue was opened.
Full review: review-mailhtml-726.md and audit-findings.md on
job/rev2-mailhtml-726. No product code was changed.

Independent read-only review of `job/mailhtml-726` at `76a79589e338d17dfe3f4c503b8a6e7c8b43e075`, for #726 and #736. No build, test, server or browser was used. **P1: cached-image access differs between read paths.** `crates/plugins/mail/src/routes.rs:1423` checks the current User preference, then line 1432 calls `remote::hydrate`. The query at `crates/plugins/mail/src/remote.rs:413` checks owner, account and image ID but not whether the Connected Account is enabled. The message query at `crates/plugins/mail/src/cache/store.rs:1451` also lacks that check. The direct image route at `routes.rs:1480` does require `a.enabled=1`. A new detail request can thus return cached remote bytes in data URLs after the account is disabled, while the image route refuses the same image. Fix: use one current-access check before both image reads. Keep local message text if that is the intended account policy. Regression idea: prepare an owned remote image, disable its account, and read both routes. Neither may return remote image bytes. Include another User and a missing image. **P2: another tab retains the old content preference.** `apps/web/src/routes/settings/mail/MailSection.svelte:120` clears only that JavaScript context's cache after the setting is saved. Warm selection at `apps/web/src/lib/mail/MailView.svelte:576` returns retained bodies without a current-preference check. `apps/web/src/lib/mail/frame.ts:47` ignores the allowance argument because remote bytes are embedded. There is no preference revision or cross-tab notification in these paths. An API preference change also leaves the warm body intact. Fix: keep current preference state outside cached bodies, notify readers of changes, and fence pending work by revision. Revalidate before warm rendering. Regression idea: warm two messages in two tabs, turn off Load remote content, and select both messages. Include a delayed completion. The data-only CSP prevents a direct sender request; this finding does not claim a User-IP or message-open leak. DESIGN §45 and #736 require current preference and access before cached content is shown. Duplicate searches covered all states for remote, revoked and hydrate terms. These findings extend #736; no duplicate issue was opened. Full review: `review-mailhtml-726.md` and `audit-findings.md` on `job/rev2-mailhtml-726`. No product code was changed.

kayg referenced this issue

2026-10-02 18:14:51 +00:00

Mail: render HTML emails faithfully (sender layout + CSS) in a strict sandbox, with an image proxy and Load images #726

kayg referenced this issue from a commit

2026-10-03 05:58:47 +00:00

Fix Mail HTML review findings: account access, cross-tab preference, retired sender control, body selectors

kayg referenced this issue

2026-10-03 06:03:04 +00:00

Mail: render HTML emails faithfully (sender layout + CSS) in a strict sandbox, with an image proxy and Load images #726

kayg commented

2026-10-03 06:03:05 +00:00

Author