この仕様は、 Web クライアント上において、一連の[名前:値]ペアのデータを保持する,持続的データ­ストレージのための API を規定する。 This specification defines an API for persistent data storage of key-value pair data in Web clients.


この節では、発行時点における… 【 以下、この節の他の内容は W3C 日本語訳 共通ページ に委譲 】

Web Storage の 2013 年 7 月 30 日付 W3C 勧告 が発行されて以降、次の変更がこの仕様に加えられた: The following changes were made to this specification after Web Storage was published as a W3C Recommendation on 30 July 2013:

W3C は、この勧告候補(および将来の勧告案/勧告)に指定される機能性が, DOM4Web IDL が勧告へ向けて変更されたとしても,影響されないものと予期しています。 We expect the functionality specified in this CR (and the future PR/REC) will not be affected by changes to DOM4 or Web IDL as those specifications proceed to Recommendation.


現時点においては、競合状態を避けるためのストレージの排他制御の利用は、一部の実装者からは、性能上の負荷が高過ぎ,むしろデータの破壊を許容した方が好ましいものと見なされている。 すべての UA に対し 生成元ごとのスクリプトのロックを要求することのない,代替案が強く求められている。 この点に関し案があれば、前節に示した宛先まで送られるよう願う。 The use of the storage mutex to avoid race conditions is currently considered by certain implementors to be too high a performance burden, to the point where allowing data corruption is considered preferable. Alternatives that do not require a user-agent-wide per-origin script lock are eagerly sought after. If reviewers have any suggestions, they are urged to send them to the addresses given in the previous section.

この課題についての更なる詳細は次のメール内に見られる( 他にも 多数 ): More details regarding this issue are available in these e-mails (as well as numerous others):

1. 序論

この節は参考である This section is non-normative.

この仕様は、 HTTP セッションクッキー [COOKIES] と類似する,クライアント側に[名前:値]ペアのデータを蓄積するための,関連する2つの仕組みを導入する。 This specification introduces two related mechanisms, similar to HTTP session cookies, for storing name-value pairs on the client side. [COOKIES]

最初のものは、利用者が単独のトランザクションでデータをやりとりする状況を想定して設計されているが、異なるウィンドウ間で並行する複数のトランザクションにも運び得るものでもある。 The first is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.

クッキーは、このケースを上手く扱えない。 例えば、利用者は,同じサイトの2つの異なるウィンドウで飛行機の搭乗券の購入を検討するかもしれない。 サイトが,購入中の搭乗券の情報をクッキーに保持させている場合、利用者が両方のウィンドウでページからページへ閲覧を続けたときに,それらの搭乗券の情報が一方のウィンドウから他方へ “漏れ出す” 結果、同じ便の搭乗券を気付かないうちに重複して購入する羽目に陥り得る。 Cookies don't really handle this case well. For example, a user could be buying plane tickets in two different windows, using the same site. If the site used cookies to keep track of which ticket the user was buying, then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same flight without really noticing.

これを解決するため、この仕様は sessionStorage IDL 属性を導入する。 サイトはセッションストレージにデータを追加でき,同じサイトで開かれているどのページからもアクセス可能になる。 To address this, this specification introduces the sessionStorage IDL attribute. Sites can add data to the session storage, and it will be accessible to any page from the same site opened in that window.

例えば、ページは,利用者が保険を希望する旨を指示するチェックボックスを持ち得る: For example, a page could have a checkbox that the user ticks to indicate that he wants insurance:

   onchange="sessionStorage.insurance = checked ? 'true' : ''"

そのページは後の時点で、利用者がそのチェックボックスにチェックを入れているかどうかを,スクリプトを使って調べられる: A later page could then check, from script, whether the user had checked the checkbox or not:

if (sessionStorage.insurance) { ... }

利用者がそのサイトの複数のウィンドウを開いたときは、それぞれのウィンドウがセッションストレージ­オブジェクトの複製を,自身専属のものとして、持つ。 If the user had multiple windows opened on the site, each one would have its own individual copy of the session storage object.

2つ目のストレージ仕組みは、複数ウィンドウに渡り,複数のセッションに渡って残り続けるストレージのために設計されている。 特に、 ウェブアプリは、性能上の理由から,例えば 利用者により作成された文書全体や利用者のメールボックスなど,数メガ単位の利用者データには クライアント側での保存を要し得る。 The second storage mechanism is designed for storage that spans multiple windows, and lasts beyond the current session. In particular, Web applications may wish to store megabytes of user data, such as entire user-authored documents or a user's mailbox, on the client side for performance reasons.

この場合も、クッキーはリクエストの度に送信されるので,このような用途には適さない。 Again, cookies do not handle this case well, because they are transmitted with every request.

localStorage IDL 属性は、ページのローカルストレージ区域へのアクセスに利用される。 The localStorage IDL attribute is used to access a page's local storage area.

example.com のサイトは、次のようなコードをページの末尾に置くことにより,利用者がページを読み込んだ回数を表示させられる: The site at example.com can display a count of how many times the user has loaded its page by putting the following at the bottom of its page:

  You have viewed this page
  <span id="count">an untold number of</span>
  if (!localStorage.pageLoadCount)
    localStorage.pageLoadCount = 0;
      = parseInt(localStorage.pageLoadCount) + 1;
      = localStorage.pageLoadCount;

