Secure Contexts 日本語訳

1. 導入

この章は非規範的です。

より便利でより強力なアプリケーションが動作できるように Web プラットフォームが拡張されるに従い、アプリケーションに必要な機能の動作範囲が、最小限のセキュリティ境界を満たすコンテキストの中だけであることを保障する必要性が高まっています。この文書では、Web における機能の悪用(see §4.1 脅威モデル)に対する脅威モデルを説明し、新しい機能を規定する文書が組み込むべき規範的な要件を説明します(see §7 実装に関して考慮すべき事項)。

ここで議論される要件の中で最も明白なのは、機微・私的なデータにアクセスするアプリケーションのコードが配信されるのは、データの完全性が保障され、認証が行われ、かつ機密性が確保された通信路のみであるべきだということです。安全な通信路でコードを配信した場合でも、ユーザの安全とプライバシーに関する要件をアプリケーションが常に満たすことまでは保障できませんが、これは必要な前提条件です。

それと比べると明確ではありませんが、アプリケーションのコードが配信される通信路において真正性と機密性が確保されていた場合でも、安全ではないコンテキストによって強力な機能が使用されることを十分に防ぐことはできません。§4.2 コンテキストの親に関するリスクで説明されている通り、機能の強固な制限を回避するために共存するフレームが悪用されることがあります。以下に定義されるアルゴリズムによって、このような回避が難しくなること、悪意を持った行動がユーザに見えるようになることとが保障されます。

以下の例では、この文書における規範的な文章を要約して説明します。

1.1. トップレベルのドキュメント

トップレベルのドキュメントは、そのドキュメントを開いた opener browsing context が安全なものである限り安全です。やや複雑なため、まずは例で考えてみましょう。

top-level browsing context で開かれた http://example.com/ は、認証と暗号化が行われた通信路で送信されていないため、secure context ではありません。

top-level browsing context で開かれた https://example.com/ は、認証と暗号化が行われた通信路で送信されたため、secure context です。

安全なコンテキストが https://example.com/ を新しいウィンドウで開いた場合、開かれた側はもともと安全であり、かつ安全なコンテキストから開かれたため、この新しいウィンドウは安全なコンテキストです。

安全でないコンテキストが https://example.com/ を新しいウィンドウで開いた場合、事情はより複雑になり、その開いた方法によって新しいウィンドウの状態は変わります。もし、安全でないコンテキストが安全なコンテキストに対する参照を得ることが可能な場合、新しいウィンドウは安全なコンテキストにはならず、逆も同様です。

つまり次の例では、どちらの書き方においても安全でないコンテキストを生成します。

<a href="https://example.com/" target="_blank">Link!</a>

<script>
  var w = window.open("https://example.com/");
</script>

noopener の link relation によって関係性を遮断することができるため、次の 2 つの書き方はどちらも安全なコンテキストを生成します。

<a href="https://example.com/" rel="noopener" target="_blank">Link!</a>

<script>
  var w = window.open("https://example.com/", "", "noopener");
</script>

1.2. フレーム内のドキュメント

フレーム内のドキュメントは、potentially trustworthy origin から送信され、かつ secure context の中に埋め込まれた場合、そのドキュメントは secure context になります。例を次に示します。

top-level browsing context で開かれた https://example.com/ が、https://sub.example.com/ をフレームの中に開いた場合、両者ともに認証と暗号化が行われた通信路で送信されたため、どちらも secure context になります。

https://example.com/ のページが、何らかの方法で http://non-secure.example.com/ を埋め込むことができた場合（ユーザが混在コンテンツの確認を無視している可能性も考えられますが）、トップレベルのフレームは安全なままですが、埋め込まれたコンテンツは安全なコンテキストではありません。

上とは逆の例として、http://non-secure.example.com/ のページ内に https://example.com/ が埋め込まれていた場合を考えます。このとき、親が送信されてきた通信路は認証と暗号化が行われていないため、埋め込まれたフレームは secure context ではありません。

1.3. Web Workers

