Web Storage

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]

1 つ目の仕組みは、利用者が単独の~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の 2 つ目の仕組みは、複数の~window, 複数の~sessionに渡って残り続ける~storage用に設計されている。 ~web-appは、特に,~megabyte~~単位の利用者~data — 例えば 利用者が作成した文書~全体や, 利用者の~mailboxなど — に対しては,処理能の理由から~client側に保存するよう望むこともある。 ◎ The second storage mechanism is designed for storage that spans multiple windows, and lasts beyond the current session. In particular, Web applications might 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を~~参照されたし。

この~pageには、[ %~window の`文書$ / %文書 の`~window$ ]という表記がよく現れるが、おそらく[ 前者は %~window に`結付けられている文書$, 後者はその逆の関係 ]を指す。

11.2. ~API

11.2.1. `Storage^I ~interface

[Exposed=Worker]
interface `Storage@I {
  readonly attribute unsigned long `length$m;
  DOMString? `key$m(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~list@ への~accessを供する: ◎ Each Storage object provides access to a list of key/value pairs,\

  • `~item~list$は、いくつかの `~item@ からなる~listである。 各`~item$は [ `~key@ とそれに対応する `~value@ ]が成す組である。 `~key$, `~value$は、いずれも文字列である — (空~文字列も含め)どのような文字列も値として妥当である。 ◎ which are sometimes called items. Keys are strings. Any string (including the empty string) is a valid key. Values are similarly strings.
  • `~item~list$は、 `Storage$I ~objの作成-時に結付けられる(詳細は `sessionStorage$m 属性, `localStorage$m 属性 各~節にて定義される)。 同じ`~item~list$が、 `Storage$I ~interfaceを実装する複数の別個の~objに,同時に結付けられ得る。 ◎ 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 . `length$m
`~item~list$内の現在の`~item$の総数を返す。 ◎ Returns the number of key/value pairs currently present in the list associated with the object.
%storage . `key(index)$m
`~item~list$の %index 番の`~key$を返す — ただし、 %index が`~item~list$内の`~item$の総数~以上の場合は, ~NULL を返す。 ◎ Returns the name of the nth key in the list, or null if n is greater than or equal to the number of key/value pairs in the object.
%value = %storage . `getItem(key)$m
%value = %storage[%key]
`~item~list$内に[ %key を`~key$とする`~item$ ]が[ 在るならば その現在の`~value$/ 無いならば ~NULL ]を返す。 ◎ Returns the current value associated with the given key, or null if the given key does not exist in the list associated with the object.
%storage . `setItem(key, value)$m
%storage[%key] = %value
`~item~list$内の[ %key を`~key$とする`~item$ ]の`~value$を — そのような`~item$が無いならば,新たなそれを作成した上で — %value に設定する。 ◎ Sets the value of the pair identified by key to value, creating a new key/value pair if none existed for key previously.
新たな値を設定できなかった場合、 `QuotaExceededError$E 例外を投出する(例えば、利用者が当の~site用の~storageを不能化していた場合や, ~quotaを超過した場合)。 ◎ Throws a "QuotaExceededError" DOMException exception if the new value couldn't be set. (Setting could fail if, e.g., the user has disabled storage for the site, or if the quota has been exceeded.)
%storage . `removeItem( key )$m
`delete$c %storage[%key]
`~item~list$内に[ %key を`~key$とする`~item$ ]が在るならば、それを除去する。 ◎ Removes the key/value pair with the given key from the list associated with the object, if a key/value pair with the given key exists.
%storage . `clear$m()
~objの`~item~list$を空にする ◎ Empties the list associated with the object of all key/value pairs, if there are any.
`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(index)@m

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

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

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

【 この順序に関しては,他に要件は述べられていないので、~itemを追加したり除去した後で,全体の順序がまるっきり変わることもあり得ることになる。 】

◎ 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名たち$は、次で与えられる【有順序】 集合として定義される:

  • ~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
被呼出時には、次を返さ~MUST ⇒ `~item~list$内に[ `~key$ ~EQ %key ]なる`~item$は[ 在るならば その現在の`~value$ / 無いならば ~NULL ] ◎ 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\

  1. %~item ~LET `~item~list$内に[ `~key$ ~EQ %key ]なる`~item$は[ 在るならば それ / 無いならば ε ] ◎ first check if a key/value pair with the given key already exists in the list associated with the object.\
  2. ~IF[ %~item ~EQ ε ] ⇒ `~item~list$に 次のようにされた新たな`~item$を追加する ⇒ ( `~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.\
  4. ~ELSE ⇒ 何もしては~MUST_NOT 【下の注記を見よ】 ◎ If its previous value is equal to value, then the method must do nothing.