それぞれのサイトは個別に専属のストレージ区域を持つ。 Each site has its own separate storage area.

2. 適合性 要件

【 以下、この節の他の内容は W3C 日本語訳 共通ページ に委譲 】

この仕様が定める適合性の対象は UA のみである。 The only conformance class defined by this specification is user agents.

UA は制約の課せられていない入力に実装固有の制限を課してもよい。例えば、 DoS 攻撃の防止, メモリ使い切りに対する保護, プラットフォーム固有の制限の回避など。 User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

特色機能のサポートを不能化する場合(例えばセキュリティの問題を軽減するための急場しのぎとして, あるいは 開発の補助やパフォーマンス上の理由から)、UA はその機能をまったくサポートしていないかのように, かつその機能がこの仕様に存在していなかったかのように,ふるまわなければならない。 例えば、その機能が Web IDL インタフェースの属性を通してアクセスできる場合、その属性そのものを,そのインタフェースを備えるオブジェクトから除外することになる。 その属性をオブジェクトに残しつつ, null を返させる, あるいは例外を投出させるのでは不十分になる。 When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. For example, if a particular feature is accessed via an attribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface — leaving the attribute on the object but making it return null or throw an exception is insufficient.

2.1. 依存性

この仕様は、他のいくつかの下層の仕様に立脚している。 This specification relies on several other underlying specifications.


この仕様には、 HTML から,多くの基本的な概念が流用されている。 [HTML] Many fundamental concepts from HTML are used by this specification. [HTML]


この仕様の IDL ブロックは WebIDL 仕様の定義に従う適合 IDL 片である。 [WEBIDL] The IDL blocks in this specification are conforming IDL fragments as defined by the WebIDL specification. [WEBIDL]

3. 語法

【 この節の内容は W3C 日本語訳 共通ページ に委譲 】

4. API

4.1. Storage インタフェース