Dedicated Web Workers は本質的にフレーム内のドキュメントと似ています。Dedicated Web Workers を安全とみなせるのは、potentially trustworthy origin から送信され、かつ、自身をホストしているサイトが secure context なコンテキストである場合です。

top-level browsing context の https://example.com/ が https://example.com/worker.js を実行する場合、ドキュメントと worker は両者ともに secure contexts です。

top-level browsing context の http://non-secure.example.com/ がフレームとして https://example.com/ を埋め込んでおり、そのフレームが https://example.com/worker.js を実行する場合、埋め込まれたドキュメントと worker はどちらも secure contexts ではありません。

1.4. Shared Workers

Shared Worker は複数のコンテキストを持つ場合があります。secure context が Shared Worker を作成した場合、その Worker は secure context になり、他の secure context によってのみ紐付けられるでしょう。安全でないコンテキストが Shared Worker を作成した場合、その Worker は secure context ではなく、他の安全でないコンテキストによってのみ紐付けられるでしょう。

top-level browsing context の https://example.com/ が Shared Worker として https://example.com/worker.js を実行する場合、ドキュメントと worker はともに安全なコンテキストと見なされます。

異なる top-level browsing context の https://example.com/（新しいウィンドウなど）が安全なコンテキストである場合、これらは安全な shared worker にアクセスできます。

http://non-secure.example.com/ に内包された https://example.com/ は安全なコンテキストではないため、安全な worker に接続することはできません。

同じく、http://non-secure.example.com/ に内包された https://example.com/ Shared Worker として https://example.com/worker.js を実行する場合、ドキュメントと worker はどちらも安全ではないと見なされます。

1.5. Service Workers

Service Workers は常に secure contexts です。secure contexts のみが Service Workers を登録でき、Service Worker は secure contexts のクライアントのみを保持できます。

top-level browsing context の https://example.com/ が https://example.com/service.js を登録した場合、ドキュメントと Service Worker はどちらも安全なコンテキストと見なされます。

2. 枠組み

§3.1 settings object は安全なコンテキストか？に示されるアルゴリズムが "Secure" を返した場合、その settings object は secure context であると見なされ、その他の場合は non-secure であると見なされます。

同様にして、ある global object が secure context と見なされるのは、その relevant settings object が secure context である場合です。

2.1. WebIDL に関する変更点

[SecureContext] という新しい属性値は、安全なコンテキストにのみ exposed されることを保障したい処理に付加できます。以下の例が参考になるはずです。

interface ExampleFeature {
  // この呼び出しはすべてのコンテキストで成功します
  Promise <double> calculateNotSoSecretResult();

  // この処理は安全でないコンテキストからアクセスできません。もしそのようなコンテキストが何らかの方法によって、
  // この条件なしに処理を呼び出せた場合、Promise は直ちに 'SecurityError' 例外を送出します。
  [SecureContext] Promise<double> calculateSecretResult();

  // 同じことがここにも当てはまります。この処理は安全でないコンテキストからはアクセスできませんが、もし何らかの
  // 方法によって呼び出された場合は 'SecurityError' 例外が送出されます。
  [SecureContext] boolean getSecretBoolean();
};

仕様書の著者には、新しい機能を定義する際にこの属性値を用いることを推奨します。

この属性値が追加されるかどうかは現在レビュー中です。 <https://github.com/heycam/webidl/issues/65>

2.2. HTML に関する変更点

2.2.1. Shared Workers

secure context ではない Worker に対して secure context を結び付けようとした場合、または secure context である Worker に対して secure context でないものを結び付けようとした場合、SharedWorker() のコンストラクタは SecurityError 例外を投げることになります。このコンストラクタは次のように定義されています。

現時点で定義されている SharedWorker() コンストラクタの処理 8.7 ("If worker global scope is not null, then run these steps:") について、最初の副手続きとして以下を実行します。
1. incumbent settings object に対して §3.1 settings object は安全なコンテキストか？のアルゴリズムを適用した結果と、worker global scope の relevant settings object に対して同じアルゴリズムを適用した結果とが一致しない場合、SecurityError 例外を投げてこれらの処理を中止します。

