Web Storage

HTML Living Standard — 最終更新 2016 年 11 月 28 日

11. Web Storage

11.1. 序論

~INFORMATIVE

この仕様は、 HTTP ~session~cookie `COOKIES$r と類似する,~client側に ( 名前, 値 ) の組たちを格納するための,関係する2つの仕組みを導入する。 ◎ This specification introduces two related mechanisms, similar to HTTP session cookies, for storing name-value pairs on the client side. [COOKIES]

最初の仕組みは、利用者が単独の~transactionで~dataをやりとりする局面を~~想定して設計されているが、異なる~window間で並行する複数の~transactionにも運び得る。 ◎ 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.

~cookieは、この事例を上手く取り扱えない。 例えば、利用者は,同じ~siteの2つの異なる~windowで航空機の搭乗券の購入を検討するかもしれない。 ~siteが,購入中の搭乗券の情報を~cookieに保ち続けている場合、利用者が両方の~windowで~pageから~pageへ~~閲覧を続けたときに,それらの搭乗券の情報が一方の~windowから他方へ “漏れ出す” 結果、同じ便の搭乗券を気付かないうちに重複して購入する羽目に陥り得る。 ◎ 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$m IDL 属性を導入する。 ~siteは~session~storageに~dataを追加でき,同じ~siteで開かれているどの~pageからも~access可能になる。 ◎ 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.

例えば、~pageは,利用者が保険を希望する旨を指示する~checkboxを持ち得る: ◎ For example, a page could have a checkbox that the user ticks to indicate that they want insurance:

<label>
 <input
   type="checkbox"
   onchange="sessionStorage.insurance = checked ? 'true' : ''"
 >
 
この旅行に保険を掛ける
◎
I want insurance on this trip.

</label>

その~pageは後の時点で、利用者がその~checkboxに~checkを入れているかどうかを,~scriptを使って調べられる: ◎ A later page could then check, from script, whether the user had checked the checkbox or not:

if (sessionStorage.insurance) { ... }

利用者がその~siteの複数の~windowを開いたとき、それぞれの~windowは,自前の~session~storage~objの複製を持つ。 ◎ If the user had multiple windows opened on the site, each one would have its own individual copy of the session storage object.

~storageの二番目の仕組みは、複数~windowに渡り,複数の~sessionに渡って残り続ける~storageのために設計されている。 特に、 ~web-appは、処理能の理由から,例えば 利用者により作成された文書~全体や利用者の~mailboxなど,~megabyte~~単位の利用者~dataには ~client側での保存を要し得る。 ◎ 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.

この場合も、~cookieは要請の度に伝送されるので,このような用途には適さない。 ◎ Again, cookies do not handle this case well, because they are transmitted with every request.

`localStorage$m IDL 属性は、~pageの~local~storage区画への~accessに利用される。 ◎ The localStorage IDL attribute is used to access a page's local storage area.

`example.com^s の~siteは、~pageの末尾に次のような~codeを置くことにより,利用者が~pageを読込んだ回数を表示させられる: ◎ 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:

<p>
  あなたがこのページを見たのは
  <span id="count">〜</span>回目です。
</p>
<script>
  if (!localStorage.pageLoadCount)
    localStorage.pageLoadCount = 0;
  localStorage.pageLoadCount
      = parseInt(localStorage.pageLoadCount) + 1;
  document.getElementById('count').textContent
      = localStorage.pageLoadCount;
</script>

各~siteには,それぞれに自前の~storage区画があてがわれる。 ◎ Each site has its own separate storage area.

【この訳に固有の表記規約】

この訳の,~algoや定義の記述に利用されている各種記号( ~LET, ~IF, ~THROW, 等々)の意味や定義の詳細は、~SYMBOL_DEF_REFを~~参照されたし。

この訳では:

  • `Document$I ~objを単に `文書@ と略記する。
  • `Window$I ~objを単に `~window@ と略記する。

11.2. API

11.2.1. `Storage^I ~interface

