仕様書

TLS 必須の機能

[25] 次の機能は、原則として素のHTTP では利用できず、 HTTPS でなければならないようになっています。

[139] Geolocation は当初非保安文脈にも提供されていましたが、 保安文脈に制限されました。従来多くの素のHTTPの Webサイトがこれを利用していましたが、 セキュリティーを理由に仕様変更が強行されました。

[79] Push API は、 secure context でのみ提供しなければならないとしながら、 開発目的のみこれを無視して良いとしています。 >>78

[86] 次の機能は、保安文脈と非保安文脈をまたいで利用できません。 混合内容制約と似ています。

[138] 一般に新しい機能は保安文脈でのみ利用可能とすることが好ましいと考えられています。

判定

[88] WindowOrWorkerGlobalScope インターフェイスの isSecureContext IDL属性 >>82 の取得器は、 次のようにしなければなりません。

[83] 環境設定群オブジェクトは、 文脈的保安が真のとき保安文脈 (secure context) であり、 偽のとき非保安文脈 (non-secure context) であります。 >>82

[84] 大域オブジェクトは、 関連設定群オブジェクトの文脈的保安が真のとき保安文脈であり、 偽のとき非保安文脈であります。 >>82

[91] 環境設定群オブジェクト設定群が文脈的保安 (contextually secure) であるか否かは、 次の Is settings contextually secure? 手順群によります。 >>90

[97] 簡単に言えばフレームの包含関係やワーカーの生成関係の祖先方向に 1つでも保安文脈でないものがあれば、保安文脈ではないと判断されます。

[131] URL URL が潜在的に信頼できるURL (potentially trustworthy URL) であるか否かは、次の手順群によります。 >>90

[141] 先験的認証済URLの定義からも参照されます。

[109] 起源起源が 潜在的に信頼できる起源 (potentially trustworthy origin) であるか否かは、 次によります。 >>90

[110] これが真であることは、 利用者エージェントが通常、データを保安して配送するものと信頼できることを意味しています。 >>90

[126] file: について、仕様書はアルゴリズムを事実の文として記述していて、 これを参照しているアルゴリズムが必須と規定されているならそれが波及してこの規定も必須となります。 仕様書本文にはそれとやや矛盾するとも思われる、 これを推奨とする規定もあります。 利用者エージェントは、 ローカルファイルを信頼できないと扱うこともできましょうが、 ディスクから利用者エージェントに保安的に輸送された資源ですし、 Web開発者の便宜を図るためもあって、 信頼できるとするべきだ >>90 とされます。 しかしながら、リスクがないでもありませんから、 そうした便宜より保安性を重視する利用者エージェントは、 file: を信頼できないとみなしても構わない >>90 ともされています。

SecureContext 拡張属性

[85] 仕様書の著者は、新しい機能を定義する時、 SecureContext とすることが推奨されます (encouraged) 。 >>82 (参考)

歴史