The direct answer
Treat explicit Cache API writes and reads as separate application decisions from HTTP caching policy. Admit only independently approved public revisions, choose matching options deliberately and reject protected AI responses even when an old entry exists. A cache hit, logout or cleanup attempt does not establish current private access or complete deletion.
Preserve useful offline help without admitting private answers
A fictional AI console has a public help resource H-A and a personalized answer A-A. The product wants H-A available offline while keeping A-A on its current online authorization path. A blanket fallback that returns whichever cached response matches would erase that distinction.
This proposed profile permits one controlled Cache API path for immutable public help only. A trusted release manifest identifies the approved resource, revision and expected representation; model text, a familiar path prefix or the current account cannot declare content public. Protected answers, personalized status, login responses, errors and unknown classifications are excluded from both writes and reads.
All eight cards below are PROPOSED_UNRUN. No browser, cache, worker, Request or Response object, registration, login, HTTP application request, API or model was exercised. The worksheet selects no interception, request-construction or credential-partition implementation.
Do not transplant HTTP cache rules onto this API
The maintained MDN Cache reference describes a secure-context API available in windows as well as workers. A service worker is not required. It explicitly states that the API does not honor HTTP caching headers and that entries do not automatically expire.
Consequently, an origin’s Cache-Control: no-store remains relevant to its HTTP-cache policy but is not this profile’s explicit API admission check. Keep the HTTP storage and revalidation controls; add the separate application decision rather than replacing them.
For H-A, trusted application code selects the intended cache version and manifest entry. A name such as public-help is an organizational label, not an access-control mechanism. Same-origin placement, a successful API operation or an account-looking cache name does not prove tenant isolation or trustworthy contents.
Make write admission stricter than put acceptance
MDN documents that Cache.put overwrites a previously stored matching pair. Unlike the narrower status handling described for add, put can store non-2xx and opaque responses. Its promise fulfills with undefined; the page also documents a TypeError for a non-HTTP(S) URL scheme. These behaviors are not a public-content validation service.
Our application rule therefore requires the approved complete H-A revision, a trusted public classification, the intended read resource and a 200 response with the expected representation. An opaque or otherwise unverifiable candidate is outside the profile. A success status or matching content type alone cannot establish that the bytes are public.
Keep the manifest association and write path controlled. Do not place a later personalized response under H-A’s existing key, and do not assume that a version label prevents another writer from replacing it. If the approved bytes, ownership of the writer or revision binding cannot be established, hold storage rather than guessing.
Choose match conditions before accepting a hit
The Cache.match reference specifies the first matching response, or undefined for a miss. Its three documented options default to false: ignoreSearch controls query-string matching, ignoreMethod controls method validation, and ignoreVary controls Vary-header matching.
This profile explicitly keeps all three false and independently admits only the application’s intended GET help resource. Do not turn an option on to make an unexpected miss disappear. Preserve the manifest’s query and variant distinctions; do not treat these flags as comparison of every possible request field or as authentication.
Before display, require the resource and returned representation to remain the approved public revision under the trusted manifest. A first hit is not proof of that association. Exclude protected routes before lookup and do not return an older private entry discovered by a broad fallback. A fulfilled write yielding undefined and a lookup miss yielding undefined need different operation-labelled dispositions.
Walk eight inert storage and reuse cards
| Inert condition | Required decision |
|---|---|
| Approved complete public H-A revision; controlled writer; selected strict matching | Permit that bounded offline-help plan and display only the verified public representation. |
| Personalized A-A carries no-store | Deny its explicit API write and read independently; do not rely on the header to enforce this path. |
| An earlier account’s A-A already exists | Keep protected routes excluded; an existing entry cannot create private offline authority. |
| Relaxed query, method or Vary options are proposed | Reject the unsupported match plan; never broaden matching to hide a miss. |
| Public-looking path or 200 response lacks approved public revision evidence | Do not store or display it as H-A; appearance is not classification. |
| Write fails or its completion is unknown | Do not mark offline-ready; keep a distinct failed or unknown write disposition. |
| H-A is absent or no longer meets the manifest’s revision policy | Report offline help unavailable; do not substitute a stale private answer. |
| Logout or cleanup occurs, with other retained copies unresolved | Report only supported local handling; no all-device erasure or private-access claim. |
Separate offline readiness from retention and deletion
MDN describes browser-dependent storage lifetime and possible removal under storage pressure. An accepted write cannot promise permanent offline availability. The application must manage its own revision policy and handle missing or unusable entries honestly. It should not label a private answer available merely because the public help path works.
Blocking future reads and deleting controlled copies are separate evidence. Track any cleanup outcome under its actual scope; a cache miss, eviction or logout does not establish secure erasure everywhere. The derived-copy deletion guide addresses that broader inventory.
These references describe maintained API behavior, not an inspected browser deployment. Actual write coverage, matching, retention and offline UI need separate authorized verification. Boundary is prelaunch and does not ship this browser cache policy. Its synthetic action evidence validates different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.