⇒! interface `Storage@I { readonly attribute unsigned long `length$m; DOMString? key(unsigned long %index); getter DOMString? `getItem$m(DOMString %key); setter void `setItem$m(DOMString %key, DOMString %value); deleter void `removeItem$m(DOMString %key); void `clear$m(); }; ◎

各 `Storage$I ~objは、いくつかの[ `~item@ とも呼ばれる,[ `~key@ とそれに対応する `~value@ ]の組 ]からなる~listへの~accessを提供する。 `~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$I ~objには、その作成-時に,`~item$の~list — 以下、 `~item~list@ と記す — が結付けられる(詳細は `sessionStorage$m 属性, `localStorage$m 属性 各~節にて規定される)。 `Storage$I ~interfaceを実装する複数の別個の~objすべてに、同時に,同じ`~item~list$が結付けられ得る。 ◎ 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.

`length@m
被取得時には、その時点で`~item~list$内に在する`~item$数を返さ~MUST。 ◎ The length attribute must return the number of key/value pairs currently present in the list associated with the object.
`key(n)@m

被呼出時には、次を走らせ~MUST:

  1. ~IF[ %n ~GTE ~list内の`~item$の総数 ] ⇒ ~RET ~NULL
  2. ~RET `~item~list$の %n 番の~itemの`~key$ ` 0 番が最初の~item^tnote

`この目的における^tnote `~item$の順序は,~UAにより定義されるが、`~item$の総数が変化しない限り,返される結果は~objにおいて一定で~MUST(したがって,`~item$の順序は、 追加除去 により変化し得るが、既存の`~item$に対する`~value$の変更により変化しては~MUST_NOT)。

◎ 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$I ~objの`被~support~property名たち$は、次で与えられる`有順序^tnote 集合として定義される:

  • ~accessされた時点で,その`~item~list$内に在する`~item$すべての`~key$からなる。
  • 順序は、当の~storage区画に`~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, in the order that the keys were last added to the storage area.
`getItem(key)@m
被呼出時には、`~item~list$内に[ `~key$ ~EQ %key ]なる`~item$が[ 存在するならば その`~item$の現在の`~value$ / 存在しないならば ~NULL ]を返さ~MUST。 ◎ 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)@m

被呼出時には、次を走らせ~MUST: ◎ 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.

  1. %item ~LET `~item~list$内の[ `~key$ ~EQ %key ]なる`~item$ ◎ ↓
  2. ~IF[ %item は存在しない ] ⇒ 次のようにされた新たな`~item$を`~item~list$に追加する ⇒ ( `~key$, `~value$ ) ~SET ( %key, %value ) ◎ 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.
  3. ~ELIF[ %item の`~value$ ~NEQ %value ] ⇒ %item の`~value$ ~SET %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.
  4. ~ELSE ⇒ 何もしては~MUST_NOT `下の注記を見よ^tnote ◎ ↑
新たな`~value$を設定できなかった場合、この~methodは `QuotaExceededError$E 例外を投出し~MUST(そのような状況は、例えば,利用者が~siteに対する~storageを不能化した場合や, ~quata~~上限を超過した場合に起こり得る)。 ◎ If it couldn't set the new value, the method must throw a "QuotaExceededError" DOMException exception. (Setting could fail if, e.g., the user has disabled storage for the site, or if the quota has been exceeded.)
`removeItem(key)@m
被呼出時には ⇒ `~item~list$内に[ `~key$ ~EQ %key ]なる`~item$が存在するならば,それを`~item~list$から除去し~MUST — 存在しない場合、何もしては~MUST_NOT `下の注記を見よ^tnote 。 ◎ 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. ◎ ↓↓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()@m
被呼出時には、`~item~list$が空でないならば,それを空にし~MUST — 元々空であった場合、何もしては~MUST_NOT `下の注記を見よ^tnote 。 ◎ 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()$m / `removeItem()$m / `clear()$m ]~methodは ⇒ その履行の失敗に関して不可分な~~操作で~MUST。 失敗する場合、これらの~methodは何もしない。 すなわち、~data~storage区画に対する変更は成功裡に完了するか, または ~data~storage区画は全く変更されないかの,いずれかで~MUST。 ◎ ↑↑

注記: [ `setItem()$m / `removeItem()$m / `clear()$m ]~methodが呼出されたときは、 `~storage区画に変更が加えられた場合に限り^tnote 新たに格納-/除去された~dataに~access可能な他の`文書$の`~window$に向けて,~eventが発火される(詳細は[ `sessionStorage$m / `localStorage$m ]属性の節にて規定される)。 ◎ 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.

注記: この仕様は、上述の~methodが,~dataが物理的に~diskに書込まれるまで待機することを要求しない。 同じ下層の`~item~list$へ~accessする 異なる~script間で、整合性が保たれることのみが要求される。 ◎ 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.