2.2.2. 機能の判別

secure contexts であることを必要とする機能があったときに、あるコンテキストからその機能が利用可能かどうかを判断するため、真偽値を持つ単純な属性値をグローバルオブジェクトに追加します。

partial interface Window {
  readonly attribute boolean isSecureContext;
};

partial interface WorkerGlobalScope {
  readonly attribute boolean isSecureContext;
};

Window における isSecureContext、ならびに WorkerGlobalScope における isSecureContext のゲッターは、そのゲッターの global object に対する relevant settings object が secure context であれば true を返し、それ以外の場合は false を返します。

3. アルゴリズム

3.1. `settings object` は安全なコンテキストか？

ある settings object (settings object) に適用されるこのアルゴリズムは、そのオブジェクトがユーザエージェントによって安全な通信路から取得されたコンテキストを表すときに "Secure" を返し、それ以外のときは "Not Secure" を返します。

ancestors に空のリストを代入します。
ここで settings object の global object が WorkerGlobalScope である場合、以下を実行します。
1. ancestors に settings object を追加します。
2. settings object の global object における worker’s Documents のリストに関して、そのリストに含まれている各 Document (document) について以下を実行します。
  1. アルゴリズム §3.3 document に関係する親を集めるを document へ適用した結果に含まれる各要素を ancestors に追加します。
そうではない場合、settings object の global object は Window であるため、以下を実行します。
1. アルゴリズム §3.3 document に関係する親を集めるを settings object の responsible document へ適用した結果に含まれる各要素を ancestors に追加します。
ancestors 内の各要素 ancestor settings object に対して以下を実行します。
1. ancestor settings object の effective script origin が origin の alias ではない 場合、ユーザエージェントは "Not Secure" を返してもよいです（MAY）。
  
  Note: ユーザエージェントが document.domain を通じて同一オリジンポリシーを緩和させたい場合、上記のことからドキュメントを安全ではないコンテキストとして扱うことが可能になります。この機能の利用範囲はとても幅広く、この動作を仕様として要求するのは難しいですが、ユーザエージェントはこの機能をいずれ実装することが推奨されます。
2. ここで ancestor settings object の HTTPS state が "modern" である場合、次の ancestor settings object の処理へ移ります。
  
  補足: ほとんどの場合、そのコンテキストが安全に送信されたかどうかを判断するにはこの確認で十分です。TLS で送信されたドキュメントはこのフラグをセットするうえ、srcdoc Document は自身の親のフラグを継承します（発行元のオリジンを継承するリクエストなども同じ振る舞いをします。これらに関する詳細は basic fetch アルゴリズムを参照してください [FETCH]）。
  http://127.0.0.1 のように "trustworthy" ではあるが認証はされていない場所から送信されたリソースに限り、この確認をスキップすることになります。
3. origin に ancestor settings object の origin を代入します。
4. ここで origin が opaque identifier である場合、settings object の creation URL における origin を origin に代入します。
  
  Note: ここでは、サンドボックス化されたコンテキストの安全性を維持するために URL のオリジンを用いています（サンドボックスはコンテキストが実行できる内容を厳しく制限するものであり、及ぼすリスクのためです）。これは <iframe sandbox src="http://localhost/"> のような場合を考慮したものです。
5. ここで、origin に対してアルゴリズム §3.2 origin は潜在的に信頼できるか？を適用した結果が Potentially Trustworthy ではない場合は "Not Secure" を返します。
"Secure" を返します。

3.2. `origin` は潜在的に信頼できるか？

potentially trustworthy origin とは、データが安全に送信されるものとユーザエージェントが通常みなせるものを指します。