新たな`~value$を設定できなかった場合、この~methodは `QuotaExceededError$E 例外を投出し~MUST。 ◎ If it couldn't set the new value, the method must throw a "QuotaExceededError" DOMException exception.
この~methodは、 `removeItem()$m と同様に,失敗に関して不可分的で~MUST。 ◎ ↓
`removeItem(key)@m

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

  1. ~IF[ `~item~list$内に[ `~key$ ~EQ %key ]なる`~item$は在る ] ⇒ その`~item$を`~item~list$から除去する
  2. ~ELSE ⇒ 何もしては~MUST_NOT 【下の注記を見よ】
◎ 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()$m に加え,この~methodも、失敗に関して不可分的で~MUST。 失敗する場合、これらの~methodは何もしない。 すなわち,~data~storage区画に対する変更は、[ 成功するか, または 全く変更されないか ]のいずれかで~MUST。 ◎ 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

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

  1. ~IF[ `~item~list$は空でない ] ⇒ `~item~list$を空にする
  2. ~ELSE ⇒ 何もしては~MUST_NOT 【下の注記を見よ】
◎ 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が呼出されたときは、 【~storage区画に変更が加えられた場合に限り】 [[ 新たに格納-または除去された~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 属性

interface mixin `WindowSessionStorage@I {
  readonly attribute `Storage$I `sessionStorage$m;
};
`Window$I includes `WindowSessionStorage$I;

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

%window . `sessionStorage$m
その生成元†に属する~session~storage区画に結付けられている `Storage$I ~objを返す。 【† より明確には、 %window に`結付けられている文書$の`生成元$であろう。】 ◎ Returns the Storage object associated with that origin's session storage area.

それぞれの`~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が失効しないようにするべきであるが、次のいずれかの場合は失効させてもよい: ◎ User agents should not expire data from a browsing context's session storage areas, but may do so when\

  • 利用者からその種の~dataを削除するよう要請されたとき。 ◎ the user requests that such data be deleted, or\
  • ~UAが~storage容量の限界を検出したとき。 ◎ when the UA detects that it has limited storage space, or\
  • 保安~上の理由があるとき。 ◎ for security reasons.\

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

  • ~dataに~accessし得る~scriptを走らせている間は,失効させないべきである。 ◎ should always avoid deleting data while a script that could access that data is running.\
  • `~top-level閲覧文脈$が破壊されたときは(したがって,それ以降~利用者からは~access不能になる),破棄できる — この仕様に述べる~APIは、後続して当の~dataを検索取得する仕方を供さないので。 ◎ 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 can support resuming sessions after a restart.

~UAは、新たな`文書$ %文書 を作成したときは、 %文書 が属する`閲覧文脈$の `~top-level閲覧文脈$ %T があるならば,次で与えられる~session~storage区画を %文書 にあてがわ~MUST: ◎ When a new Document is created in a browsing context which has a top-level browsing context, the user agent must check to see\

  • %T が[ %文書 の`生成元$ %O ]用の~session~storage区画をすでに有しているならば、それ。 ◎ 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.\
  • 他の場合、 %O 用の新たな~storage区画を作成した結果。 ◎ 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.\

%文書 が存続する限り、 %文書 に他の~storage区画があてがわれることはない。 ◎ 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を返さ~MUST。 各 `文書$は、それぞれが別個の,その`~window$の `sessionStorage$m 属性に対応する~objを持た~MUST。 ◎ The sessionStorage attribute must return a Storage object associated with the Document's assigned session storage area. Each Document object must have a separate object for its Window's sessionStorage attribute.

~session~storage区画は、`新たな閲覧文脈を作成する$ときに 複製される こともある。 ◎ While creating a new browsing context, the session storage area is sometimes copied over.

~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 属性

