Privacy and security boundaries

Core memory snapshots

The core captures supported text-like inputs, textareas, checkbox and radio state, and select values before transport. The snapshot remains in page memory only and can be released after success.

Password, file, hidden, submit, reset, image, generic button, ignored, and out-of-form controls are excluded. File field names may be recorded so the interface can explain that files need reselection; file data is never stored.

Session recovery storage

The optional addon stores a versioned record in sessionStorage. It adds pathname, timestamps, expiry, state, the filtered snapshot, and an optional submission reference. It never stores cookies, headers, raw FormData, file objects, response bodies, or hidden CSRF fields.

Session storage is used instead of local storage because its lifetime is scoped to the tab. It is still readable by same-origin scripts, may remain available for a restored browser session, may be denied, and is not encryption.

Prefer a field allowlist

Use fieldNames to include only the minimum fields that provide meaningful recovery. The addon always excludes passwords, files, hidden controls, ignored controls, and payment autocomplete tokens such as cc-number, cc-csc, and cc-exp.

Public events and response bodies

Core lifecycle events contain the instance, state, attempt number, retry and unknown-outcome flags, safe response metadata, field-error names/messages, restoration source, and optional reference. They exclude field values, payloads, full responses, headers, cookies, and stack traces.

Core classification never reads an arbitrary response body. The server-error-mapper addon does so only when explicitly configured, using a cloned response and a size limit. Messages are inserted with textContent and returned HTML is treated as text.

Why retry is not automatic

A network error or navigation interruption does not prove that the receiving server rejected the request. Automatically sending it again can duplicate purchases, applications, legal requests, or support tickets. Online events only indicate a browser connectivity hint; they never trigger transport.

Unknown outcomes disable retry by default. When the application permits an explicit uncertain retry, users should first check whether the original request was received.

Idempotency limitations

A submission reference can correlate attempts and gives a backend a stable key for duplicate detection. It does not guarantee exactly-once behavior unless the backend stores and enforces the key across the complete transaction. References are identifiers, not credentials.

Failure support summaries

The optional failure-support-summary addon reads only selected lifecycle metadata: attempt number, numeric HTTP status, and an optional submission reference. It excludes response URLs, status text, field values, bodies, headers, field errors, and backend messages.

Reference display is disabled by default because operational identifiers can still be sensitive in context. Enable it only when references are opaque, non-personal, and safe for users to share. The addon does not store, transmit, log, or copy the summary.

Application responsibilities

• Use HTTPS and appropriate CORS configuration.
• Enforce server-side validation, authorization, CSRF protection, and abuse controls.
• Choose a retention policy and disclose storage behavior when appropriate.
• Test storage denial, private browsing, navigation, and multi-tab behavior.
• Use dedicated payment and high-risk transaction review.