このアルゴリズムは特定のホストとスキーム、オリジンについて、認証や暗号化が行われていない場合でも慣例に従い、これらは潜在的に信頼できるものとみなします。ユーザエージェントは特に、file URL ならびに localhost と等価なホスト名を持つ URL を潜在的に信頼できるものとして扱うべきです（SHOULD）。ローカルファイルとローカルサーバを信頼しないことは原理的に可能ですが、実行時にユーザエージェントが取得できる情報を考慮すると、そのリソースはディスクからユーザエージェントへ安全に送信されたと考えられます。加えて、そのようなリソースを潜在的に信頼できるものとみなすことにより、デプロイ前のアプリ開発者にとって都合がよくなります。

しかし、このように開発者の利便性を優先してもリスクは増えません。ユーザエージェントが先程のような利点よりも安全性を優先する場合、localhost. や file を除外することでより厳しい信頼性を確保してもよいです（MAY）。

これとは反対に、信頼できるスキームかどうかをアプリオリに判断できる、app:、chrome-extension: といったベンダー定義のスキームまで、ユーザエージェントは信頼できるスキームの範囲を広げてもよいです（MAY）（詳しくは §7.1 Packaged Applications を参照してください）。

ある origin (origin) が与えられた際に、以下のアルゴリズムは "Potentially Trustworthy" か "Not Trustworthy" のどちらか適切な方を返します。

ここで origin が opaque identifier であった場合、"Not Trustworthy" を返します。
ここで origin の scheme が https" または "wss" のどちらかであった場合、"Potentially Trustworthy" を返します。

Note: これは [MIX] の a priori authenticated URL という概念と相似になるように意図されています。

Note: blob: と filesystem: URL のオリジンは、自身が作られたコンテキストのオリジンになります。したがって、潜在的に信頼できるオリジンで作られた blob は潜在的に信頼できるものになります。これに対して data: URL と javascript: URL は opaque identifier であり、潜在的に信頼できるものとはみなされません。
ここで origin の host 部が "localhost." [RFC6761] であった場合、"Potentially Trustworthy" を返します。
ここで origin の host 部が 127.0.0.0/8 または ::1/128 といった CIDR 記法 [RFC4632] の一つに一致する場合、"Potentially Trustworthy" を返します。
ここで origin の scheme 部が file であった場合、"Potentially Trustworthy". を返します。
ここで origin の scheme 部がユーザエージェントの認証するものであった場合、"Potentially Trustworthy" を返します。

Note: 詳しくは §7.1 Packaged Applications を参照してください。
ここで origin が信頼できるオリジンとして設定されていた場合、Potentially Trustworthy" を返します。

Note: 詳しくは §7.2 開発環境を参照してください。
"Not Trusted" を返します。

3.3. `document` に関係する親を集める

ある Document (document) に適用されるこのアルゴリズムは、その document が secure context であるかを判断する際に考慮すべき settings objects のリストを返します。

ancestors に空のリストを代入します。
ここで document が an IFrame srcdoc Document ではなかった場合、document の relevant settings object を ancestors に追加します。
document の中に creator Document が含まれている間、その要素を creator にセットして以下を実行します。
1. ここで creator の browsing context が ancestor browsing context ないしは opener browsing context としての document である場合、以下を実行します。
  1. creator が an IFrame srcdoc Document ではない場合、creator の relevant settings object を ancestors に追加します。
  2. document に creator を代入します。
2. それ以外の場合、このループから抜けます。
ancestors を返します。

Note: Document の親を集める際、ここでは browsing context creation document chain を辿りましたが、チェインが top-level browsing context に到達した時点で終了しました。とはいえ、auxiliary browsing contexts のチェインを辿ることになりますが、これは §1.1 トップレベルのドキュメントで議論したとおり、どのように開いたかによってポップアップの状態が変わることを考慮しています。

4. 脅威モデルとリスク

この章は非規範的です。

4.1. 脅威モデル

ネットワーク上には攻撃者が存在するため、認証されていないオリジンに権限を与えることは、あらゆるオリジンに権限を与えることと等価です。インターネットの現状はひどいものであり、ネットワーク上に攻撃者が存在することを当然のように仮定しなくてはなりません。一般に、ネットワーク上の攻撃者は受動的と能動的との2種類に分類されます。

4.1.1. ネットワーク上の受動的な攻撃者