interface Storage {
  readonly attribute unsigned long length;
  DOMString? key(unsigned long index);
  getter DOMString? getItem(DOMString key);
  setter creator void setItem(DOMString key, DOMString value);
  deleter void removeItem(DOMString key);
  void clear();

それぞれの Storage オブジェクトは、 key とそれに対応する value の組( “item” とも呼ばれる)からなるリストへのアクセスを提供する。 key は文字列であり、(空文字列も含め)どのような文字列も, key として妥当である。 value も同様に文字列である。 Each Storage object provides access to a list of key/value pairs, which are sometimes called items. Keys are strings. Any string (including the empty string) is a valid key. Values are similarly strings.

それぞれの Storage オブジェクトには、その作成時に, item のリストが結び付けられる(詳細は sessionStorage 属性, および localStorage 属性の節にて規定される)。 Storage インタフェースを実装する複数の別個のオブジェクトすべてに、同時に,同じ item リストが結び付けられ得る。 Each Storage object is associated with a list of key/value pairs when it is created, as defined in the sections on the sessionStorage and localStorage attributes. Multiple separate objects implementing the Storage interface can all be associated with the same list of key/value pairs simultaneously.

【 以下、論の対象の Storage オブジェクトに結び付けられている item のリストを,単に(オブジェクトの) “item リスト” と記す。 】

length 属性の被取得時には、 item リストにその時点で存在している item の総数が返されなければならない。 The length attribute must return the number of key/value pairs currently present in the list associated with the object.

key(n) メソッドは、 item リストの n 番目の item 【 0 番目が最初の item 】 の key を返さなければならない。 【この目的における】 item の順序は, UA 定義とするが、 item の総数が変化しない限り,返される結果はオブジェクトにおいて一定でなければならない(したがって, item の順序は、 追加削除 により変化し得るが、既存の item に対する value の変更に際しては,変更されてはならない)。 n がリスト内の item の総数以上である場合、このメソッドは null を 返さなければならない。 The key(n) method must return the name of the nth key in the list. The order of keys is user-agent defined, but must be consistent within an object so long as the number of keys doesn't change. (Thus, adding or removing a key may change the order of the keys, but merely changing the value of an existing key must not.) If n is greater than or equal to the number of key/value pairs in the object, then this method must return null.

Storage オブジェクトの 被サポート­プロパティ名は、アクセスされた時点でその item リストに存在している item すべての key からなる集合になる。 The supported property names on a Storage object are the keys of each key/value pair currently present in the list associated with the object.

getItem(key) メソッドは、与えられた key を持つ item が item リスト内に存在しない場合は null を, 存在する場合はその item の現在の value を返さなければならない。 The getItem(key) method must return the current value associated with the given key. If the given key does not exist in the list associated with the object then this method must return null.

setItem(key, value) メソッドは、まず始めに,与えられた key を持つ item が item リスト内に存在しているかどうかを確認する。 The setItem(key, value) method must first check if a key/value pair with the given key already exists in the list associated with the object.

存在していない場合、 key, value が与えられた key, value にされた,新たな item が、 item リストに追加されなければならない。 If it does not, then a new key/value pair must be added to the list, with the given key and with its value set to value.

存在している場合、その value が引数の value に[ 等しくないならば,その value を value に更新しなければならない / 等しいならば,このメソッドは何もしてはならない ]。 If the given key does exist in the list, and its value is not equal to value, then it must have its value updated to value. If its previous value is equal to value, then the method must do nothing.

新たな value を設定できなかった場合、このメソッドは QuotaExceededError 例外を投出しなければならない(このような状況は、例えば,利用者がサイトに対するストレージを不能化した場合や, ディスククォータの制限を超過した場合に起こり得る)。 If it couldn't set the new value, the method must throw a QuotaExceededError exception. (Setting could fail if, e.g., the user has disabled storage for the site, or if the quota has been exceeded.)

removeItem(key) メソッドは、与えられた key を持つ item が item リスト内に存在する場合は,それを item リストから除去しなければならない。 他の場合、このメソッドは何もしてはならない。 The removeItem(key) method must cause the key/value pair with the given key to be removed from the list associated with the object, if it exists. If no item with that key exists, the method must do nothing.

setItem() および removeItem() メソッドは、その履行の失敗に関して不可分な操作でなければならない。 失敗する場合、これらのメソッドは何もしない。 すなわち、データ­ストレージ区域に対する変更は成功裡に完了するか, または データ­ストレージ区域は全く変更されないかの,いずれかでなければならない。 The setItem() and removeItem() methods must be atomic with respect to failure. In the case of failure, the method does nothing. That is, changes to the data storage area must either be successful, or the data storage area must not be changed at all.

clear() メソッドは、 item リストが空でないならば,不可分な操作として,それが空になるようにしなければならない。 元々空であった場合、このメソッドは何もしてはならない。 The clear() method must atomically cause the list associated with the object to be emptied of all key/value pairs, if there are any. If there are none, then the method must do nothing.

注記: setItem(), removeItem(), clear() メソッドが呼び出された際には、 【ストレージ区域に変更が生じた場合に限り】 新たに蓄積/除去されたデータにアクセス可能な他の DocumentWindow オブジェクトに向けて,イベントが発火される(詳細は sessionStorage および localStorage 属性の節にて規定される)。 When the setItem(), removeItem(), and clear() methods are invoked, events are fired on the Window objects of other Documents that can access the newly stored or removed data, as defined in the sections on the sessionStorage and localStorage attributes.

注記: この仕様は、上述のメソッドが,データが物理的にディスクに書き込まれるまで待機することを要求しない。 同じ下層の item リストへアクセスする,異なるスクリプト間で、整合性が保たれることのみが要求される。 This specification does not require that the above methods wait until the data has been physically written to disk. Only consistency in what different scripts accessing the same underlying list of key/value pairs see is required.

4.2. sessionStorage 属性

interface WindowSessionStorage {
  readonly attribute Storage sessionStorage;
Window implements WindowSessionStorage;

sessionStorage 属性は、現在のトップレベル閲覧文脈に固有の,ストレージ区域の集合を表現する。 The sessionStorage attribute represents the set of storage areas specific to the current top-level browsing context.

それぞれのトップレベル閲覧文脈は、各生成元ごとに,専属のセッションストレージ区域を割り当てる。 【すなわち,異なる生成元に属するストレージ区域は互いに隔離される。】 Each top-level browsing context has a unique set of session storage areas, one for each origin.

UA は、閲覧文脈のセッションストレージ区域のデータが失効しないようにするべきであるが、次のいずれかの場合は失効させてもよい: (1) 利用者からその種のデータの削除が要請されたとき, または (2) UA がストレージ容量の限界を検知したとき, または (3) セキュリティ上の理由があるとき。 UA は、データにアクセスし得るスクリプトが実行中の間は,データの削除を避けるべきである。 トップレベル閲覧文脈が破壊された際には(したがって,それ以上利用者からアクセスされない)、この仕様に述べる API はそのデータに対する後続の取得手段を提供しないので, UA は セッションストレージ区域に蓄積されているデータを破棄できる。 User agents should not expire data from a browsing context's session storage areas, but may do so when the user requests that such data be deleted, or when the UA detects that it has limited storage space, or for security reasons. User agents should always avoid deleting data while a script that could access that data is running. When a top-level browsing context is destroyed (and therefore permanently inaccessible to the user) the data stored in its session storage areas can be discarded with it, as the API described in this specification provides no way for that data to ever be subsequently retrieved.

注記: UA は,再起動後のセッションの復帰をサポートし得るので、閲覧文脈の存続期間は, UA が実際にその処理を行う期間と必ずしも連動するわけではない。 The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart.

トップレベル閲覧文脈を持つ閲覧文脈において,新たな Document が作成された際には、 UA はまず、そのトップレベル閲覧文脈において,その文書の生成元にセッションストレージ区域が割り当てられているかどうか確認しなければならない。 すでに割り当てられている場合、それが Document にあてがわれるセッションストレージ区域になる。 そうでない場合、文書の生成元に対するストレージ区域が新たに作成された上で,それが Documentにあてがわれるセッションストレージ区域にされなければならない。 Document にあてがわれたストレージ区域は、 Document が存続する限り,変更されない。 When a new Document is created in a browsing context which has a top-level browsing context, the user agent must check to see if that top-level browsing context has a session storage area for that document's origin. If it does, then that is the Document's assigned session storage area. If it does not, a new storage area for that document's origin must be created, and then that is the Document's assigned session storage area. A Document's assigned storage area does not change during the lifetime of a Document.

iframe が他の Document 下に移動された場合、入れ子の閲覧文脈は破壊され,新たなものが作成される。 In the case of an iframe being moved to another Document, the nested browsing context is destroyed and a new one created.

sessionStorage 属性は、[ Document にあてがわれている セッションストレージ区域 ]に結び付けられている Storage オブジェクトがあれば それを, 無ければ null を返さなければならない。 各 Document オブジェクトは、それぞれが別個の,その WindowsessionStorage 属性に対応するオブジェクトを持たなければならない。 The sessionStorage attribute must return a Storage object associated with the Document's assigned session storage area, if any, or null if there isn't one. Each Document object must have a separate object for its Window's sessionStorage attribute.

新たなトップレベル閲覧文脈が,既存の閲覧文脈のクローンにより作成された際には、その新たな閲覧文脈のセッションストレージ区域は,元のそれと同じものから開始されなければならないが、その時点から,この2つは互いに影響を及ぼさないように,別個のものと見なされなければならない。 When a new top-level browsing context is created by cloning an existing browsing context, the new browsing context must start with the same session storage areas as the original, but the two sets must from that point on be considered separate, not affecting each other in any way.

新たなトップレベル閲覧文脈が (1) 既存の閲覧文脈スクリプトにより作成された, または (2) 利用者が既存の閲覧文脈からリンクを辿ることにより作成された, または (3) 特定の Document に関係する何らかの別の方法で作成された ときは、その作成が新たなセッションストレージの開始でないならば、その Document生成元のセッションストレージ区域が,新たな閲覧文脈に複製されなければならない。 しかしながら、その時点から,この2つは互いに影響を及ぼさないように,別個のものと見なされなければならない。 When a new top-level browsing context is created by a script in an existing browsing context, or by the user following a link in an existing browsing context, or in some other way related to a specific Document, and the creation is not a new start for session storage, then the session storage area of the origin of that Document must be copied into the new browsing context when it is created. From that point on, however, the two session storage areas must be considered separate, not affecting each other in any way.

セッションストレージ区域 A に結び付けられている Storage オブジェクト S に対し setItem(), removeItem(), clear() メソッドが呼び出された際には、そのメソッドにおいて[ 例外が投出された, あるいは上述の “何もしてはならない” と規定されている ]ときを除き、次を満たす Document オブジェクトすべてに対し, ストレージ通知を送信する: その Window オブジェクトの sessionStorage 属性が返す Storage オブジェクトが,[ S でない, かつ A に結び付けられている ]。 When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a session storage area, if the methods did not throw an exception or "do nothing" as defined above, then for every Document object whose Window object's sessionStorage attribute's Storage object is associated with the same storage area, other than x, send a storage notification.

4.3. localStorage 属性

interface WindowLocalStorage {
  readonly attribute Storage localStorage;
Window implements WindowLocalStorage;

localStorage オブジェクトは、生成元ごとに Storage オブジェクトを提供する。 The localStorage object provides a Storage object for an origin.

UA は、それぞれの生成元ごとに,専属のローカルストレージ区域をあてがわなければならない。 User agents must have a set of local storage areas, one for each origin.

UA がローカルストレージ区域のデータを失効させるのは、セキュリティ上の理由があるか, または利用者から要請された場合のみに限られるべきである。 UA は、データにアクセスし得るスクリプトが実行中の間は,データの削除を避けるべきである。 User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running.

localStorage 属性にアクセスされた際には、 UA は,以下の Storage オブジェクト初期化 手続き を実行しなければならない。 When the localStorage attribute is accessed, the user agent must run the following steps, which are known as the Storage object initialization steps:

  1. その要請がポリシーの決定に違反している場合(例えば UA の環境設定で,そのページによるデータの持続的な保持は許容しないようにされているときなど)、 Storage オブジェクトを返す代わりに, SecurityError 例外を投出して,この手続きを中止してもよい。 The user agent may throw a SecurityError exception and abort these steps instead of returning a Storage object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data).

  2. Document生成元が scheme/host/port の三つ組みでない場合、 SecurityError 例外を投出して,この手続きを中止する。 If the Document's origin is not a scheme/host/port tuple, then throw a SecurityError exception and abort these steps.

  3. 属性がアクセスされている Window オブジェクトの Document生成元に対し,ローカルストレージ区域が割り当てられているかどうか確認する。 割り当てられていない場合、新たなストレージ区域を作成して,その生成元に対し割り当てる。 Check to see if the user agent has allocated a local storage area for the origin of the Document of the Window object on which the attribute was accessed. If it has not, create a new storage area for that origin.

  4. 生成元に割り当てられているローカルストレージ区域に結び付けられている Storage オブジェクトを返す。 各 Document オブジェクトは、それぞれが別個の, その WindowlocalStorage 属性に対応するオブジェクトを持たなければならない。 Return the Storage object associated with that origin's local storage area. Each Document object must have a separate object for its Window's localStorage attribute.

ローカルストレージ区域 A に結び付けられている Storage オブジェクト S に対し setItem(), removeItem(), clear() メソッドが呼び出された際には、そのメソッドにおいて[ 例外が投出された, あるいは上述の “何もしてはならない” と規定されている ]ときを除き、次を満たす Document オブジェクトすべてに対し,ストレージ通知を送信する: その Window オブジェクトの sessionStorage 属性が返す Storage オブジェクトが,[ S でない, かつ A に結び付けられている ]。 When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did not throw an exception or "do nothing" as defined above, then for every Document object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, send a storage notification.

Storage オブジェクトの localStorage 属性のプロパティが [ プロパティの有無の確認, プロパティの列挙, プロパティの総数の確認, など,直接的なプロパティ­アクセスの一環として], あるいは[ Storage インタフェースのいずれかのメソッドや属性に対するアクセスの実行の一環として ]、調査/取得/設定/削除される際は常に、 UA はまず,ストレージの排他制御を取得しなければならない。 Whenever the properties of a localStorage attribute's Storage object are to be examined, returned, set, or deleted, whether as part of a direct property access, when checking for the presence of a property, during property enumeration, when determining the number of properties present, or as part of the execution of any of the methods or attributes defined on the Storage interface, the user agent must first obtain the storage mutex.

4.4. storage イベント

前の2つの節( セッションストレージ節, ローカルストレージ節 )に述べたように,ストレージ区域に変更が加えられた際には、 DocumentWindow オブジェクトに向けて, storage イベントが発火される。 The storage event is fired on a Document's Window object when a storage area changes, as described in the previous two sections (for session storage, for local storage).

UA が,対象の Document に対し ストレージ通知を送信 するときは、[[ 名前 storage の, 浮上せず, 取消不可の, StorageEvent インタフェースを利用する trusted イベント ]を,[ Document オブジェクトの Window オブジェクト ]に向けて発火するタスク ]を,待ち行列に入れなければならない。 When a user agent is to send a storage notification for a Document, the user agent must queue a task to fire a trusted event with the name storage, which does not bubble and is not cancelable, and which uses the StorageEvent interface, at the Document object's Window object.

注記: その種の Document オブジェクトが fully active になっている必要はないが、その種のオブジェクトに向けて発火されるイベントは,その Document が再び fully active になるまでは、イベントループからは無視される。 Such a Document object is not necessarily fully active, but events fired on such objects are ignored by the event loop until the Document becomes fully active again.

これらのタスクに対するタスクソースは、 DOM 操作タスクソースである。 The task source for these tasks is the DOM manipulation task source.

setItem()removeItem() メソッドの呼び出しに応じてイベントが発火される場合、そのイベントの各種 属性が,次のように初期化されなければならない:

  • key 属性 ← 当該 item の key
  • oldValue 属性 ← [ 当該 item が setItem() により新たに追加されたものならば null / 他の場合は 当該 item の元の value ]
  • newValue 属性 ← [ setItem() の場合は 当該 item の新たな value / removeItem() の場合は null ]

If the event is being fired due to an invocation of the setItem() or removeItem() methods, the event must have its key attribute initialised to the name of the key in question, its oldValue attribute initialised to the old value of the key in question, or null if the key is newly added, and its newValue attribute initialised to the new value of the key in question, or null if the key was removed.

clear() メソッドの呼び出しに応じてイベントが発火される場合、そのイベントの各種 属性が,次のように初期化されなければならない:

Otherwise, if the event is being fired due to an invocation of the clear() method, the event must have its key, oldValue, and newValue attributes initialised to null.

In addition, the event must have its url attribute initialised to the address of the document whose Storage object was affected; and its storageArea attribute initialised to the Storage object from the Window object of the target Document that represents the same kind of Storage area as was affected (i.e. session or local).

【 多数の変更が加えられた場合、相応する個数のイベントが配送されることになるが(ただし, clear() に対しては1個になると見られる)、例えば同じ item の値が複数回更新された場合に1個のイベントに集約されることは,あるかもしれない。 】

4.4.1. StorageEvent インタフェース

[Constructor(DOMString type, optional StorageEventInit eventInitDict)]
interface StorageEvent : Event {
  readonly attribute DOMString? key;
  readonly attribute DOMString? oldValue;
  readonly attribute DOMString? newValue;
  readonly attribute DOMString url;
  readonly attribute Storage? storageArea;

dictionary StorageEventInit : EventInit {
  DOMString? key;
  DOMString? oldValue;
  DOMString? newValue;
  DOMString url;
  Storage? storageArea;

key 属性は、初期化時の値†を返さなければならない。 オブジェクトの作成時には、この属性は null に初期化されなければならない。 これは変更された item の key を表現する。 【† 共通の慣用表現 参照 The key attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to null. It represents the key being changed.

oldValue 属性は、初期化時の値を返さなければならない。 オブジェクトの作成時には、この属性は null に初期化されなければならない。 これは変更された item の前の value を表現する。 The oldValue attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to null. It represents the old value of the key being changed.

newValue 属性は、初期化時の値を返さなければならない。 オブジェクトの作成時には、この属性は null に初期化されなければならない。 これは変更された item の新たな value を表現する。 The newValue attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to null. It represents the new value of the key being changed.

url 属性は、初期化時の値を返さなければならない。 オブジェクトの作成時には、この属性は空文字列に初期化されなければならない。 これは変更された item を持つ storage が属する文書のアドレスを表現する。 The url attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to the empty string. It represents the address of the document whose key changed.

storageArea 属性は、初期化時の値を返さなければならない。 オブジェクトの作成時には、この属性は null に初期化されなければならない。 これは、変更が加えられた Storage オブジェクトを表現する。 The storageArea attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to null. It represents the Storage object that was affected.

4.5. スレッド

ストレージの排他制御利用により、スクリプトが他のスクリプトの並列実行を検知し得なくとも,複数の閲覧文脈から同時にローカルストレージ区域にアクセスできるようになる。 Because of the use of the storage mutex, multiple browsing contexts will be able to access the local storage areas simultaneously in such a manner that scripts cannot detect any concurrent script execution.

従って,スクリプトの実行中は、 Storage オブジェクトの length 属性, および そのオブジェクトの種々のプロパティの値が,スクリプト自身から予期し得ない方法で変更されることはない。 Thus, the length attribute of a Storage object, and the value of the various properties of that object, cannot change while a script is executing, other than in a way that is predictable by the script itself.

5. ディスク容量

UA は、ストレージ区域に許容される総量を制限するべきである。 さもなければ、敵対的­作者が,この特色機能を利用して 利用者のディスク容量を枯渇させることが可能になるので。 User agents should limit the total amount of space allowed for storage areas, because hostile authors could otherwise use this feature to exhaust the user's available disk space.

UA は、サイトが,その生成元の他の提携サイトの下でデータを蓄積することからも,利用者を保護するべきである。 さもなければ、例えば a1.example.com, a2.example.com, a3.example.com, 等々 に許容される限界までデータを蓄積することにより,メインの example.com のストレージ制限を迂回することが可能になるので。 User agents should guard against sites storing data under their origin's other affiliated sites, e.g. storing up to the limit in a1.example.com, a2.example.com, a3.example.com, etc, circumventing the main example.com storage limit.

UA は、ディスククォータの限界に到達した際に、利用者がより多くの容量をサイトにあてがうことを許可できるようにするため、利用者に通知してもよい。 これにより,サイトは、例えば,利用者が作成した多数の文書データを,利用者のコンピュータ上に蓄積できるようになる。 User agents may prompt the user when quotas are reached, allowing the user to grant a site more space. This enables sites to store many user-created documents on the user's computer, for instance.

UA は、それぞれのドメインが占めている容量を,利用者が閲覧できるようにするべきである。 User agents should allow users to see how much space each domain is using.

生成元ごとに,ほぼ一律に 5 メガバイト程度を上限にすることが勧められる。 実装からのフィードバックを歓迎する。 その際には,この案は将来的に更新されることになる。 A mostly arbitrary limit of five megabytes per origin is suggested. Implementation feedback is welcome and will be used to update this suggestion in the future.

予測可能性のため,ディスククォータは格納データの無圧縮状態のサイズに基づくべきである。 For predictability, quotas should be based on the uncompressed size of data stored.

6. プライバシー

6.1. 利用者の追跡

第三者主体の広告主(あるいは,複数のサイトに内容を流布し得る任意の主体)は、利用者の関心プロファイルを構築し,より高度な絞り込み広告を可能にする目的で、ローカルストレージ区域に一意的な識別子を蓄積することにより,複数のセッションに渡って利用者を追跡し得る。 利用者の実際の身元を知っているサイト(例えば認証を要する電子商取引サイト)と連携した場合、不当な団体が,匿名 Web 利用よりも高い精度で個人を標的にすることも許容されてしまう。 A third-party advertiser (or any entity capable of getting content distributed to multiple sites) could use a unique identifier stored in its local storage area to track a user across multiple sessions, building a profile of the user's interests to allow for highly targeted advertising. In conjunction with a site that is aware of the user's real identity (for example an e-commerce site that requires authenticated credentials), this could allow oppressive groups to target individuals with greater accuracy than in a world with purely anonymous Web usage.

利用者の追跡のリスクを軽減するために利用し得る、いくつもの技法がある: There are a number of techniques that can be used to mitigate the risk of user tracking:

第三者主体によるストレージ利用を遮断 Blocking third-party storage

UA は localStorage オブジェクトへのアクセスを,閲覧文脈のトップレベル文書のドメイン由来のスクリプトに制約してもよい。 例えば、 iframe の中で実行中の 他のドメインからのページに対しては、 API へのアクセスを許可しないなど。 User agents may restrict access to the localStorage objects to scripts originating at the domain of the top-level document of the browsing context, for instance denying access to the API for pages from other domains running in iframes.

蓄積データを失効させる Expiring stored data

UA は、場合によっては,利用者の設定に従う形で,一定期間が経過した蓄積データは自動的に削除されるようにしてもよい。 User agents may, possibly in a manner configured by the user, automatically delete stored data after a period of time.

例えば UA は、その環境設定にて、第三者主体によるローカルストレージ区域をセッション用途のみと見なし,利用者がそれへアクセスし得るすべての閲覧文脈を閉じた時点で,データが削除されるようにも、設定し得る。 For example, a user agent could be configured to treat third-party local storage areas as session-only storage, deleting the data once the user had closed all the browsing contexts that could access it.

これにより、サイトが複数のセッションに渡って利用者を追跡できるのは,サイト自身により認証が行われる場合(例えばサービスの購入やログインなど)に限られることになるため、サイトが利用者を追跡する能力を制約し得るものになる。 This can restrict the ability of a site to track a user, as the site would then only be able to track the user across multiple sessions when he authenticates with the site itself (e.g. by making a purchase or logging in to a service).

しかしながら これは、持続的ストレージの仕組みから得られる API の有用性も制約する。 それはまた、利用者がデータの失効がもたらす影響について十分理解していない場合に、利用者のデータをリスクにさらすことになる。 However, this also reduces the usefulness of the API as a long-term storage mechanism. It can also put the user's data at risk, if the user does not fully understand the implications of data expiration.

持続的ストレージをクッキー同様に扱う Treating persistent storage as cookies

利用者がローカルストレージ区域に蓄積されているデータは残しつつ,クッキーをクリアすることで自身のプライバシー保護を行う試みに対しては、サイト側は,両者の特色機能を利用して相互に冗長バックアップすることで、迂回し得る。 UA は、利用者に,この可能性について理解することを支援し、持続的ストレージを供するすべての特色機能について,同時にデータを削除し得るような、インタフェースを備えるべきである。 [COOKIES] If users attempt to protect their privacy by clearing cookies without also clearing data stored in the local storage area, sites can defeat those attempts by using the two features as redundant backup for each other. User agents should present the interfaces for clearing these in a way that helps users to understand this possibility and enables them to delete data in all persistent storage features simultaneously. [COOKIES]

ローカルストレージ アクセスのためのサイト別 許可リスト Site-specific white-listing of access to local storage areas

UA は、サイトによるセッションストレージ区域へのアクセスは制約しない一方で,ローカルストレージ区域へのアクセスについては 利用者からの許可を要するようにしてもよい。 User agents may allow sites to access session storage areas in an unrestricted manner, but require the user to authorise access to local storage areas.

蓄積データからの生成元の追跡 Origin-tracking of stored data

UA は、データの蓄積を生じさせた第三者主体の生成元からの内容を含んでいるサイトの生成元を記録してよい。 User agents may record the origins of sites that contained content from third-party origins that caused data to be stored.

この情報を 持続的ストレージに存在するデータの表示に利用すれば、利用者が持続的ストレージのどの部分を取り除くかを判断する際の材料になる。 ブラックリストとの併用により( “このデータを削除して、このドメインが再びデータを蓄積しないようにする” 等)、利用者は,持続的ストレージの利用を信用できるサイトのみに制約できるようになる。 If this information is then used to present the view of data currently in persistent storage, it would allow the user to make informed decisions about which parts of the persistent storage to prune. Combined with a blacklist ("delete this data and prevent this domain from ever storing data again"), the user can restrict the use of persistent storage to sites that he trusts.

ブラックリストの共有 Shared blacklists

UA は、利用者間で持続的ストレージに関するドメインのブラックリストを共有できるようにしてもよい。 User agents may allow users to share their persistent storage domain blacklists.

これにより、コミュニティはプライバシー保護に向けて協同できるようになる。 This would allow communities to act together to protect their privacy.

これらの提案は、利用者の追跡のための,この API の自明な利用は防止するが、総体的な形では遮断しない。 サイトは、単独のドメイン内ではセッションに渡って利用者を追跡し続けられ,その情報をサイトが取得した個人識別情報(名前, カード番号, 住所など)と伴に第三者主体に渡すことは可能である。 第三者主体がその種の情報を得るために複数のサイトにおいて協調すれば、依然として,プロファイルは作成され得る。 While these suggestions prevent trivial use of this API for user tracking, they do not block it altogether. Within a single domain, a site can continue to track the user during a session, and can then pass all this information to the third party along with any identifying information (names, credit card numbers, addresses) obtained by the site. If a third party cooperates with multiple sites to obtain such information, a profile can still be created.

しかしながら、利用者の追跡は,UA とのいかなる協調さえなくとも、例えば、 URL にセッション識別子を埋め込むことにより,ある範囲において(過去に遡ってすら)可能である。 これは、害の無い目的で,すでに広く利用されてはいるが、利用者の追跡に容易に転用し得る技法でもある。 この情報は、訪問者の IP アドレスその他の,利用者­固有のデータ(例えば User-Agent ヘッダや環境設定など)を利用して,個別のセッションを組み合わせ、一貫性を備えた利用者プロファイルに仕立て上げることにより、他サイトと共有し得るものになる。 However, user tracking is to some extent possible even with no cooperation from the user agent whatsoever, for instance by using session identifiers in URLs, a technique already commonly used for innocuous purposes but easily repurposed for user tracking (even retroactively). This information can then be shared with other sites, using visitors' IP addresses and other user-specific data (e.g. user-agent headers and configuration settings) to combine separate sessions into coherent user profiles.

6.2. データの取り扱い

UA は、持続的に蓄積されたデータを,潜在的にセンシティブなものと見なすべきである。 メール, 予定表, 診断記録, その他の秘匿文書が,この仕組みを通して蓄積されることは、ごく普通にあり得る。 User agents should treat persistently stored data as potentially sensitive; it's quite possible for e-mails, calendar appointments, health records, or other confidential documents to be stored in this mechanism.

最後に、 UA は,データを削除する際には、必ず,下層のストレージからも即時に削除されるようにすべきである。 To this end, user agents should ensure that when deleting data, it is promptly deleted from the underlying storage.

7. セキュリティ

7.1. DNS 偽装攻撃

DNS 偽装攻撃の下では、一定のドメインに属すると主張するホストが本当にそのドメインからのものであるかどうか,確証が得られなくなる可能性がある。 TLS を利用して,これを軽減することができる。 TLS を利用するページは、[ 利用者, 利用者を代理するソフトウェア, [ TLS を利用し, 同じドメインに属していることを証明する証明書を持つ,他のページ ]]のみが,それらのストレージ区域にアクセス可能であることの、確証を得られる。 Because of the potential for DNS spoofing attacks, one cannot guarantee that a host claiming to be in a certain domain really is from that domain. To mitigate this, pages can use TLS. Pages using TLS can be sure that only the user, software working on behalf of the user, and other pages using TLS that have certificates identifying them as being from the same domain, can access their storage areas.

7.2. クロスディレクトリ攻撃

同じホスト名を共有している作者たちは(例えば geocities.com で内容をホストしている作者たちなど)、全員が1個のローカルストレージ­オブジェクトを共有することになる。 パス名によりアクセスを制約する特色機能はないので、彼らのうち誰もが他の作者のデータを読み取ったり, 上書きすることが可能になる。 したがって、共有されているホストを利用している作者には,これらの特色機能の利用を避けるよう勧める。 Different authors sharing one host name, for example users hosting content on geocities.com, all share one local storage object. There is no feature to restrict the access by pathname. Authors on shared hosts are therefore urged to avoid using these features, as it would be trivial for other authors to read the data and overwrite it.

注記: 仮にパス制約の特色機能が利用できたとしても、通常の DOM スクリプティング セキュリティ­モデルから、この保護を迂回して,任意のパスからのデータへアクセスすることは自明になる。 Even if a path-restriction feature was made available, the usual DOM scripting security model would make it trivial to bypass this protection and access the data from any path.

7.3. 実装にあたって考慮すべきリスク

これらの持続的なストレージ特色機能を実装するにあたっては、2つの主要なリスクがある: (1) 敵対的サイトによる他のドメインの情報の読み取り (2) 敵対的サイトによる情報の書き込み後の他サイトからの情報の読み取り 。 The two primary risks when implementing these persistent storage features are letting hostile sites read information from other domains, and letting hostile sites write information that is then read from other domains.

第三者主体サイトのドメインからの読み取りが予期されていないようなデータに,そのような読み取りを許した場合、情報漏洩になる。 例えば、あるドメインの利用者の購入希望リストは,他のドメインによる絞り込み広告に利用され得る。 あるいは文書作成サイトにより蓄積された,利用者の作業中の秘匿文書が競合する企業のサイトに読まれてしまうなど。 Letting third-party sites read data that is not supposed to be read from their domain causes information leakage, for example, a user's shopping wishlist on one domain could be used by another domain for targeted advertising; or a user's work-in-progress confidential documents stored by a word-processing site could be examined by the site of a competing company.

第三者主体サイトによる,他のドメインの持続的ストレージへのデータの書き込みを許した場合、同等に危険な,情報なりすましが生じる。 例えば、敵対的サイトが利用者の購入希望リストに “item” を付け加えるなど。 あるいは、敵対的サイトにより利用者のセッション識別子が既知の ID に設定された場合,その ID は被害者サイトにおける利用者の追跡に利用され得る。 Letting third-party sites write data to the persistent storage of other domains can result in information spoofing, which is equally dangerous. For example, a hostile site could add items to a user's wishlist; or a hostile site could set a user's session identifier to a known ID that the hostile site can then use to track the user's actions on the victim site.

従って、この仕様に述べた生成元モデルを厳格に守ることは、利用者のセキュリティにとり,重要になる。 Thus, strictly following the origin model described in this specification is important for user security.


“参考” と記されていない文献はすべて規定である。 All references are normative unless marked "Non-normative".

HTTP State Management Mechanism, A. Barth. IETF.
Anne van Kesteren; Aryeh Gregor; Ms2ger; Alex Russell; Robin Berjon. W3C DOM4. 10 July 2014. W3C Last Call Working Draft. URL: http://www.w3.org/TR/dom/
ECMAScript Language Specification. ECMA.
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 28 October 2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF.
Cameron McCormack. Web IDL. 19 April 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/WebIDL/


全部的な一覧は HTML 仕様を参照されたし。 [HTML] For a full list of acknowledgements, please see the HTML specification. [HTML]