11.2.2. `sessionStorage^m 属性

⇒! [NoInterfaceObject] interface `WindowSessionStorage@I { readonly attribute `Storage$I `sessionStorage$m; }; `Window$I implements `WindowSessionStorage$I; ◎

`sessionStorage@m 属性は、現在の`~top-level閲覧文脈$特有の,~storage区画の集合を表現する。 ◎ The sessionStorage attribute represents the set of storage areas specific to the current top-level browsing context.

それぞれの`~top-level閲覧文脈$は、各`生成元$ごとに,別々の~session~storage区画をあてがう。 ◎ Each top-level browsing context has a unique set of session storage areas, one for each origin.

~UAは、閲覧文脈の~session~storage区画の~dataが失効しないようにするべきであるが、次のいずれかの場合は失効させてもよい:

  • 利用者からその種の~dataを削除するよう要請されたとき。
  • ~UAが~storage容量の限界を検知したとき。
  • ~security上の理由があるとき。

~UAは、また~session~storage区画に格納されている~dataに対し:

  • ~dataに~accessし得る~scriptを走らせている間は,失効させないべきである。
  • `~top-level閲覧文脈$が破壊されたときは(したがって,それ以上~利用者から~accessされない),破棄できる — この仕様に述べる API は,当の~dataに対する後続の取得手段を提供しないので。
◎ 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は,再起動~後の~sessionの復帰を~supportし得るので、閲覧文脈の存続期間と, ~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.

~UAは、新たな`文書$ %文書 を作成したときは、 %文書 が属する`閲覧文脈$の `~top-level閲覧文脈$ %T があるならば,次で与えられる~session~storage区画を %文書 にあてがわ~MUST:

  • %T が[ %文書 の`生成元$ %O ]に対する~session~storage区画をすでに有しているならば、それ。
  • 他の場合、 %O に対する新たな~storage区画を作成した結果。

%文書 が存続する限り、 %文書 に他の~storage区画があてがわれることはない。

◎ 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$e が他の`文書$下に移動された場合、 `iframe$e を通して入子にされている閲覧文脈は破壊され,新たなものが作成される。 ◎ In the case of an iframe being moved to another Document, the nested browsing context is destroyed and a new one created.

`sessionStorage$m 属性の被取得時には、[ `文書$にあてがわれている ~session~storage区画 ]に属する `Storage$I ~objがあれば それ / 無ければ ~NULL ]を返さ~MUST。 各 `文書$は、それぞれが別個の,その`~window$の `sessionStorage$m 属性に対応する~objを持た~MUST。 ◎ 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.

新たな`~top-level閲覧文脈$ %T が作成されたときは:

  • %T は,既存の`閲覧文脈$を~cloneして作成されたならば ⇒ %T の~session~storage区画は,元のそれと同じものから開始され~MUSTが、その時点から,この2つは互いに影響しないように,別個のものと見なされ~MUST。 ◎ 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.
  • %T は,次のいずれかにより作成されたならば…:

    • 既存の`閲覧文脈$の`~script$により, または
    • 利用者が既存の閲覧文脈から~linkを追うことにより, または
    • 特定の`文書$に関係する何らかの別の方法で

    …ならば ⇒ その作成が新たな~session~storageの開始でないならば、その`文書$の`生成元$に属する~session~storage区画が, %T に複製され~MUST。 しかしながら,その時点から、この2つの区画は互いに影響しないように,別個のものと見なされ~MUST。

    ◎ 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.

~session~storage区画 %A に属する `Storage$I ~obj %S に対し[ `setItem()$m / `removeItem()$m / `clear()$m ]~methodが呼出されたときは、その~methodにおいて[ 例外が投出された, あるいは上述の “何もしては~MUST_NOT” と規定されている ]ときを除き ⇒ 次を満たすような各 `文書$ %文書 に対し,`~storage通知を送信する$ ⇒ [[ %文書 の`~window$の `sessionStorage$m 属性 ]が返す `Storage$I ~obj ]は、[ %A に属する, かつ %S でない ] ◎ 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.

11.2.3. `localStorage^m 属性

⇒! [NoInterfaceObject] interface `WindowLocalStorage@I { readonly attribute `Storage$I `localStorage$m; }; `Window$I implements `WindowLocalStorage$I; ◎

`localStorage@m ~objは、`生成元$ごとに `Storage$I ~objを提供する。 ~FINGERPRINTING ◎ The localStorage object provides a Storage object for an origin. ◎ (This is a fingerprinting vector.)

~UAは、それぞれの`生成元$ごとに,専属の~local~storage区画をあてがわ~MUST。 ◎ User agents must have a set of local storage areas, one for each origin.

~UAが~local~storage区画の~dataを失効させるのは、~security上の理由があるか, または利用者から要請された場合に限られるべきである。 ~UAは、~dataに~accessし得る~scriptが走らせている間は,~dataを失効させないべきである。 ◎ 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$m 属性に~accessされた際には、~UAは,以下に与える `Storage^I ~objの初期化~手続き を走らせ~MUST: ◎ 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の任意選択で ⇒ ~IF[ その要請は施策決定に違反している(例えば~UAの環境設定により,その~pageでは~dataの持続-は許容されていないなど) ] ⇒ ~THROW `SecurityError$E ◎ The user agent may throw a "SecurityError" DOMException and abort these steps instead of returning a Storage object if the request violates a policy decisions (e.g. if the user agent is configured to not allow the page to persist data).
  2. %O ~LET 属性が~accessされている`~window$の`文書$の`生成元$ ◎ ↓
  3. ~IF[ %O は`不透明な生成元$である ] ⇒ ~THROW `SecurityError$E ◎ If the Document's origin is an opaque origin, then throw a "SecurityError" DOMException and abort these steps.
  4. ~IF[ %O には,~local~storage区画はあてがわれていない ] ⇒ 新たな~storage区画を作成した上で,それを %O にあてがう。 ◎ 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.
  5. ~RET [ %O にあてがわれている~local~storage区画 ]に属する `Storage$I ~obj — 各 `文書$は、それぞれが別個の,その`~window$の `localStorage$m 属性に対応する `Storage$I ~objを持た~MUST。 ◎ 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.

~local~storage区画 %A に属する `Storage$I ~obj %S に対し[ `setItem()$m / `removeItem()$m / `clear()$m ]~methodが呼出されたときは、その~methodにおいて[ 例外が投出された, あるいは上述の “何もしては~MUST_NOT” と規定されている ]ときを除き ⇒ 次を満たすような各 `文書$ %文書 に対し,`~storage通知を送信する$ ⇒ [[ %文書 の`~window$の `sessionStorage$m 属性 ]が返す `Storage$I ~obj ]は、[ %A に属する, かつ %S でない ]。 ◎ 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.

`localStorage$m 属性は、共有されている状態への~accessを提供する。 この仕様は、複数の閲覧文脈を同時に処理する~UAにおける,閲覧文脈~間の相互作用は定義しない。 よって,作者には、~lockする類の仕組みはないものと見做すことが奨励される。 例えばある~siteが、`~key$に対する`~value$を読取って, それを~~変更した結果の新たな`~value$を,当の~sessionに対する一意な識別子として書戻すとするとき、これが異なる二つの~browser~windowで同時に行われた場合、両~sessionに対し同じ “一意な” 識別子を利用する結果,破壊的な効果をもたらし得ることになる。 ◎ The localStorage attribute provides access to shared state. This specification does not define the interaction with other browsing contexts in a multiprocess user agent, and authors are encouraged to assume that there is no locking mechanism. A site could, for instance, try to read the value of a key, increment its value, then write it back out, using the new value as a unique identifier for the session; if the site does this twice in two different browser windows at the same time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects.

11.2.4. `storage^et ~event

上の ~session~storage節, ~local~storage節 に述べたように,~storage区画`の内容^tnoteが変化した際には、`文書$の`~window$に向けて, `storage$et ~eventが発火される。 ◎ 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は,`文書$ %文書 に対し `~storage通知を送信する@ ときは、次を行う~taskを`待入し$~MUST ⇒ %文書 の`~window$に向けて, `StorageEvent$I ~interfaceを利用する 名前 `storage$et の`~eventを発火-$する ◎ When a user agent is to send a storage notification for a Document, the user agent must queue a task to fire an event named storage at the Document object's Window object, using StorageEvent.

注記: %文書 は `全部的に作動中$であることは必要とされないが、 %文書 に向けて発火される~eventは, %文書 が再び `全部的に作動中$になるまでは、`~event~loop$からは無視される。 ◎ 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.

上述の~taskに対する`~task源$は、 `DOM 操作~task源$とする。 ◎ The task source for these tasks is the DOM manipulation task source.

`setItem()$m ~methodの呼出により `~item$ %~item が追加-または更新され,それに応じて~eventが発火される場合、その~eventの各種 属性は,次のように初期化され~MUST:

  • `key$m 属性 ~SET %~item の`~key$
  • `oldValue$m 属性 ~SET %~item は新たに追加されたならば ~NULL / 他の場合は %~item の元の`~value$
  • `newValue$m 属性 ~SET %~item の新たな`~value$

【 呼出の回数に応じて,相応する個数の~eventが配送されることになるが、例えば同じ`~item$の値が複数回更新された場合に1個の~eventに集約されることは,あるかもしれない。 】

`removeItem()$m ~methodの呼出により `~item$ %~item が除去され,それに応じて~eventが発火される場合、その~eventの各種 属性は,次のように初期化され~MUST:

  • `key$m 属性 ~SET %~item の`~key$
  • `oldValue$m 属性 ~SET %~item の`~value$
  • `newValue$m 属性 ~SET ~NULL
◎ If the event is being fired due to an invocation of the setItem() or removeItem() methods, the event must have its key attribute initialized to the name of the key in question, its oldValue attribute initialized to the old value of the key in question, or null if the key is newly added, and its newValue attribute initialized to the new value of the key in question, or null if the key was removed.

`clear()$m ~methodの呼出に応じて~eventが発火される場合、その~eventの各種 属性は,次のように初期化され~MUST:

  • [ `key$m, `oldValue$m, `newValue$m ]属性 ~SET ~NULL
  • `url$m 属性 ~SET [ 影響された `Storage$I ~objが属する`文書の~URL$ ]
  • `storageArea$m 属性 ~SET [ 対象の`文書$の`~window$のそれと同種の(すなわち~sessionか~localか) `Storage$I 区画を表現する `Storage$I ~obj ]
◎ 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 initialized to null. ◎ In addition, the event must have its url attribute initialized to the URL of the document whose Storage object was affected; and its storageArea attribute initialized 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).

11.2.4.1. `StorageEvent^I ~interface

⇒! [Constructor(DOMString type, optional `StorageEventInit$I eventInitDict)] interface `StorageEvent@I : `Event$I { readonly attribute DOMString? `key$m; readonly attribute DOMString? `oldValue$m; readonly attribute DOMString? `newValue$m; readonly attribute DOMString `url$m; readonly attribute `Storage$I? `storageArea$m; }; dictionary `StorageEventInit@I : `EventInit$I { DOMString? key = null; DOMString? oldValue = null; DOMString? newValue = null; USVString url = ""; `Storage$I? storageArea = null; }; ◎
`key@m
変更された`~item$の`~key$を表現する。 ◎ ↓
被取得時には、初期化-時の値を返さ~MUST。 ◎ The key attribute must return the value it was initialized to. It represents the key being changed.
`oldValue@m
変更された`~item$の前の`~value$を表現する。 ◎ ↓
被取得時には、初期化-時の値を返さ~MUST。 ◎ The oldValue attribute must return the value it was initialized to. It represents the old value of the key being changed.
`newValue@m
変更された`~item$の新たな`~value$を表現する。 ◎ ↓
被取得時には、初期化-時の値を返さ~MUST。 ◎ The newValue attribute must return the value it was initialized to. It represents the new value of the key being changed.
`url@m
変更された`~item$を持つ~storageが属する`文書の~URL$を表現する。 ◎ ↓
被取得時には、初期化-時の値を返さ~MUST。 ◎ The url attribute must return the value it was initialized to. It represents the URL of the document whose key changed.
`storageArea@m
影響された `Storage$I ~objを表現する。 ◎ ↓
被取得時には、初期化-時の値を返さ~MUST。 ◎ The storageArea attribute must return the value it was initialized to. It represents the Storage object that was affected.

11.3. ~disk容量

~UAは、~storage区画に許容される総量を制限するべきである。 さもなければ、敵対的~作者が,この特色機能を利用して 利用者の~disk容量を枯渇させることが可能になるので。 ◎ 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は、~siteが,その生成元の他の提携~siteの下で~dataを格納することからも,利用者を防護するべきである。 さもなければ、例えば `a1.example.com^s, `a2.example.com^s, `a3.example.com^s, 等々 に許容される限界まで~dataを格納することにより,~mainの `example.com^s の~storage制限を迂回することが可能になるので。 ◎ 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は、~quata~~上限に到達した際に、利用者がより多くの容量を~siteにあてがえるよう,利用者に促してもよい。 これにより,~siteは、例えば,利用者が作成した多数の文書~dataを,利用者のコンピュータ上に格納できるようになる。 ◎ 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は、それぞれの~domainが占めている容量を,利用者が見れるようにするべきである。 ◎ User agents should allow users to see how much space each domain is using.

`生成元$ごとに,ほぼ恣意的な 5 ~megabyte程度を上限にすることが示唆される。 実装からの~feedbackを歓迎する。 その際には,この示唆は将来的に更新されることになる。 ◎ 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.

予測可能性のため,~quataは格納済み~dataの無圧縮時の~sizeに基づくべきである。 ◎ For predictability, quotas should be based on the uncompressed size of data stored.

11.4. ~privacy

11.4.1. 利用者の追跡

第三者主体の広告主(あるいは,複数の~siteに内容を流布し得る任意の主体)は、利用者の関心~profileを築き上げ,より~~高度な絞り込み広告を可能にする目的で、~local~storage区画に一意な識別子を格納することにより,複数の~sessionに渡って利用者を追跡し得る。 利用者の本当の身元を知っている~site(例えば認証情報を要する電子商取引~site)と~~連携した場合、不当な団体が,匿名 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.

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

第三者主体による~storage利用を阻止する ◎ Blocking third-party storage
~UAは、 `localStorage$m ~objへの~accessを,`~top-level閲覧文脈$の`作動中の文書$の~domainを出自にしている~scriptに制約してもよい。 例えば、 `iframe$e の中で走らせている 他の~domainからの~pageに対しては、 API への~accessを~~許可しないなど。 ◎ User agents may restrict access to the localStorage objects to scripts originating at the domain of the active document of the top-level browsing context, for instance denying access to the API for pages from other domains running in iframes.
格納済み~dataを失効させる ◎ Expiring stored data
~UAは、場合によっては,利用者による環境設定に従って,一定期間が経過した格納済み~dataは自動的に削除されるようにしてもよい。 ◎ User agents may, possibly in a manner configured by the user, automatically delete stored data after a period of time.
例えば~UAは、その環境設定にて、第三者主体による~local~storage区画を~session用途のみと見なし,利用者がその~storageへ~accessし得るすべての`閲覧文脈$を閉じた時点で ~dataが削除されるように,環境設定することもできる。 ◎ 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.
これにより、~siteが複数の~sessionに渡って利用者を追跡できるのは,利用者が~site自身にて認証される場合(例えば購入予約や~serviceへの~log-inなど)に限られることになるため、~siteが利用者を追跡する~~能力を制約し得るものになる。 ◎ 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 they authenticate with the site itself (e.g. by making a purchase or logging in to a service).
しかしながら これは、持続的~storageの仕組みから得られる API の有用性も抑制する。 それはまた、利用者が~dataの失効がもたらす~~影響について全部的に理解していない場合に、利用者の~dataを~riskにさらすことになる。 ◎ 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.
持続的~storageを~cookie同様に扱う ◎ Treating persistent storage as cookies
利用者が~local~storage区画に格納されている~dataは残しつつ,~cookieを消去することで自身の~privacy保護を行う試みに対しては、~site側は,両者の特色機能を利用して相互に冗長backupすることで、迂回し得る。 ~UAは、利用者に,この可能性について理解することを支援し、持続的~storageを供するすべての特色機能について,同時に~dataを削除し得るような、~UIを備えるべきである。 `COOKIES$r ◎ 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]
~local~storage ~accessのための~site別 安全list ◎ Site-specific safelisting of access to local storage areas
~UAは、~siteによる~session~storage区画への~accessは制約しない一方で,~local~storage区画への~accessについては 利用者からの~~許可を要するようにしてもよい。 ◎ User agents may allow sites to access session storage areas in an unrestricted manner, but require the user to authorize access to local storage areas.
格納済み~dataからの生成元の追跡 ◎ Origin-tracking of stored data
~UAは、~dataを格納させた第三者主体の生成元からの内容を含んでいる~siteの`生成元$を記録してよい。 ◎ User agents may record the origins of sites that contained content from third-party origins that caused data to be stored.
この情報を 持続的~storageに存在する~dataの表示に利用すれば、利用者が持続的~storageのどの部分を取り除くかの~~判断材料になる。 阻止listとの併用により( “この~dataを削除して、この~domainが再び~dataを格納しないようにする” 等)、利用者は,持続的~storageの利用を 信用できる~siteのみに制約できるようになる。 ◎ 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 blocklist ("delete this data and prevent this domain from ever storing data again"), the user can restrict the use of persistent storage to sites that they trust.
阻止listの共有- ◎ Shared blocklists
~UAは、利用者~間で持続的~storageに関する~domainの阻止listを共有できるようにしてもよい。 ◎ User agents may allow users to share their persistent storage domain blocklists.
これにより、~communityは~privacy保護に向けて~~協同できるようになる。 ◎ This would allow communities to act together to protect their privacy.

これらの示唆は、利用者を追跡するための,この API の自明な利用は防止するが、まとめて阻止するものではない。 ~siteは、単独の~domain内では~sessionに渡って利用者を追跡し続けられ,その情報を~siteが取得した個人識別情報(~~名前, カード番号, 住所など)と伴に第三者主体に渡すことは可能である。 第三者主体が,複数の~siteで協同してその種の情報を得れば、依然として,~profileは作成され得る。 ◎ 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 に~session識別子を埋め込むことにより — ある範囲において(過去に遡ってすら)可能である。 これは、害の無い目的で,すでに広く利用されてはいるが、利用者の追跡に容易に転用し得る技法でもある。 この情報は、他~siteと共有し得るものになる — 訪問者の IP ~addressその他の 利用者~特有の~data(例えば `User-Agent^h ~headerや環境設定など)を利用して,個別の~sessionを組合せて、一貫した利用者~profileに仕立て上げることにより。 ◎ 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.

11.4.2. ~dataの取り扱い

~UAは、持続的に格納された~dataを,潜在的に~sensitiveなものと見なすべきである。 メール, 予定表, 診断記録, その他の秘匿文書が,この仕組みを通して格納されることは、ごく普通にあり得る。 ◎ 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は,~dataを削除する際には、必ず,下層の~storageからも即座に削除されるようにすべきである。 ◎ To this end, user agents should ensure that when deleting data, it is promptly deleted from the underlying storage.

11.5. ~security

11.5.1. DNS 偽装~攻撃

DNS 偽装~攻撃の下では、一定の~domainに属すると主張する~hostが本当にその~domainからのものであるかどうか,保証できなくなる可能性がある。 TLS を利用すれば,これを軽減できる。 TLS を利用する~pageは、[ 利用者, 利用者を~~代理する~software, [ 証明書を伴う TLS を利用していて, 同じ~domainからであるものと識別される,他の~page ]]のみが,それらの~storage区画に~access可能であることの、確証を得られる。 ◎ 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.

11.5.2. ~cross-directory攻撃

同じ~host名を共有している作者たちは(例えば(今や~~機能しなくなったが) `geocities.com^s で内容を~hostしている作者たちなど)、全員が1個の~local~storage~objを共有することになる。 ~pathnameにより~accessを制約する特色機能はないので、彼らのうち誰もが他の作者の~dataを読取ったり, 上書きすることが可能になる。 したがって,他者と~hostを共有している作者には、これらの特色機能の利用を避けることが督促される。 ◎ Different authors sharing one host name, for example users hosting content on the now defunct 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.

注記: 仮に~path制約の特色機能が利用できたとしても、通常の DOM ~scripting ~security~modelから、この保護を迂回して,任意の~pathからの~dataへ~accessすることは自明になる。 ◎ 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.

11.5.3. 実装にあたって考慮すべき~risk

これらの持続的な~storage特色機能を実装するにあたっては、2つの主要な~riskがある:

  • 敵対的~siteによる他の~domainの情報の読取り
  • 敵対的~siteによる情報の書込み後の他~siteからの情報の読取り
◎ 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.

第三者主体~siteの~domainからの読取りは想定されていない~dataに,そのような読取りを許した場合、情報~漏洩になる。 例えば、ある~domainの利用者の~wishlistは,他の~domainによる絞り込み広告に利用され得る。 あるいは文書作成~siteにより格納された,利用者の作業中の秘匿文書が競合企業の~siteに読まれてしまうなど。 ◎ 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.

第三者主体~siteによる,他の~domainの持続的~storageへの~dataの書込みを許した場合、同等に危険な,情報~spoofingが生じる。 例えば、敵対的~siteが利用者の~wishlistに “item” を付け加えるなど。 あるいは、敵対的~siteにより利用者の~session識別子が既知の ID に設定された場合,その ID は被害者~siteにおける利用者の追跡に利用され得る。 ◎ 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.

したがって,この仕様に述べた`生成元$~modelを厳格に守ることは、利用者の~securityにとり,重要になる。 ◎ Thus, strictly following the origin model described in this specification is important for user security.