「ネットワーク上の受動的な攻撃者」とは、通信の流れを観察することはできるが、この仕様に関係するレイヤーでの通信を改変することはできない、または意図的に改変しない集団を指します。

このように、ネットワークの監視は「通信している人々の承認なしに彼らの意志を裏切り」、そして「誰かが監視を許している限り、人々はその『誰か』をどれだけ慈悲深い存在と考えていようとも、最も非道な連中から自分たちの身を守ることはできない」 [RFC7258] のです。そのため、この文書で定義されるアルゴリズムは、アプリケーション層におけるデータの完全性だけでなくプライバシーも提供する仕組みを要求しています。

4.1.2. ネットワーク上の能動的な攻撃者

「ネットワーク上の能動的な攻撃者」は、「ネットワーク上の受動的な攻撃者」ができることすべてに加え、ネットワークを流れるあらゆるデータを改変、阻止、再送できる攻撃手段を持っています。セキュリティやプライバシーを揺るがし、個人や団体、さらには国民全体を標的にする潜在的な敵の集団にとって、公共の無線ネットワークを提供、または単に接続しているだけの脆弱なデバイスに限らず、料金の徴収のために通信を操作していながら、セキュリティやプライバシー上の脆弱性を間接的に抱えているインターネットサービスプロバイダ（[VERIZON] や [COMCAST] が最近の例です）という具合に、対象によってさまざまな攻撃手段をとることができます。

4.2. コンテキストの親に関するリスク

そのコンテキスト自身が安全かどうかを判断する際、考察の対象とするコンテキストからその親すべてに至るまで §3.1 settings object は安全なコンテキストか？のアルゴリズムが適用されます。ところで、安全な通信路で送信された iframe 内のドキュメントを、なぜ私たちは安全であると扱わないのでしょうか？

簡潔に言えば、このモデルでは機能の悪用を許してしまうからです。API へのアクセスを安全なコンテキストに制限する試みは、Chrome における [WEBCRYPTOAPI] の実装で早くから行われていましたが、コンテキストの祖先まで制限をかけることは当時の実装において考慮されていませんでした。当時はまだ、API へのアクセスを安全に送信されてきたリソースに制限すれば、API の安全な利用は十分に保障されると考えられていました。しかし実際は Netflix のようなコンテンツが埋め込んだ iframe と postMessage() のブリッジにより、安全でないコンテキストからも API が利用可能になっていました。このときの対策は、安全でないコンテキストによる API へのアクセス速度を遅くする程度のことでしかなく、先程のようなアクセスはまったく防ぎようがありませんでした。

この文書におけるアルゴリズムを利用しても、（§5.1 不完全な分離で議論されているように）secure contexts と安全でないコンテキストとを完全に分離することはできません。しかしながら、コンテキストが提供すべき真正性、機密性、完全性は、コンテキストの親も確認することでかなり強固に保護することができます。

4.3. 安全でないコンテキストに関連するリスク

上で述べた脅威からユーザを守るために、特定の Web プラットフォームの持つ、ユーザのセキュリティとプライバシーに大きな影響を与える機能は secure contexts の中でのみ利用可能であるべきです。安全でないコンテキストで機能を利用可能にすると、以下の可能性をネットワーク上の攻撃者に与えてしまう危険を冒します

