[GH-ISSUE #8422] [Feature] Inventory browser Cache Storage entries as read-only web Evidence #6597

New issue

Open

opened 2026-11-01 21:12:32 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:32 +00:00

Owner

Originally created by @jayykernel on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8422

Problem

Browser captures can expose DOM, scripts, network activity and parts of browser storage, but an offline-capable web application may keep important application resources in the Service Worker Cache Storage API. Without an explicit inventory, an investigation can miss the cached request/response set that explains offline behavior, stale assets or version transitions.

Proposed outcome

Add an opt-in, read-only Cache Storage inventory to browser inspection and retained capture workflows.

Enumerate cache names and their entries for the selected origin and browser context.
Record request method and URL plus response status, relevant safe headers, MIME type, body size and a content digest where the browser/provider can supply them.
Preserve cache name, origin, capture time, entry ordering where observable, and the source browser/context identity.
Distinguish an empty cache from unavailable, denied, opaque, evicted or partially enumerated entries.
Support comparison across two captures, reporting added, removed and changed entries without claiming that a digest proves semantic change.
Make collection opt-in and bounded by entry-count, byte and time budgets; do not fetch missing resources or trigger service-worker updates.

Safety and privacy

Do not expose response bodies by default. Redact sensitive request headers and URL query values using existing capture redaction policy. Never enumerate other origins or browser profiles outside the selected target/context. Keep opaque responses and inaccessible bodies explicitly unknown rather than treating them as empty.

Acceptance criteria

Owned fixtures cover multiple caches, duplicate URLs in different caches, opaque responses, inaccessible entries and partial enumeration.
CLI/MCP output preserves provenance and reports coverage/limits accurately.
Capture comparison distinguishes added/removed/changed/unknown entries.
Cancellation and cleanup leave the attached browser/context unchanged.
Documentation explains opt-in behavior, privacy limits and unsupported browser/provider combinations.

Scope

A focused browser-storage Evidence capability under the website reverse-engineering direction (#774). This is not a general browser-profile forensic extractor and does not modify cache contents.

Originally created by @jayykernel on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8422 ## Problem Browser captures can expose DOM, scripts, network activity and parts of browser storage, but an offline-capable web application may keep important application resources in the Service Worker Cache Storage API. Without an explicit inventory, an investigation can miss the cached request/response set that explains offline behavior, stale assets or version transitions. ## Proposed outcome Add an opt-in, read-only Cache Storage inventory to browser inspection and retained capture workflows. - Enumerate cache names and their entries for the selected origin and browser context. - Record request method and URL plus response status, relevant safe headers, MIME type, body size and a content digest where the browser/provider can supply them. - Preserve cache name, origin, capture time, entry ordering where observable, and the source browser/context identity. - Distinguish an empty cache from unavailable, denied, opaque, evicted or partially enumerated entries. - Support comparison across two captures, reporting added, removed and changed entries without claiming that a digest proves semantic change. - Make collection opt-in and bounded by entry-count, byte and time budgets; do not fetch missing resources or trigger service-worker updates. ## Safety and privacy Do not expose response bodies by default. Redact sensitive request headers and URL query values using existing capture redaction policy. Never enumerate other origins or browser profiles outside the selected target/context. Keep opaque responses and inaccessible bodies explicitly unknown rather than treating them as empty. ## Acceptance criteria - [ ] Owned fixtures cover multiple caches, duplicate URLs in different caches, opaque responses, inaccessible entries and partial enumeration. - [ ] CLI/MCP output preserves provenance and reports coverage/limits accurately. - [ ] Capture comparison distinguishes added/removed/changed/unknown entries. - [ ] Cancellation and cleanup leave the attached browser/context unchanged. - [ ] Documentation explains opt-in behavior, privacy limits and unsupported browser/provider combinations. ## Scope A focused browser-storage Evidence capability under the website reverse-engineering direction (#774). This is not a general browser-profile forensic extractor and does not modify cache contents.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#6597

No description provided.

Rows
Columns