interface mixin `WindowLocalStorage@I {
  readonly attribute `Storage$I `localStorage$m;
};
`Window$I includes `WindowLocalStorage$I;

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

%window . `localStorage$m
その生成元†に属する~local~storage区画に結付けられている `Storage$I ~objを返す。 【† より明確には、 %window に`結付けられている文書$の`生成元$であろう。】 ◎ Returns the Storage object associated with that origin's local storage area.
次の場合、 `SecurityError$E 例外を投出する ⇒ `Document$I の`生成元$は`不透明な生成元$である / その要請は施策~裁定に違反する(例:~UAは、~pageが~dataを持続化するのを許容しないよう,環境設定されている) ◎ Throws a "SecurityError" DOMException if the Document's origin is an opaque origin or if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data).

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

~UAが~local~storage区画の~dataを失効させるのは、保安~上の理由があるか, または利用者から要請された場合に限られるべきである。 ~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. ~IF[ その要請は施策~裁定に違反している(例えば~UAの環境設定により,その~pageでは~dataの持続-は許容されていないなど) ] ⇒ ~UAの任意選択で ⇒ ~THROW `SecurityError$E ◎ If the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data), the user agent may throw a "SecurityError" DOMException instead of returning a Storage object
  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.
  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用の一意な識別子として書戻すとするとき、これが 2 つの~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区画【の内容】が変化した際には、以下に述べるように,~~関連する`~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通知を送信する@ ときは、次を走らせ~MUST ⇒ `~DOM操作~task源$から,次を走らす`~taskを~queueする$ ⇒ %文書 の`~window$に向けて,名前 `storage$et の`~eventを発火する$ — `StorageEvent$I ~interfaceを利用して ◎ 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. ◎ The task source for these tasks is the DOM manipulation task source.

この~eventが、次のいずれかの動作に応じて発火された場合 ⇒ [[ `setItem()$m / `setItem()$m / `removeItem()$m ]~methodが呼出されて,`~item$ %~item が[ 新たに追加された/更新された/除去された ]], あるいは[ `clear()$m ~methodが呼出されて,`~item~list$が空にされた ] ◎終 ~UAは、~eventの属性を,次に従って初期化し~MUST: ◎ If the event is being fired due to an invocation of the setItem() or removeItem() methods,\

  • [ `key$mE, `oldValue$mE, `newValue$mE ]属性は、次の表に従って初期化する:

    動作 `key$mE `oldValue$mE `newValue$mE
    新たに追加された %~item の`~key$ ~NULL %~item の新たな`~value$
    更新された %~item の`~key$ %~item の元の`~value$ %~item の新たな`~value$
    除去された %~item の`~key$ %~item の`~value$ ~NULL
    空にされた ~NULL ~NULL ~NULL
    ◎ 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. ◎ 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.
  • `url$mE 属性 ~SET [ 影響された `Storage$I ~objが属する`文書の~URL$【を文字列に直列化した結果】 ] ◎ In addition, the event must have\ ◎ its url attribute initialized to the URL of the document whose Storage object was affected;\
  • `storageArea$mE 属性 ~SET [ 対象の`文書$の`~window$のそれと同種の(すなわち~sessionか~localか) `Storage$I 区画を表現する `Storage$I ~obj ] ◎ 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).

【 呼出された回数だけ~eventが配送されることになるが、例えば同じ`~item$の`~value$が続けて複数回~更新された場合に 1 個の~eventに集約されることは,あるかも? 】

11.2.4.1. `StorageEvent^I ~interface

[Exposed=Worker,
 Constructor(DOMString type, optional `StorageEventInit$I eventInitDict)]
interface `StorageEvent@I : `Event$I {
  readonly attribute DOMString? `key$mE;
  readonly attribute DOMString? `oldValue$mE;
  readonly attribute DOMString? `newValue$mE;
  readonly attribute USVString `url$mE;
  readonly attribute `Storage$I? `storageArea$mE;
};

dictionary `StorageEventInit@I : `EventInit$I {
  DOMString? key = null;
  DOMString? oldValue = null;
  DOMString? newValue = null;
  USVString url = "";
  `Storage$I? storageArea = null;
};
%event . `key$mE
変更された`~item$の`~key$を返す。 ◎ Returns the key of the storage item being changed.
%event . `oldValue$mE
変更された`~item$の前の`~value$を返す。 ◎ Returns the old value of the key of the storage item whose value is being changed.
%event . `newValue$mE
変更された`~item$の新たな`~value$を返す。 ◎ Returns the new value of the key of the storage item whose value is being changed.
%event . `url$mE
変更された`~item$を持つ~storageが属する`文書の~URL$【を文字列に直列化した結果】を返す。 ◎ Returns the URL of the document whose storage item changed.
%event . `storageArea$mE
影響された `Storage$I ~objを返す。 ◎ Returns the Storage object that was affected.
`key@mE
`oldValue@mE
`newValue@mE
`url@mE
`storageArea@mE
いずれも,取得子は、初期化-時の値を返さ~MUST。 ◎ The key, oldValue, newValue, url, and storageArea attributes must return the values they were initialized to.

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は、~quotaの~~上限に到達した際に、利用者がより多くの容量を~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.

予測-可能にするため,~quotaは、格納-済み~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. 保安

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している作者たちなど)、全員が同じ~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 保安~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がある: ◎ The two primary risks when implementing these persistent storage features are\

  • 敵対的~siteによる他の~domainの情報の読取り ◎ letting hostile sites read information from other domains, and\
  • 敵対的~siteによる情報の書込み後の他~siteからの情報の読取り ◎ 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を厳格に守ることは、利用者の保安にとり,重要になる。 ◎ Thus, strictly following the origin model described in this specification is important for user security.