機微な情報（個人を識別できる情報、資格情報、支払方法など）を閲覧、改変できる可能性。[CREDENTIAL-MANAGEMENT] は機微な情報を扱う API の一例です。
ユーザのデバイス（カメラ、マイクロフォン、そして GPS は特に挙げる価値がありますが、これには加速度計のように明らかな危険性のほとんどないセンサも確かに含まれています）からの入力を閲覧、改変できる可能性。[GEOLOCATION-API] や [MEDIACAPTURE-STREAMS] はセンサの入力を使う機能の歴史的な一例です。
ユーザがアクセスできる他のデバイスの情報にアクセスできる可能性。[DISCOVERY] や [BLUETOOTH] が良い例です。
ある一定時間が経過すると自身をリセットする識別子（例: sessionStorage）や、ユーザが手動でリセットできる識別子（例: [ENCRYPTED-MEDIA]、Cookie [RFC6265]、そして [IndexedDB]）、さらにはユーザが容易にはリセットできないハードウェアの特徴を識別するもの、こういったものを含む一時的、ないしは永続的な識別子を使ってユーザを追跡できる可能性。
ブラウザのセッションが切れるまで有効なある状態をオリジンに設定できる可能性。[SERVICE-WORKERS] がとても良い例です。
削除したり覆い隠したり、またはコンテキストをユーザが理解するのに用いる詳細情報を変更するなどして、ブラウザのネイティブな UI を操作できる可能性。例えば [FULLSCREEN] が挙げられます。
ユーザの許可が必要な機能を組み込める可能性。

このリストにすべて列挙されているわけではありませんが、仕様を作成したり実装する際に考慮すべきリスクに、どういう種類のものがあるかは分かるはずです。

Note: 機能を secure contexts に制限することは極めて重要ですが、そのような情報を運ぶ手段（例えば、新しいネットワークにアクセスする仕組み、または他のネットワークの情報にアクセスするための基本的な機能）も、同じく機微なものとして扱うことを忘れてはいけません。

5. セキュリティに関して考慮すべき事項

5.1. 不完全な分離

この文書における secure context の定義は、あるオリジン上の「安全な」ビューと、同じオリジン上の「安全でない」ビューとが完全に分離されていません。データを隠し取る手法には、ほぼ誰にも知られていないようなものもあり、localStorage/sessionStorage や storage イベント、BroadcastChannel など多岐に渡ります。

6. プライバシーに関して考慮すべき事項

この文書で定義される secure context は、プライバシーに関して何らかの効果を与えることはありません。しかし、プライバシー上で考慮すべき影響を持つ機能に対して安全なコンテキストを要請することは、完全性・真正性・機密性が担保されたコンテキスト内に動作範囲を制限できることにつながります。

プライバシーの観点から、仕様の著者は機能の定義に際して、安全なコンテキストの要請を考慮することが推奨されます。

7. 実装に関して考慮すべき事項

7.1. Packaged Applications

Packaged Applications をサポートしているユーザエージェントは、自身でコンテンツを認証した特定の URL スキームからなるホワイトリストを作成しても良いでしょう（MAY）。例えば、Firefox OS アプリケーションのリソースは、scheme の構成部分が app: である URL で参照されます。同様に、Chrome 拡張機能と Chrome アプリは chrome-extension: スキームで動作します。これらを信頼できるオリジンと見なせても無理はないでしょう。

7.2. 開発環境

ループバックではないホストでステージングサーバを動かしている開発者を支援するため、§3.2 origin は潜在的に信頼できるか？が通常通り Not Trusted を返す場合であっても、ユーザエージェントは信頼できるオリジンをユーザが指定するのを許可しても良いでしょう（MAY）。

7.3. 新しい機能の制限

この章は非規範的です。

新しい機能に関する仕様を書く著者と編者には、secure context であるかの確認を行って機微な API を守ることが推奨されます。良いアプローチの一例として、以下のようなものが挙げられます。

もし incumbent settings object が secure context でない場合
1. [ ここに適切な文章を入れてください。 SecurityError によって Promise をリジェクトする、エラー時のコールバックを呼び出す、権限リクエストを拒否する、などといった文章が入るかもしれません ]。

機微な API を扱う仕様の著者は、その API を保護するために [SecureContext] 属性を利用し、API が secure context のみで利用可能なことを保障するべきです。

[SecureContext]
interface SensitiveFeature {
  Promise<double> getTheSecretDouble();
};

// Or:

interface AnotherSensitiveFeature {
  [SecureContext] void doThatPowerfulThing();
};

7.4. レガシーな機能の制限

この章は非規範的です。

先ほど挙げたリストには、現時点で Web に存在し、かつ安全でない通信路でアクセス可能な機能が明らかに含まれています。そのようなレガシーな機能が secure context内で利用可能となるよう、現実的な範囲で少しでも早く動き始めることが推奨されます。

