initial commit

2 files changed, 146 insertions, 0 deletions

diff --git a/files/ja/web/api/storage_access_api/index.html b/files/ja/web/api/storage_access_api/index.html
new file mode 100644
index 0000000000..853faa4325
--- /dev/null
+++ b/files/ja/web/api/storage_access_api/index.html
@@ -0,0 +1,93 @@
+---
+title: Storage Access API
+slug: Web/API/Storage_Access_API
+tags:
+  - API
+  - Reference
+  - Storage
+  - Storage Access API
+translation_of: Web/API/Storage_Access_API
+---
+<div>{{DefaultAPISidebar("Storage Access API")}}{{seecompattable}}</div>
+
+<p><span class="seoSummary">Storage Access API（ストレージアクセス API）は、埋め込まれたクロスオリジンのコンテンツが、通常はファーストパーティのコンテキストでのみアクセスできるストレージ（これをオリジンの<em>ファーストパーティ</em>ストレージと呼びます）に無制限にアクセスする方法を提供します。 API は、埋め込まれたリソースがファーストパーティストレージに現在アクセスできるかどうかを確認し、ユーザーエージェントからファーストパーティストレージへのアクセスを要求できるメソッドを提供します。</span></p>
+
+<h2 id="Concepts_and_usage" name="Concepts_and_usage">概念と使用方法</h2>
+
+<p>ほとんどのブラウザーは、埋め込まれたクロスオリジンリソースのクッキーおよびサイトデータへのアクセスを制限する多くのストレージアクセスポリシーを実装しています。 これらの制限は、各最上位オリジンの下に埋め込まれたリソースに一意のストレージスペースを与えることから、サードパーティのコンテキストでリソースが読み込まれたときのストレージアクセスの完全なブロックにまで及びます。</p>
+
+<p>特にサードパーティのクッキーブロックポリシーに関する意味論はブラウザーごとに異なりますが、コア機能は似ています: サードパーティのコンテキストに埋め込まれたクロスオリジンリソースには、ファーストパーティのコンテキストで読み込まれたときにアクセスできるのと同じクッキーとサイトストレージへのアクセスが与えられません。</p>
+
+<p>これらのクッキーブロックポリシーは、ファーストパーティストレージへのアクセスを必要とする埋め込まれたクロスオリジンコンテンツを中断することが知られています。 例として、フェデレーションログイン（federated login、複数組織にまたがったログイン）では、ファーストパーティストレージに保存されている認証クッキーへのアクセスが必要になることが多く、これらのクッキーが利用できない場合、ユーザーは各サイトに個別にサインインする（または完全に中断する）必要があります。 中断した場合、サイト所有者は、ユーザーにサイトを例外として追加するか、ポリシーを完全に無効にすることを推奨することがよくあります。 結果として、埋め込まれたコンテンツとのやり取りを継続することを希望するユーザーは、すべての埋め込まれたオリジンおよびおそらくすべてのウェブサイトから読み込まれたリソースのブロックポリシーを大幅に緩和する必要があります。</p>
+
+<p>Storage Access API は、この問題を解決することを目的としています。 埋め込まれたクロスオリジンのコンテンツは、{{domxref("Document.requestStorageAccess()")}} メソッドを介してサイトごとにファーストパーティストレージへの無制限のアクセスを要求し、{{domxref("Document.hasStorageAccess()")}} メソッドを介して既にアクセス権があるかどうかを確認できます。</p>
+
+<p>さらに、セキュリティ上の理由から、サンドボックス化した {{htmlelement("iframe")}} にはデフォルトでストレージアクセスを許可できません。 そのため、API は、<code>allow-storage-access-by-user-activation</code> <a href="/ja/docs/Web/HTML/Element/iframe#attr-sandbox">sandbox トークン</a>も追加します。 次のように、埋め込まれたウェブサイトは、これを追加してストレージアクセス要求が成功することを許可するとともに、<code>allow-scripts</code> と <code>allow-same-origin</code> を使用して API の呼び出しを許可し、クッキーを持つことができるオリジンで実行します。</p>
+
+<pre class="brush: html">&lt;iframe sandbox="allow-storage-access-by-user-activation
+                 allow-scripts
+                 allow-same-origin"&gt;
+  ...
+&lt;/iframe&gt;</pre>
+
+<p>API は、潜在的なストレージの例外を、ユーザーがやり取りする意図を示したオリジンに制限するように設計されています。 これは、次の制約によって実施されます。</p>
+
+<ul>
+ <li>埋め込まれたコンテンツがタップやクリックなどのユーザージェスチャーを現在処理していない限り、アクセス要求は自動的に拒否されます。 これにより、ページに埋め込まれたコンテンツが過剰なアクセス要求でブラウザーまたはユーザーにスパムすることも防止されます。</li>
+ <li>ファーストパーティとしてやり取りしたことがないオリジンには、ファーストパーティストレージの概念がありません。 ユーザーの観点から見ると、そのオリジンとサードパーティの関係性しかありません。 ブラウザーが、ユーザーがファーストパーティのコンテキストで埋め込まれたコンテンツと最近やり取りしていないことをブラウザーが検出した場合、アクセス要求は自動的に拒否されます（Firefox では、「最近」は「30日以内」です）。</li>
+</ul>
+
+<p>ブラウザーは、到来するストレージアクセス要求を許可するかどうかの決定にユーザーを関与させることを決定する場合があります。 ストレージ許可の存続期間とブラウザーがユーザーに通知することを決定する状況に関する詳細は現在作業中であり、準備ができ次第発表されます。</p>
+
+<h2 id="User_prompts" name="User_prompts">ユーザープロンプト</h2>
+
+<p>埋め込まれたクロスオリジンの文書によって <code>requestStorageAccess()</code> が呼び出されると、ユーザーエージェントは、要求オリジンにストレージアクセスを許可するかどうかの決定にユーザーを関与させることを選択できます。 現在、プロンプトヒューリスティック（Prompting heuristics、プロンプトするべきかを決める発見的方法）は Storage Access API の2つの実装者によって異なります。 Safari は、以前にストレージアクセスを受け取っていないすべての埋め込まれた追跡コンテンツにプロンプトを表示します。 Firefox は、追跡オリジンがサイトのしきい値数を超えてストレージアクセスを要求した後にのみユーザーにプロンプトします。 詳細については、{{domxref("Document.requestStorageAccess()")}} を参照してください。</p>
+
+<h2 id="Safari_implementation_differences" name="Safari_implementation_differences">Safari の実装との違い</h2>
+
+<p>API の表面は同じですが、Storage Access API を使用するウェブサイトは、Firefox と Safari の間で受け取るストレージアクセスのレベルと範囲に違いがあることを予期する必要があります。 これは、2つのブラウザーに実装されているストレージアクセスポリシーの違いが原因です。 Firefox に固有の設計プロパティを以下に要約します。</p>
+
+<ul>
+ <li>埋め込まれたオリジン <code>tracker.example</code> が最上位オリジン <code>foo.example</code> でファーストパーティストレージへのアクセスを既に取得しており、ユーザーが <code>foo.example</code> からのページに埋め込まれた <code>tracker.example</code> からのページに、30日以内に再度訪問した場合、埋め込まれたオリジンは、読み込まれるとすぐにストレージにアクセスできます。</li>
+ <li>最上位オリジン <code>foo.example</code> のページに <code>tracker.example</code> の複数の {{htmlelement("iframe")}} が埋め込まれ、それらの <code>&lt;iframe&gt;</code> の1つが Storage Access API を使用してストレージアクセスを正常に取得した場合、<code>foo.example</code> 最上位オリジン上の <code>tracker.example</code> からの他のすべての iframe は、requestStorageAccess() を個別に呼び出す必要なく、すぐにストレージアクセスを取得します。</li>
+ <li><code>tracker.example</code> から埋め込まれたページが以前に最上位オリジン <code>foo.example</code> でストレージアクセスを正常に取得していた場合、<code>foo.example</code> 上の <code>tracker.example</code> からのすべての埋め込まれたサブリソース（スクリプト、画像、スタイルシートなど）がファーストパーティストレージにアクセスして読み込まれます。 つまり、Cookie ヘッダーを送って、到来する {{httpheader("Set-Cookie")}} ヘッダーを尊重する可能性があります。</li>
+ <li>Firefox では、<code>requestStorageAccess()</code> から返された Promise が解決されると、埋め込まれたページは、クッキーだけでなく、ファーストパーティストレージ全体にアクセスできます。 これには、<a href="/ja/docs/Web/API/Web_Storage_API">Web Storage</a>、<a href="/ja/docs/Web/API/IndexedDB_API">IndexedDB</a>、<a href="/ja/docs/Web/API/Cache">DOM Cache</a> などの API へのアクセスが含まれます。</li>
+ <li>Firefox では、ストレージアクセス許可は30暦日が経過すると段階的に廃止されますが、Safari では、ブラウザーの使用がユーザーの操作なしで30日が経過するとストレージアクセス許可が段階的に廃止されます。 これは現在、Firefox 実装の制限であり、将来のバージョンで対処する可能性があります。 Safari では、Storage Access API を正常に使用すると、このカウンターがリセットされます。</li>
+</ul>
+
+<p>追跡クッキーをブロックするための Firefox の新しいストレージアクセスポリシーの文書には、ストレージアクセス許可の範囲の<a href="/ja/docs/Mozilla/Firefox/Privacy/Storage_access_policy#Storage_access_grants">詳細な説明</a>が含まれています。</p>
+
+<h2 id="Storage_Access_API_methods" name="Storage_Access_API_methods">Storage Access API のメソッド</h2>
+
+<p>Storage Access API のメソッドは、{{domxref("Document")}} インターフェイスに実装されます。</p>
+
+<dl>
+ <dt>{{domxref("Document.hasStorageAccess()")}}</dt>
+ <dd>文書がファーストパーティストレージにアクセスできるかどうかを示すブール値で解決される {{jsxref("Promise")}} を返します。</dd>
+ <dt>{{domxref("Document.requestStorageAccess()")}}</dt>
+ <dd>ファーストパーティストレージへのアクセスが許可された場合に解決し、アクセスが拒否された場合に拒否する {{jsxref("Promise")}} を返します。</dd>
+</dl>
+
+<div class="note">
+<p><strong>注</strong>: ユーザーとのやり取りは、これらの両方のメソッドによって返される Promise に伝播し、呼び出し元は、ユーザーからの2回目のクリックを必要とせずに、ユーザーとのやり取りを必要とするアクションを実行できます。 例えば、呼び出し元は、Firefox のポップアップブロッカーをトリガーせずに、解決した Promise からポップアップウィンドウを開くことができます。</p>
+</div>
+
+<h2 id="Extensions_to_&lt;iframe>_sandbox" name="Extensions_to_&lt;iframe>_sandbox">&lt;iframe&gt; サンドボックスの拡張</h2>
+
+<p>{{htmlelement("iframe")}} 要素の <code>sandbox</code> 属性には新しいトークン <code>allow-storage-access-by-user-activation</code> があり、サンドボックス化した <code>&lt;iframe&gt;</code> は Storage Access API を使用してストレージアクセスを要求できます。</p>
+
+<h2 id="Specifications" name="Specifications">仕様</h2>
+
+<p>API は現在、提案段階にあり、標準化プロセスはまだ開始されていません。 現在、Apple の <a href="https://webkit.org/blog/8124/introducing-storage-access-api/">Introducing Storage Access API</a> ブログ投稿、および <a href="https://github.com/whatwg/html/issues/3338">WHATWG HTML issue 3338 — Proposal: Storage Access API</a> で API の仕様の詳細を見つけることができます。</p>
+
+<h2 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの互換性</h2>
+
+
+
+<p>{{Compat("api.Document.hasStorageAccess")}}</p>
+
+<p>{{Compat("api.Document.requestStorageAccess")}}</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<p><a href="/ja/docs/Web/API/Storage_Access_API/Using">Storage Access API の使用</a></p>
diff --git a/files/ja/web/api/storage_access_api/using/index.html b/files/ja/web/api/storage_access_api/using/index.html
new file mode 100644
index 0000000000..f6446ab416
--- /dev/null
+++ b/files/ja/web/api/storage_access_api/using/index.html
@@ -0,0 +1,53 @@
+---
+title: Storage Access API の使用
+slug: Web/API/Storage_Access_API/Using
+tags:
+  - API
+  - DOM
+  - Guide
+  - Reference
+  - Storage
+  - Storage Access API
+translation_of: Web/API/Storage_Access_API/Using
+---
+<div>{{seecompattable}}{{DefaultAPISidebar("Storage Access API")}}</div>
+
+<p class="summary"><span class="seoSummary">埋め込まれたクロスオリジンの文書で <a href="/ja/docs/Web/API/Storage_Access_API">Storage Access API</a> を使用して、ファーストパーティストレージにアクセスできるかどうかを確認し、そうでない場合はアクセスを要求する必要があります。 一般的なストレージアクセスのシナリオについて簡単に説明します。</span></p>
+
+<h2 id="Usage_notes" name="Usage_notes">使用上の注意</h2>
+
+<p>Storage Access API は、ユーザーのブラウザーがすべてのサードパーティのクッキーをブロックするように設定されている場合にブロックされるストレージへのアクセスを埋め込まれたコンテンツが要求できるように設計されています。 埋め込まれたコンテンツはユーザーが使用しているストレージポリシーを認識しないため、ストレージからの読み取りまたは書き込みを試みる前に、常に埋め込まれたフレームにストレージアクセスがあるかどうかを確認するのが最善です。 これは、{{domxref("Document.cookie")}} へのアクセスの場合に特に当てはまります。 サードパーティのクッキーがブロックされると、ブラウザーはしばしば空のクッキージャーを返すためです。</p>
+
+<h2 id="Accessing_a_users_cookies_in_an_embedded_cross-origin_iframe" name="Accessing_a_users_cookies_in_an_embedded_cross-origin_iframe">埋め込まれたクロスオリジン iframe でユーザーのクッキーにアクセスする</h2>
+
+<p>この例では、埋め込まれたクロスオリジン {{htmlelement("iframe")}} が、サードパーティのクッキーをブロックするストレージアクセスポリシーの下でユーザーのクッキーにアクセスする方法を示します。</p>
+
+<p>まず、<code>&lt;iframe&gt;</code> がサンドボックス化されている場合、次のように、埋め込まれたウェブサイトは <code>allow-storage-access-by-user-activation</code> <a href="/ja/docs/Web/HTML/Element/iframe#attr-sandbox">sandbox トークン</a>を追加して、ストレージアクセス要求が成功することを許可するとともに、<code>allow-scripts</code> と <code>allow-same-origin</code> を使用して API の呼び出しを許可し、クッキーを持つことができるオリジンで実行します。</p>
+
+<pre class="brush: html">&lt;iframe sandbox="allow-storage-access-by-user-activation
+                 allow-scripts
+                 allow-same-origin"&gt;
+  ...
+&lt;/iframe&gt;</pre>
+
+<p>次に、埋め込まれた文書内で実行されるコードに進みます。 現在ストレージにアクセスできるかどうかはわからないため、最初に {{domxref("Document.hasStorageAccess()")}} を呼び出す必要があります。 その呼び出しが <code>false</code> を返す場合、{{domxref("Document.requestStorageAccess()")}} を呼び出すことができます。 それが返した結果は、前の Promise 呼び出しにチェーンできます。 最後の <code>then</code> では、ファーストパーティストレージへのアクセスが可能になります。</p>
+
+<pre class="brush: js">document.hasStorageAccess().then(hasAccess =&gt; {
+  if (!hasAccess) {
+    return document.requestStorageAccess();
+  }
+}).then(_ =&gt; {
+  // これで、ファーストパーティストレージにアクセスできます！
+
+  // ファーストパーティのクッキージャーからいくつかのアイテムにアクセスしましょう
+  document.cookie = "foo=bar";              // クッキーを設定
+  localStorage.setItem("username", "John"); // localStorage エントリにアクセス
+}).catch(_ =&gt; {
+  // ストレージアクセスの取得エラー。
+});</pre>
+
+<p>埋め込まれたコンテンツがタップやクリックなどのユーザージェスチャーを現在処理していない限り、アクセス要求は自動的に拒否されることに注意してください。 このコードは、例えば、次のようなユーザージェスチャーベースのイベントハンドラー内で実行する必要があります。</p>
+
+<pre class="brush: js">btn.addEventListener('click', () =&gt; {
+  // ここでコードを実行します
+});</pre>