LocalStorage Dump (LSD) Specification

Editor’s Draft — 4 May 2025

This document is an Editor’s Draft for discussion within the W3C Linked Web Storage (LWS) Working Group. It proposes LocalStorage Dump (LSD) — a lightweight convention and protocol profile that enables Web applications to serialise window.localStorage and persist the resulting data in any user‑chosen Linked Web Storage–compatible backend (e.g., Solid Pods, remoteStorage/Unhosted, WebDAV, nosdav).

Design principle: Per‑origin, per‑user, format‑agnostic, backend‑agnostic, privacy‑preserving.

Background

Modern client‑side Web applications rely heavily on localStorage for quick, synchronous persistence of small key‑value pairs. Unfortunately, these data are:

siloed inside individual browsers and devices;
opaque to backup workflows;
lost when a user clears their browser or moves to another device;
difficult to migrate between applications that share a logical dataset.

The Linked Web Storage vision decouples application from storage and identity. LSD provides the missing on‑ramp by describing:

A normalised dump format for a snapshot of localStorage scoped to a single origin;
A transmission profile for writing that snapshot to any LWS‑conformant storage server under the user’s control;
A discovery and restore flow for applications to retrieve and re‑hydrate localStorage when appropriate.

LSD is intentionally minimal: it reuses the forthcoming Linked Web Storage Protocol v1.0 for authentication, authorisation, and transport semantics, layering only a few conventions on top.

Scope

In Scope

Data model for serialising localStorage as canonical JSON (see § 7).
HTTP interaction profile that maps LSD operations (dump, list, restore, delete) to LWS Protocol requests.
Path & naming conventions for per‑origin containers.
Security & privacy considerations specific to exposing localStorage off‑device.
Interoperability with representative storage backends: Solid, remoteStorage, WebDAV, nosdav.

Out of Scope

Defining new authentication, authorisation, or identity mechanisms (LWS provides these).
Defining new data formats beyond the JSON mapping in § 7.
Extending browser APIs; LSD is entirely JavaScript‑library‑driven.

Deliverables

ID	Title	Type	Expected Maturity	Note
LSD‑Format 1.0	LocalStorage Dump Format	Normative	W3C Note	Canonical JSON schema & processing rules
LSD‑Profile 1.0	LSD over Linked Web Storage Protocol	Normative	W3C Note	Method verbs, response codes, path template `/apps/lsd/{origin}/`
LSD‑Test Suite	Conformance tests	Non‑normative	–	Dump/restore against Solid, remoteStorage, WebDAV, nosdav
LSD‑Threat Model	Security & privacy analysis	Non‑normative	–	Complements LWS Threat Model

Timeline

Milestone	Date
First Public Working Draft (FPWD)	2025‑07‑15
Wide Review + CR exit criteria agreed	2026‑01‑15
Final Community Review	2026‑04‑15
Publish W3C Note	2026‑06‑01

Success Criteria

Interoperability: ≥ 2 independent client libraries interoperate with ≥ 2 distinct storage servers for every required feature.
Conformance tests: 100 % pass on reference implementations.
Security & Privacy: All considerations in § 9 addressed with mitigations or rationale.
Accessibility: User‑facing flows meet WCAG 2.2 AA.

Coordination

LSD work will be incubated inside the LWS WG but will actively liaise with:

Solid Community Group — mapping to Solid Pods and ACP/WAC.
Unhosted Web CG — alignment with remoteStorage (RFC 9530) and nosdav.
IETF HTTP WG — confirmation of safe/unsafe method usage in the LSD profile.
TAG — design reviews for Web‑platform consistency.

Horizontal review will be requested from Accessibility, Internationalisation, Privacy, and Security IGs at each major transition.

Participation

The Editors expect at least 6 active contributors across client/tool vendors and backend providers. Bi‑weekly telecons will be appended to regular LWS calls; additional ad‑hoc issue‑triage calls may be scheduled.

Communication

GitHub: https://github.com/w3c/lsd-spec (public) — issues, PRs, Editor’s Draft.
Mailing list: [email protected] (publicly archived).
Meeting minutes: published to the repo within 48 hours.

Decision Policy

LSD inherits the LWS WG consensus‑first process (§ 4.2 of the W3C Process). All resolutions taken in calls are subject to a 5 business‑day Call for Consensus on GitHub or the public list. Lack of objections = consensus. Formal votes (1 vote per Member organisation) may be called by Chairs if required.

Patent Policy

LSD specifications are produced under the W3C Patent Policy. Participants must disclose essential claims. The Editors aim for Royalty‑Free licensing.

Licensing

All textual material is licensed under the W3C Software and Document License.

About this Charter

This draft charter extension was prepared by the Editor(s) to capture the initial scope and process for the LSD deliverable within the LWS Working Group. It will evolve based on Working Group input and Advisory Committee review.

6 Terminology

Origin — As defined by the HTML Living Standard; the tuple ⟨scheme, host, port⟩ that scopes localStorage.
Snapshot — The serialised state of all key–value pairs in localStorage for a given origin at a point in time.
LSD Container — A storage location (Solid container, remoteStorage folder, WebDAV collection, etc.) at path /apps/lsd/{origin}/.
Dump — The act of writing a snapshot to an LSD Container.
Restore — The act of retrieving the most recent (or specified) snapshot and re‑hydrating localStorage in a running Web context.

7 Data Model

{
  "$schema": "https://w3c.github.io/lsd-spec/schema-1.0.json",
  "@context": "https://w3c.github.io/lsd-spec/context-1.0.jsonld",
  "id": "{UUID}",
  "origin": "https://example.com",
  "dumpedAt": "2025-05-04T11:32:07Z",
  "kv": {
    "someKey": "someValue",
    "anotherKey": "…"
  }
}

Keys MUST be valid ECMAScript String values.
Values MUST be serialisable via JSON.stringify without a replacer.
Snapshots SHOULD be compressed (e.g., gzip) in transport.

8 Operation Profile (LSD over LWS)

Operation	HTTP Method	Request URI Template	Request Body	Success Response	Notes
Dump	`POST`	`/apps/lsd/{origin}/`	`application/lsd+json` snapshot	`201 Created` + `Location`	Requires `Write` ACL
List	`GET`	`/apps/lsd/{origin}/?select=ids`	–	`200 OK` JSON array of snapshot URIs
Restore	`GET`	`/apps/lsd/{origin}/{snapshotId}`	–	`200 OK` `application/lsd+json`	Client re‑hydrates `localStorage`
Delete	`DELETE`	`/apps/lsd/{origin}/{snapshotId}`	–	`204 No Content`	Optional; obeys server retention policies

Servers MUST expose LSD Containers as LDP Containers or equivalent collection semantics when possible.

9 Security & Privacy Considerations

Sensitive data: Applications SHOULD NOT store passwords, access tokens, or highly sensitive personal data in localStorage; if such data are present, the user agent MUST prompt before dumping.
Cross‑device restoration: To prevent CSRF‑like attacks, clients MUST confirm origin match and display source information before restore.
Snapshot integrity: Snapshots SHOULD be signed (e.g., JWS) when stored in an untrusted backend.
Access control: LSD relies on LWS ACL (e.g., ACP) — default permissions: Owner full access, Public none.

melvincarvalho/LSD.md