そのような機能が広く実装されてはいない場合、secure contexts に関する制限を含めるよう、仕様をすぐに修正することを勧めます。
そのような機能が広く実装されているが、広く使われてはいない場合は、§7.3 新しい機能の制限で述べた確認手順を現存の実装に追加し、それに従って仕様を修正することにより、速やかに機能を secure contexts に制限することを勧めます。
そのような機能が広く使われている場合は、現存の機能を廃止することを勧めます。そして、この文書で説明した制限に仕様が準拠しない旨を記述するために仕様を修正し、準拠する将来のバージョンを提供して現在のユーザを新しいバージョンに移行させる計画の立案をするべきです。

7.4.1. 例: Geolocation

そのような機能の具体例として良いものには [GEOLOCATION-API] があります。この機能は広く実装されており、数多くの安全でないサイトで使われています。無理なく改善するための流れは、以下のようになるかもしれません。

getCurrentPosition() や watchPosition() のアルゴリズムを実行する前に secure context であるかの確認が行われるよう、仕様を修正します。

もし incumbent settings object が secure context ではなかった場合、そのアルゴリズムは中断されるべきであり、かつ PERMISSION_DENIED を表す code とともに errorCallback が呼び出されるべきです。
安全でないコンテキストにおける API を無効にする明確な意志を、決められた日時に表明するべきであり、それに従って開発者には警告を出すべきです（例えば、コンソールにメッセージを出すなど）。
プログラムの変更日を迎えるための準備として、コードを変更する必要性をサイトの運営者に認識させるため、加えてその期間中のユーザを守るため、単純に API をすべて停止させる前に、ユーザエージェントは廃止のスケジュールを公表するべきです。そのような計画には次のようなものが含まれるかもしれません。
1. 安全でないオリジンに与えられていた永続的な権限を無効にする
2. 安全でないオリジンで API を利用した際の精度を粗雑にする（高精度のデータではなく市区町村単位のデータを継続的に返すかもしれません）
3. ユーザとサイトの運営者に対してリスクを伝えるように UI を変更する

8. 謝辞

この文書は、Chrome セキュリティチームの [POWERFUL-NEW-FEATURES] における成果に大きく依存しています。これには Chris Palmer、Ryan Sleevi、そして David Dorwin 各氏が特に貢献しています。また、Anne van Kesteren と Henri Sivonen 両氏からとても有益なフィードバックをいただきました。

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Secure Contexts 日本語訳

Editor’s Draft, 2 February 2016

Abstract

Status of this document

1. 導入

1.1. トップレベルのドキュメント

1.2. フレーム内のドキュメント

1.3. Web Workers

1.4. Shared Workers

1.5. Service Workers

2. 枠組み

2.1. WebIDL に関する変更点

2.2. HTML に関する変更点

2.2.1. Shared Workers

2.2.2. 機能の判別

3. アルゴリズム

3.1. settings object は安全なコンテキストか？

3.2. origin は潜在的に信頼できるか？

3.3. document に関係する親を集める

4. 脅威モデルとリスク

4.1. 脅威モデル

4.1.1. ネットワーク上の受動的な攻撃者

4.1.2. ネットワーク上の能動的な攻撃者

4.2. コンテキストの親に関するリスク

4.3. 安全でないコンテキストに関連するリスク

5. セキュリティに関して考慮すべき事項

5.1. 不完全な分離

6. プライバシーに関して考慮すべき事項

7. 実装に関して考慮すべき事項

7.1. Packaged Applications

7.2. 開発環境

7.3. 新しい機能の制限

7.4. レガシーな機能の制限

7.4.1. 例: Geolocation

8. 謝辞

Conformance

Document conventions

Conformant Algorithms

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

Informative References

IDL Index

Issues Index

3.1. `settings object` は安全なコンテキストか？

3.2. `origin` は潜在的に信頼できるか？

3.3. `document` に関係する親を集める