Summary

  • W3C's first Web Storage Working Draft appeared on 23 April 2009. Its two-flight-booking example exposed a practical flaw in keeping a transaction marker in a cookie shared by the site's open windows.
  • sessionStorage gave each top-level window an origin-scoped working area. localStorage gave an origin a wider-lived area across windows, without sending its contents on every HTTP request.

A passenger has two airline windows open. One is a sensible morning flight. The other leaves at an hour when even the airport coffee looks tired. Both are on the same site. The passenger switches between them, compares prices, and chooses one. Then the booking form resurrects the wrong trip. The site's memory has one drawer labelled “current flight,” and both windows have been stuffing tickets into it.

That is the problem in W3C's first Web Storage Working Draft of 23 April 2009. Its introduction says a cookie carrying the current booking can let one window's choice leak into the other. A customer could end up buying two tickets for the same flight. It is a pleasantly concrete standards example: the consequence is a charge on a card, not a diagram with three anonymous boxes.

A cookie normally goes along with requests to its site. That is useful for a server trying to recognize a browser. It also makes the site's open windows share a server-facing piece of state. The two booking sessions require a smaller boundary. Each window needs to remember its own route, passenger choices and optional insurance while the traveller works through the form. The browser already knows which top-level window a document belongs to. Web Storage made that fact usable as an address for state.

The first drawer was sessionStorage. The 2013 Recommendation describes a separate storage area for each top-level browsing context and each origin. Pages from the same site in the same window can find the transaction's values as the passenger moves through the booking. A second window has its own area. A script opening a related window may give the new one an initial copy, but the copies then go their own ways. The passenger can keep the morning flight in one window and the midnight ordeal in the other without a shared “current flight” key deciding which one exists.

The origin is the other half of the address. A site gets its own area; a different origin cannot simply browse that drawer. The window gives the transaction a local room, and the origin identifies whose room it is. This is a modest rule with a large effect: the browser can hold several same-site activities at once without making every value part of one shared conversation with the server.

The second drawer was localStorage. It belongs to an origin across its windows and lasts beyond a single browsing session. The specification imagined a site keeping a user-written document or mailbox data in the browser. A cookie would accompany request after request; a local storage value stays in the browser until script reads it and an application chooses what to send. A page-load counter is the specification's small example. The site can count visits in a local key without mailing the counter back with every request like a clerk who insists on attaching the entire filing cabinet to each envelope.

The two drawers share a simple key-and-value interface. setItem, getItem, removeItem and clear let scripts manage entries. The 2016 Second Edition Recommendation says writes and removals are atomic with respect to failure: a failed change leaves the area as it was. A full or disabled area can make setItem throw QuotaExceededError. A change can also produce a storage event in other documents that use the same area, giving another window a signal that the shared local drawer changed. The standard asks for consistent observations by scripts; it does not demand that every call wait for a physical disk write.

One proposed neatness came with a bill. The 2013 text records implementors' objection to a storage mutex intended to keep scripts from seeing races across windows. They considered a broad lock costly enough to raise the possibility of allowing data corruption while looking for a better answer. That argument sits in the standards record. The same specification that handed the browser convenient little drawers also had to decide how hard to police the traffic around them.

The publication trail matters. The W3C history runs from the 2009 draft to Recommendations in 2013 and 2016. The two-ticket scene survived because it made the design choice legible. A booking is a live window's work. A saved document can outlast the window. A cookie is a message travelling to the server. Give each of those jobs its own address, and the browser stops confusing a comparison with a purchase.