1. 序論
~INFORMATIVE~web~platformが拡張され，より有用かつ強力な応用が可能化されるに伴い、［ その種の応用を可能化する特色機能は、最小限の保安~levelを満たす文脈に限り，可能化される ］ことを確保することが，ますます重要になっている。 この文書は — `SECURING-WEB$r における TAG の推奨の拡張として — ~web上で特色機能を濫用する脅威~modelについて述べる（ 脅威~model 節を見よ）とともに、新たな特色機能を仕様化している文書に組入れるべき，規範的~要件について概説する（ 実装にあたっての考慮点 を見よ）。 ◎ As the web platform is extended to enable more useful and powerful applications, it becomes increasingly important to ensure that the features which enable those applications are enabled only in contexts which meet a minimum security level. As an extension of the TAG’s recommendations in [SECURING-WEB], this document describes threat models for feature abuse on the web (see §4.1 Threat Models) and outlines normative requirements which should be incorporated into documents specifying new features (see §7 Implementation Considerations).
ここで論じられる要件のうち，最も明らかなものは、敏感あるいは私的な~dataへの~accessを伴う~app~codeが、~data完全性を保証する認証-済み~channel越しに，機密的に送達されることである。 ~codeを保安的に送達することは、［ その~appが，利用者の保安や~privacy要件を満たす ］ことを，常に確保するわけではないが、必要とされる前提条件である。 ◎ The most obvious of the requirements discussed here is that application code with access to sensitive or private data be delivered confidentially over authenticated channels that guarantee data integrity. Delivering code securely cannot ensure that an application will always meet a user’s security and privacy requirements, but it is a necessary precondition.
もう少し明らかでないことは、~app~codeが認証-済みかつ機密的な~channel越しに送達されるだけでは、強力な特色機能に対する 非保安的~文脈からの利用を制限するには，十分でないことである。 先祖による~risk 節に説明するように、協同する~frameを濫用することにより，さもなければ堅固な［ 特色機能に対する制約 ］は迂回され得る。 以下に定義される各種~algoは、これらの迂回を困難かつ利用者から可視にすることを確保する。 ◎ Less obviously, application code delivered over an authenticated and confidential channel isn’t enough in and of itself to limit the use of powerful features by non-secure contexts. As §4.2 Ancestral Risk explains, cooperative frames can be abused to bypass otherwise solid restrictions on a feature. The algorithms defined below ensure that these bypasses are difficult and user-visible.
以下に示す例に、後述の規範的~textを要約する： ◎ The following examples summarize the normative text which follows:
1.1. ~top-level文書
`~top-level閲覧文脈$内に開いた `http://example.com/^s は、認証-済みかつ暗号化された~channel越しに送達されていないので，`保安的~文脈$にならない。 ◎ http://example.com/ opened in a top-level browsing context is not a secure context, as it was not delivered over an authenticated and encrypted channel.
`fig-01^dgm`~top-level閲覧文脈$内に開いた `https://example.com/^s は、認証-済みかつ暗号化された~channel越しに送達されたので，`保安的~文脈$になる。 ◎ https://example.com/ opened in a top-level browsing context is a secure context, as it was delivered over an authenticated and encrypted channel.
`fig-02^dgm保安的~文脈が，新たな~window内に `https://example.com/^s を開いた場合、その新たな~windowは，それ自体が保安的なので 保安的~文脈になる。 ◎ If a secure context opens https://example.com/ in a new window, that new window will be a secure context, as it is secure on its own merits:
`fig-03^dgm同様に、非保安的な文脈が，新たな~window内に `https://example.com/^s を開いた場合、その~windowは保安的になる — それを開いた側が非保安的でも： ◎ Likewise, if a non-secure context opens https://example.com/ in a new window, that new window will be a secure context, even through its opener was non-secure:
`fig-05^dgm1.2. ~frame内の文書
~frame内の文書は、それが［ `信用に価し得る生成元$から送達されたものであって, なおかつ `保安的~文脈$内に埋込まれている ］ならば、`保安的~文脈$になれる。 すなわち： ◎ Framed documents can be secure contexts if they are delivered from potentially trustworthy origins, and if they’re embedded in a secure context. That is:
`~top-level閲覧文脈$内に開かれた `https://example.com/^s が ~frame内に `https://sub.example.com/^s を開いた場合、両者とも，認証-済みかつ暗号化された~channel越しに送達されたので、`保安的~文脈$になる。 ◎ If https://example.com/ opened in a top-level browsing context opens https://sub.example.com/ in a frame, then both are secure contexts, as both were delivered over authenticated and encrypted channels.
`fig-06^dgm`https://example.com/^s が，どうにかして `http://non-secure.example.com/^s を~frame内に入れれた場合（おそらく、利用者が混在~内容の検査法を上書きしたがため？）、~top-level~frameは，保安的であり続けるが、~frame内の内容は保安的~文脈にならない。 ◎ If https://example.com/ was somehow able to frame http://non-secure.example.com/ (perhaps the user has overridden mixed content checking?), the top-level frame would remain secure, but the framed content is not a secure context.
`fig-07^dgm一方で、 `http://non-secure.example.com/^s の内側の~frame内に入れられた `https://example.com/^s は、保安的~文脈にならない — その先祖は、認証-済みかつ暗号化された~channel越しに送達されてないので。 ◎ If, on the other hand, https://example.com/ is framed inside of http://non-secure.example.com/, then it is not a secure context, as its ancestor is not delivered over an authenticated and encrypted channel.
`fig-08^dgm1.3. ~web~worker
`専用~worker$は、その資質から~frame内の文書と類似する。 それは、［ `信用に価し得る生成元$から送達され, なおかつ その所有者~自身も`保安的~文脈$である ］ときに限り、`保安的~文脈$になる： ◎ Dedicated Workers are similar in nature to framed documents. They’re secure contexts when they’re delivered from potentially trustworthy origins, only if their owner is itself a secure context:
`~top-level閲覧文脈$内の `https://example.com/^s が `https://example.com/worker.js^s を走らせた場合、その文書, ~workerの両者とも`保安的~文脈$になる。 ◎ If https://example.com/ in a top-level browsing context runs https://example.com/worker.js, then both the document and the worker are secure contexts.
`fig-09^dgm`~top-level閲覧文脈$内の `http://non-secure.example.com/^s が `https://example.com/^s を~frame内に入れていて，後者が `https://example.com/worker.js^s を走らせた場合、~frame内の文書, ~workerの両者とも，`保安的~文脈$にならない。 ◎ If http://non-secure.example.com/ in a top-level browsing context frames https://example.com/, which runs https://example.com/worker.js, then neither the framed document nor the worker are secure contexts.
`fig-10^dgm1.5. ~service~worker
~service~workerは、常に`保安的~文脈$になる。 ~service~workerを登録できるのは，`保安的~文脈$に限られ、~service~workerの~clientもまた，`保安的~文脈$に限られる。 ◎ Service Workers are always secure contexts. Only secure contexts may register them, and they may only have clients which are secure contexts.
`~top-level閲覧文脈$内の `https://example.com/^s が `https://example.com/service.js^s を登録した場合、 文書と~service~workerの両者とも保安的~文脈と見なされる。 ◎ If https://example.com/ in a top-level browsing context registers https://example.com/service.js, then both the document and the Service Worker are considered secure contexts.
`fig-15^dgm2. ~framework
`環境~設定群~obj$は、`保安的~文脈を与え$るならば `保安的~文脈@ と見なされ，他の場合は `非保安的~文脈@ と見なされる。 ◎ Environment settings objects are considered to be secure contexts if they are contextually secure as defined in §3.1 Is an environment settings object contextually secure?, and non-secure contexts otherwise.
同様に，`大域~obj$（ `Window$I, `WorkerGlobalScope$I, 等々）は、それに`関連する設定群~obj$が`保安的~文脈を与え$るならば `保安的~文脈$と見なされ，他の場合は `非保安的~文脈$と見なされる。 ◎ Likewise, a global object (Window, WorkerGlobalScope, etc.) is considered to be a secure context if its relevant settings object is contextually secure as defined in §3.1 Is an environment settings object contextually secure?, and a non-secure context otherwise.
2.1. WebIDL との統合
~INFORMATIVE~interface／~interface~memberに対しては [`SecureContext$] 拡張属性が新たに可用にされている。 それは、当の ~interface／~member が，保安的~文脈に限り`公開され$ることを確保する。 次の例のように： ◎ A new [SecureContext] attribute is available for operators, which ensures that they will only be exposed into secure contexts. The following example should help:
interface ExampleFeature {
/*
この~callはすべての文脈で成功する。
◎
This call will succeed in all contexts.
*/
Promise <double> calculateNotSoSecretResult();
/*
この演算は非保安的~文脈には公開されない。
◎
This operation will not be exposed to a non-secure context.
*/
[`SecureContext$] Promise<double> calculateSecretResult();
/*
同様に次の演算も，非保安的~文脈には公開されない。
◎
The same applies here: the operation will not be exposed to a non-secure context.
*/
[`SecureContext$] boolean getSecretBoolean();
};
[`SecureContext$] interface SecureFeature {
/*
この~interfaceは非保安的~文脈には公開されない。
◎
This interface will not be exposed to non-secure contexts.
*/
Promise<any> doAmazingThing();
};
仕様の策定者には、新たな特色機能を定義するときは，この拡張属性を利用することが奨励される。 ◎ Specification authors are encouraged to use this attribute when defining new features.
2.2. ~HTMLに対する改変
2.2.1. ~sandbox法
開発者は、~sandbox化された`閲覧文脈$を 状況によっては`保安的~文脈$に扱い，他の場合は`非保安的~文脈$に扱いたいと望むこともあろう。 次の~sandbox法~flagが，それを~supportする： ◎ Developers may wish to treat sandboxed browsing contexts as secure contexts in some situations, and non-secure contexts in others. The following sandboxing flag supports this desire:
- `閲覧文脈~sandbox化( 保安的 )~flag@ ◎ The sandboxed secure browsing context flag
- この~flagは、［ 当の閲覧文脈~内の内容は，`非保安的~文脈$と扱われる ］ものと表明する — 他では保安的と見なされる内容に対しても。 ◎ This flag asserts that content in a browsing context will be treated as a non-secure context, even if it would otherwise be considered secure.
`~sandbox法~指令を構文解析する$ ~algoは、次のように拡張される ⇒ ［ ~algoの最後の， %tokens を一連の~flagに構文解析する段 ］の最後に，次の段を追加する： ◎ The parse a sandboxing directive algorithm is extended by adding the following entry to the list in the final step of the algorithm which parses tokens into flags:
-
次が満たされるならば，`閲覧文脈~sandbox化( 保安的 )~flag$も %出力 に追加する ⇒ `allow-secure-context@v ~NIN %tokens ◎ The sandboxed secure browsing context flag, unless tokens contains the allow-secure-context keyword.
この特色機能は “~risk下” にあり、下の~link先に述べる課題の解決を待っている（それ自体も各~browser~vendorからの~~評価を待っている）。 そのため、これは WHATWG の~HTMLも W3Cの~HTMLも~~規範にしない。 この特色機能を保つかどうか決まったときは、それについて取りかかることになる。 <https://github.com/w3c/webappsec-secure-contexts/issues/28> ◎ This feature is "at risk", pending the resolution of the linked issue (which itself is pending metrics gathered from browser vendors). Accordingly, no attempt has been made to upstream this to either WHATWG’s HTML or W3C’s HTML. Once we’ve decided whether or not to keep the feature, we’ll work on that. <https://github.com/w3c/webappsec-secure-contexts/issues/28>
2.2.3. 特色機能の検出
~appは、自身が`保安的~文脈$内で実行されているかどうかを，`大域~obj$上の単純な~boolean属性を検査して決定できる： ◎ An application can determine determine whether it’s executing in a secure context by checking a simple boolean attribute on the global object:
partial interface mixin `WindowOrWorkerGlobalScope$I {
readonly attribute boolean `isSecureContext$m;
};
`isSecureContext@m 属性の取得子は、此れに`関連する設定群~obj$は`保安的~文脈を与え$るならば ~T ／ ~ELSE_ ~F ］を返す。 ◎ The isSecureContext attribute’s getter returns true if this global object's relevant settings object is contextually secure, and false otherwise.
3. 各種~algo
3.1. 環境~設定群~objは保安的~文脈を与えるか？
所与の ( `環境~設定群~obj$ %設定群 ) は、［ 次に与える~algoが `保安的^i を返す ］とき, そのときに限り， `保安的~文脈を与え@ ると見なされる（その否定は “与えない” ）： ◎ An environment settings object (settings) is considered contextually secure if and only if the following Is settings contextually secure? algorithm returns "Secure":
- %大域~obj ~LET %設定群 の`大域~obj$enV ◎ Let global be settings’s global object.
-
~IF［ %大域~obj は `WorkerGlobalScope$I ~objである ］： ◎ If global is a WorkerGlobalScope, then:
-
%大域~obj の`所有者~集合$内の~EACH ( `Document$I ~obj %文書 ) に対し： ◎ For each Document (document) in global’s owner set:
- ~Assert： ~workerは，それを作成した文脈と同一生成元であり、したがって %文書 に`関連する設定群~obj$の［ `生成元$enV, `~HTTPS状態$enV ］は %大域~obj に`関連する設定群~obj$の それらと同じである ◎ Assert: Workers must be same-origin with the context that created them, so document’s relevant settings object's origin and HTTPS state is the same as global’s relevant settings object's origin and HTTPS state.
- ~IF［ %文書 に`関連する設定群~obj$は`保安的~文脈を与え$る ］ ⇒ ~CONTINUE ◎ If document’s relevant settings object is not contextually secure, return "Not Secure".
- ~RET `非~保安的^i ◎ ↑
-
~RET `保安的^i ◎ Return "Secure".
注記： 上の ~Assert が与えられた下で，この段に達した場合、当の~workerは`保安的~文脈$から作成されたものであり，したがって それ自身も`保安的~文脈$で~MUST。 ◎ Note: Given the assertion above, if we’ve reached this step, the worker must have been created from a secure context, and therefore must itself be a secure context.
-
- ~Assert： %大域~obj は `Window$I ~objである ◎ Assert: global is a Window.
- %文書 ~LET %設定群 の`担当の文書$enV ◎ Let document be settings’s responsible document.
- %S ~LET %文書 の`作動中の~sandbox法~flag集合$ ◎ ↓
-
~IF［ 次のいずれかが満たされる ］ ⇒ ~RET `非~保安的^i ： ◎ Return "Not Secure" if any of the following are true:
-
`閲覧文脈~sandbox化( 保安的 )~flag$ ~IN %S ◎ document’s active sandboxing flag set contains the sandboxed secure browsing context flag.
注記： この検査は “~risk下” にある。 詳細は ~sandbox法 節を見よ。 ◎ Note: This check is "at risk". See §2.2.1 Sandboxing for details.
- ［ %文書 の`親~閲覧文脈$ %文脈 ~NEQ ε ］~AND［ %文脈 にて`作動中の文書$に`関連する設定群~obj$は `保安的~文脈を与え$ない ］ ◎ document has a parent browsing context (context), and context’s active document's relevant settings object is not contextually secure.
- %設定群 の`~HTTPS状態$enV ~EQ `deprecated^l ◎ settings’s HTTPS state is "deprecated".
-
［ `閲覧文脈~sandbox化( 生成元 )~flag$ ~IN %S ］~AND［ `~URLは信用に価し得るか？$( %設定群 の`作成時の~URL$enV ) ~EQ `価しない^i ］ ◎ document’s active sandboxing flag set includes the sandboxed origin browsing context flag, and §3.3 Is url potentially trustworthy? returns "Not Trustworthy" when executed upon settings’s creation URL.
注記： ここでは、`作成時の~URL$enVを検査する — ~sandbox化された内容であって，不透明な生成元~内にあると扱われるもの（例： `<iframe sandbox="allow-secure-context" src="http://127.0.0.1/">^s ）は、さもなければ，`生成元は信用に価し得るか？$により信用に価しないものと扱われるので。 ~sandbox法は，内容の能力を抑制するのみであり、 and therefore in the risk it poses,【？】 ［ ~sandbox化されていないときに，それを信用に価すると見なすことになる ］かどうかを決定するため，その~URLの生成元を診る。 ◎ Note: We check the creation URL here because sandboxed content that is treated as being in an opaque origin (e.g. <iframe sandbox="allow-secure-context" src="http://127.0.0.1/">) would otherwise be treated as non-trustworthy by §3.2 Is origin potentially trustworthy?. Since sandboxing is a strict reduction in the content’s capabilities, and therefore in the risk it poses, we look at the origin of its URL to determine whether we would have considered it trustworthy had it not been sandboxed.
- ［ `閲覧文脈~sandbox化( 生成元 )~flag$ ~NIN %S ］~AND［ `生成元は信用に価し得るか？$( %設定群 の`生成元$enV ) ~EQ `価しない^i ］ ◎ document’s active sandboxing flag set does not include the sandboxed origin browsing context flag, and §3.2 Is origin potentially trustworthy? returns "Not Trustworthy" when executed upon settings’s origin.
-
- ~RET `保安的^i ◎ Return "Secure".
3.2. 生成元は信用に価し得るか?
`信用に価し得る生成元@ （ `potentially trustworthy origin^en ）とは、~UAが~dataを保安的に送達していると一般に信用できるものである。 ◎ A potentially trustworthy origin is one which a user agent can generally trust as delivering data securely.
この節に述べる~algoは、伝統的~感覚では［ 認証され, かつ暗号化されるもの ］でないかもしれないような，ある種の［ ~host ／ ~scheme ／ 生成元 ］に対しても、信用に価し得ると見なす。 特に，~UAは、 `file^sc ~URLを信用に価し得るものと扱うべきである。 原則的には、~UAは，局所~fileを信用に価しないものと扱うこともできるが、~UAに可用な情報が 実行時に与えられている下では，資源は~diskから~UAに保安的に~transportされたように現れる。 加えて，公共に配備する前の~appを築いている開発者にとっては、そのような資源を信用に価し得るものと扱えた方が，簡便になる。 ◎ This algorithms considers certain hosts, scheme, and origins as potentially trustworthy, even though they might not be authenticated and encrypted in the traditional sense. In particular, the user agent SHOULD treat file URLs as potentially trustworthy. In principle the user agent could treat local files as untrustworthy, but, given the information that is available to the user agent at runtime, the resources appear to have been transported securely from disk to the user agent. Additionally, treating such resources as potentially trustworthy is convenient for developers building an application before deploying it to the public.
しかしながら、この開発者への親切さに~riskがないわけではない。 そのような作り込みより保安を優先する~UAは、より厳格に， `file^sc を除外する仕方で信用をあてがってもよい。 ◎ This developer-friendlyness is not without risk, however. User agents which prioritize security over such niceties MAY choose to more strictly assign trust in a way which excludes file.
他方、~UAは，この信用を，自身が 先天的に 信用-済みであると決定できる他の~URL~scheme — `app^sc や `chrome-extension^sc の様な~vendor特有の~URL~scheme — にまで拡張してもよい（詳細は ~package化~app 節を見よ ）。 ◎ On the other hand, the user agent MAY choose to extend this trust to other, vendor-specific URL schemes like app: or chrome-extension: which it can determine a priori to be trusted (see §7.1 Packaged Applications for detail).
次の~algoは、所与の ( `生成元$ %生成元 ) に対し，信用に［ `価し得る^i ／ `価しない^i ］いずれか適切な方を返す： ◎ Given an origin (origin), the following algorithm returns "Potentially Trustworthy" or "Not Trustworthy" as appropriate.
- ~IF［ %生成元 は`不透明な生成元$である ］ ⇒ ~RET `価しない^i ◎ If origin is an opaque origin, return "Not Trustworthy".
- ~Assert： %生成元 は`成分組~生成元$である ◎ Assert: origin is a tuple origin.
- ( %~scheme, %~host ) ~LET %生成元 の ( `~scheme$, `~host$ ) ◎ ↓
-
~IF［ 次のいずれかが満たされる ］ ⇒ ~RET `価し得る^i： ◎ ↓
-
%~scheme ~IN { `https^l, `wss^l } ◎ If origin’s scheme is either "https" or "wss", return "Potentially Trustworthy".
注記： これは、 `MIX$r における`先天的に認証-済み~URL$の概念に相似するよう~~意図されている。 ◎ Note: This is meant to be analog to the a priori authenticated URL concept in [MIX].
- %~host は， CIDR 記法による［ `127.0.0.0/8^c, `::1/128^c ］いずれかに合致する `RFC4632$r ◎ If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return "Potentially Trustworthy".
-
［［ %~host ~EQ `localhost^l ］~OR［ %~host は `.localhost^l に類する ］］~AND［ ~UAは `let-localhost-be-localhost$r による名前~解決 規則に適合する ］ ◎ If origin’s host component is "localhost" or falls within ".localhost", and the user agent conforms to the name resolution rules in [let-localhost-be-localhost], return "Potentially Trustworthy".
注記： この要件の詳細は、~localhost節を見よ。 ◎ Note: See §5.2 localhost for details on the requirements here.
- %~scheme ~EQ `file^l ◎ If origin’s scheme component is file, return "Potentially Trustworthy".
-
%~scheme は ~UAが認証-済みと見なすものである ◎ If origin’s scheme component is one which the user agent considers to be authenticated, return "Potentially Trustworthy".
注記： 詳細は ~package化~app 節を見よ。 ◎ Note: See §7.1 Packaged Applications for detail here.
-
%生成元 は 信用に価するものと環境設定されている ◎ If origin has been configured as a trustworthy origin, return "Potentially Trustworthy".
注記： 詳細は 開発~環境 節を見よ。 ◎ Note: See §7.2 Development Environments for detail here.
-
- ~RET `価しない^i ◎ Return "Not Trustworthy".
注記： %生成元 の［ `~domain$, `~port$ ］は、いずれも，`保安的~文脈$と見なされるかどうかには効果はない。 ◎ Note: Neither origin’s domain nor port has any effect on whether or not it is considered to be a secure context.
3.3. ~URLは信用に価し得るか？
`信用に価し得る~URL@ とは、作成元から文脈を継承するもの（ `about:blank^l, `about:srcdoc^l ），または［ `生成元$urlが`信用に価し得る生成元$ ］なるものである。 次の~algoは、所与の ( `~URL$ %url ) に対し，信用に［ `価し得る^i ／ `価しない^i ］いずれか適切な方を返す： ◎ A potentially trustworthy URL is one which either inherits context from it’s creator (about:blank, about:srcdoc) or one whose origin is a potentially trustworthy origin. Given a URL (url), the following algorithm returns "Potentially Trustworthy" or "Not Trustworthy" as appropriate:
-
~IF［ %url の`~scheme$url ~EQ `data^l ］ ⇒ ~RET `価しない^i ◎ If url’s scheme is "data", return "Not Trustworthy".
注記： これは、現今の各 主流~browserが同意している［ `不透明な生成元$としての `data^sc ~URL ］に対する事実上（ `de facto^en ）の挙動による，`保安的~文脈$の定義に倣う — ［ `data^sc ~URLは~HTMLにて定義される生成元の挙動を継承する ］とする，規則上の（ `de jure^en ）それではなく。 ◎ Note: This aligns the definition of a secure context with the de facto "data: URL as opaque origin" behavior that a majority of today’s browsers have agreed upon, rather than the de jure "data: URL inherits origin" behavior defined in HTML.
- ~IF［ %url ~IN { `about:blank^l, `about:srcdoc^l } ］ ⇒ ~RET `価し得る^i ◎ If url is "about:blank" or "about:srcdoc", return "Potentially Trustworthy".
-
~RET `生成元は信用に価し得るか？$( %url の`生成元$url ) ◎ Return the result of executing §3.2 Is origin potentially trustworthy? on url’s origin.
注記： `blob^sc ／ `filesystem^sc ~URLの生成元は，それらを作成した文脈の生成元になる。 したがって，信用に価する生成元~内で作成された~blobは，それ自身 信用に価し得ることになる。 ◎ Note: The origin of blob: and filesystem: URLs is the origin of the context in which they were created. Therefore, blobs created in a trustworthy origin will themselves be potentially trustworthy.
4. 脅威~modelとその~risk
~INFORMATIVE4.1. 脅威~model
未認証の生成元に対する許可を是認することは、~network攻撃者の~~存在において，任意の生成元に対する許可を是認することに等価になる。 Internet においては、そのような~network攻撃者が~~実在するものと見做さ~MUST。 一般に，~network攻撃者は、受動的, 能動的の 2 つに分類される。 ◎ Granting permissions to unauthenticated origins is, in the presence of a network attacker, equivalent to granting the permissions to any origin. The state of the Internet is such that we must indeed assume that a network attacker is present. Generally, network attackers fall into 2 classes: passive and active.
4.1.1. 受動的~network攻撃者
“受動的~network攻撃者” は、流通~flowを観測できるが，この仕様が懸念する層における流通を 改変する~~能を欠くか, 改変しないことにした者である。 ◎ A "Passive Network Attacker" is a party who is able to observe traffic flows but who lacks the ability or chooses not to modify traffic at the layers which this specification is concerned with.
この方式による~networkの監視0は、 “通信している当の主体の同意なしに，彼らの意図をないがしろにする” ものであり、 “他の行為者による監視 — 誰がどの程度それを善意と見なすかにかかわらず — を許容している者は、ほとんどの無法な行為者に抗して防御できない” ことを指す。 `RFC7258$r したがって、この文書に定義される~algoでは、単純に完全性のみならず，~app層における~dataの~privacyを供する仕組みも要求する。 ◎ Surveillance of networks in this manner "subverts the intent of communicating parties without the agreement of these parties" and one "cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be." [RFC7258] Therefore, the algorithms defined in this document require mechanisms that provide for the privacy of data at the application layer, not simply integrity.
4.1.2. 能動的~network攻撃者
“能動的~network攻撃者” は、 “受動的~network攻撃者” が有する能力に加え，~networkを通過している~dataを［ 改変- ／ 阻止- ／ 再生- ］できる者である。 これらの能力は、多くの~levelで敵に可用になる — 公共~無線~network内で［ 提供している ／ 単純に関与している ］ような弱体化された機器から，金銭的利益の流通を操作していながら 保安や~privacyの脆弱性を間接的に導入しているような ISP （最近の例として、 `VERIZON$r や `COMCAST$r が挙げられる）まで、果ては［ 個々の利用者／組織／団体／あらゆる人々 ］でさえ標的にできるような，保安や~privacyを弱体化する意図を指図する主体までにわたる。 ◎ An "Active Network Attacker" has all the capabilities of a "Passive Network Attacker" and is additionally able to modify, block or replay any data transiting the network. These capabilities are available to potential adversaries at many levels of capability, from compromised devices offering or simply participating in public wireless networks, to Internet Service Providers indirectly introducing security and privacy vulnerabilities while manipulating traffic for financial gain ([VERIZON] and [COMCAST] are recent examples), to parties with direct intent to compromise security or privacy who are able to target individual users, organizations or even entire populations.
4.2. 先祖による~risk
`環境~設定群~objは保安的~文脈を与えるか？$の~algoは、当の文脈が保安的になるかどうか決定する際に，その文脈のすべての先祖を巡回する。 なぜ、文書は `iframe$e 内に保安的に送達されたこと自体では，保安的と見なされないのか？ ◎ The Is an environment settings object contextually secure? algorithm walks through all the ancestors of a particular context in order to determine whether or not the context itself is secure. Why wouldn’t we consider a securely-delivered document in an iframe to be secure, in and of itself?
短く答えるなら、その~modelでは濫用-が可能化されるからである。 Chrome による `WEBCRYPTOAPI$r 実装による，~APIを保安的~文脈に~lockする早期の実験では、文脈の先祖を巡回していなかった。 そこでは、~APIを，自身が保安的に送達された資源に~lockすることで、保安的な用法は十分に確保されると見做していた。 しかしながらその結果は、~APIを非保安的~文脈に公開するような［ `iframe$e と `postMessage()^m ］に基づく~shimを築いた Netflix の様な実体であった。 その制約は、~APIへの非保安的~accessを，段差舗装より少しばかり遅くするものであったが、その種の~accessを防止するには，何ら効果がなかった。 ◎ The short answer is that this model would enable abuse. Chrome’s implementation of [WEBCRYPTOAPI] was an early experiment in locking APIs to secure contexts, and it did not walk through a context’s ancestors. The assumption was that locking the API to a resouce which was itself delivered securely would be enough to ensure secure usage. The result, however, was that entities like Netflix built iframe- and postMessage()-based shims that exposed the API to non-secure contexts. The restriction was little more than a speed-bump, slowing down non-secure access to the API, but completely ineffective in preventing such access.
この文書における~algoは，非保安的~文脈を`保安的~文脈$から完全0には隔離しないが（不完全な隔離節を見よ）、先祖の検査は，そのような文脈に供されるべき［ 認証, 機密性, 完全性 ］を保証するような，相応に堅牢な保護を供する。 ◎ While the algorithms in this document do not perfectly isolate non-secure contexts from secure contexts (as discussed in §5.1 Incomplete Isolation), the ancestor checks provide a fairly robust protection for the guarantees of authentication, confidentiality, and integrity that such contexts ought to provide.
4.3. 非保安的~文脈に結付けられる~risk
利用者の保安や~privacyに独特の影響0を及ぼすような，ある種の~web~platform特色機能は、上述の脅威に抗して防御するため，`保安的~文脈$に限って可用にされるべきである。 非保安的~文脈にて可用な特色機能は、その能力を~network攻撃者に公開する~riskがある： ◎ Certain web platform features that have a distinct impact on a user’s security or privacy should be available for use only in secure contexts in order to defend against the threats above. Features available in non-secure contexts risk exposing these capabilities to network attackers:
- 敏感な~data（個人を特定する情報, 資格証, 対外支払い法, 等々）を読取る／改変する能 `CREDENTIAL-MANAGEMENT-1$r は、敏感な~dataを取扱う~APIの例である。 ◎ The ability to read and modify sensitive data (personally-identifying information, credentials, payment instruments, and so on). [CREDENTIAL-MANAGEMENT-1] is an example of an API that handles sensitive data.
- 利用者の機器~上の~sensorからの入力を［ 読取る／改変する ］能（特に ~camera, ~microphone, GPS が挙げられるが、そこまで危険に見えない加速度計の様な~sensorも，間違いなく含まれる）。 `GEOLOCATION-API$r, `MEDIACAPTURE-STREAMS$r は、~sensor入力を利用する特色機能の歴史的な例である。 ◎ The ability to read and modify input from sensors on a user’s device (camera, microphone, and GPS being particularly noteworthy, but certainly including less obviously dangerous sensors like the accelerometer). [GEOLOCATION-API] and [MEDIACAPTURE-STREAMS] are historical examples of features that use sensor input.
- 利用者が~accessを有する他の機器についての情報に~accessする能。 格好の例として， `DISCOVERY-API$r, `WEB-BLUETOOTH$r が挙げられる。 ◎ The ability to access information about other devices to which a user has access. [DISCOVERY-API] and [WEB-BLUETOOTH] are good examples.
-
利用者が一時的または持続的に利用している識別子を追跡する能 — 次のものが含まれる：
- ある期間後に自身を再設定する識別子（例： `sessionStorage$m ）
- 利用者が手動で再設定できる識別子（例： `ENCRYPTED-MEDIA$r, ~cookie `RFC6265$r, `IndexedDB$r ）
- 利用者が容易に再設定できない~hardware特色機能を識別するもの
- 閲覧~sessionを超えて持続化するような，生成元に何らかの状態を導入する能。 特に， `SERVICE-WORKERS$r が挙げられる。 ◎ The ability to introduce some state for an origin which persists across browsing sessions. [SERVICE-WORKERS] is a great example.
- ~UAの~native~UIを，何らかの仕方で操作する能 — 利用者のそれらの文脈に関連する詳細に対する理解を［ 除去する／遮る／操作する ］ような。 格好の例として， `FULLSCREEN$r が挙げられる。 ◎ The ability to manipulate a user agent’s native UI in some way which removes, obscures, or manipulates details relevant to a user’s understanding of their context. [FULLSCREEN] is a good example.
- 利用者に許可を要求するような何らかの機能性を導入する能。 ◎ The ability to introduce some functionality for which user permission will be required.
上述の~listは網羅的ではないが、仕様を書いたり実装するときに考慮すべき~riskの型についての感触を与えるであろう。 ◎ This list is non-exhaustive, but should give you a feel for the types of risks we should consider when writing or implementing specifications.
注記： 特色機能~自身を`保安的~文脈$に制約することが~criticalである一方で、そのような情報を運ぶ便宜性（~network~accessの新たな仕組み, その他，~network~dataへの~accessを伴う汎用の関数など）も等しく敏感であることを，忘れるべきでない。 ◎ Note: While restricting a feature itself to secure contexts is critical, we ought not forget that facilities that carry such information (such as new network access mechanisms, or other generic functions with access to network data) are equally sensitive.
5. 保安~上の考慮点
5.1. 不完全な隔離
この文書における`保安的~文脈$の定義は、ある生成元~上の “保安的” ~viewを 同じ生成元~上の “非保安的” ~viewから完全には隔離しない。 `exfiltration^en 【外部への “裏口通信” 】 は、依然として，見え難い部分を次第に拡げていくような仕組み — `localStorage$m や `sessionStorage$m の内容, `storage$et ~event, `BroadcastChannel$I, その他など — を介して可能になる。 ◎ The secure context definition in this document does not completely isolate a "secure" view on an origin from a "non-secure" view on the same origin. Exfiltration will still be possible via increasingly esoteric mechanisms such as the contents of localStorage/sessionStorage, storage events, BroadcastChannel, and others.
5.2. ~localhost
`RFC6761$r の節 6.3 では、 `localhost.^l や `.localhost.^l に類する名前の解決は特別であり、局所~解決器は，それらを特別に［ 扱うべき／扱ってよい ］ものと示唆している。 善悪は別として、解決器は，いくつかの状況下で この示唆を無視して，~localhostを解決するために~networkへ送信することが多い。 ◎ Section 6.3 of [RFC6761] lays out the resolution of localhost. and names falling within .localhost. as special, and suggests that local resolvers SHOULD/MAY treat them specially. For better or worse, resolvers often ignore these suggestions, and will send localhost to the network for resolution in a number of circumstances.
そのような不確かさをふまえ，~UAは、［ `let-localhost-be-localhost$r による~localhost名前~解決 規則 ］を固守する場合（それは、~localhostは，決して非~loopback~addressに解決されないことを確保する）, その場合に限り，~localhost名を信用に価し得る生成元と扱って~MAY。 ◎ Given that uncertainty, user agents MAY treat localhost names as having potentially trustworthy origins if and only if they also adhere to the localhost name resolution rules spelled out in [let-localhost-be-localhost] (which boil down to ensuring that localhost never resolves to a non-loopback address).
6. ~privacy上の考慮点
この文書における`保安的~文脈$の定義は、それ自身には，~privacyへの影響0はない。 しかしながら，それは、［［［［ 完全性, 認証性, 機密性 ］に関して特定の保証を確保するような文脈 ］の中へ，自身を~lockする ］ような，［ 関心を引く~privacy上の含意 ］が~~実際にある，他の特色機能 ］を可能化する。 ◎ The secure context definition in this document does not in itself have any privacy impact. It does, however, enable other features which do have interesting privacy implications to lock themselves into contexts which ensures that specific guarantees can be made regarding integrity, authenticity, and confidentiality.
~privacyの観点からは、仕様の策定者には，［ 自身が定義する特色機能に対し，保安的~文脈を要求する ］ことを考慮することが奨励される。 ◎ From a privacy perspective, specification authors are encouraged to consider requiring secure contexts for the features they define.
7. 実装にあたっての考慮点
7.1. ~package化~app
~package化された~appを~supportする~UAは、［ ~UAにより認証-済みの内容を伴うような，特定の~URL~scheme ］を “保安的” と見なしてよい。 例えば， FirefoxOS ~appの資源は、 `app^sc `~scheme$urlの~URLで指される。 同様に， Chrome の拡張／~appは、 `chrome-extension^sc ~schemeに住まう。 これらを信用-済みの生成元と見なすのが，理に適うこともある。 ◎ A user agent that support packaged applications MAY consider as "secure" specific URL schemes whose contents are authenticated by the user agent. For example, FirefoxOS application resources are referred to by a URL whose scheme component is app:. Likewise, Chrome’s extensions and apps live on chrome-extension: schemes. These could reasonably be considered trusted origins.
7.2. 開発~環境
~loopbackでない~host上で試験用~serverを走らす開発者を~supportするため、~UAは，特定の［ 生成元の集合 ］を — それらに対する `生成元は信用に価し得るか？$が，通常は `価しない^i を返すとしても — 信用に価するものと，利用者が環境設定できるようにしてよい。 ◎ In order to support developers who run staging servers on non-loopback hosts, the user agent MAY allow users to configure specific sets of origins as trustworthy, even though §3.2 Is origin potentially trustworthy? would normally return "Not Trustworthy".
7.3. 新たな特色機能の制約-法
~INFORMATIVE新たな特色機能~用の仕様を書く策定者／編集者には、［ `保安的~文脈$に対する検査により，敏感な~APIを防護する ］ことが推奨される。 例えば、次の様に書く所から始めるのが良いであろう： ◎ When writing a specification for new features, we recommend that authors and editors guard sensitive APIs with checks against secure contexts. For example, something like the following might be a good approach:
-
~IF［ `現在の設定群~obj$は `保安的~文脈$でない ］： ◎ If the current settings object is not a secure context, then:
-
＜ここに何か適切なものを挿入する＞ — おそらく、次に挙げるものなど：
- `Promise^I を `SecurityError^E で却下する,
- ~error用の~callbackを~callする,
- 何かの許可~要請を否認する, 等々。
-
別法として，策定者は、敏感な~APIを次のように [`SecureContext$] 拡張属性で防護して，`保安的~文脈$に限り公開されるよう確保することもできる： ◎ Authors could alternatively ensure that sensitive APIs are only exposed to secure contexts by guarding them with the [SecureContext] attribute.
[`SecureContext$]
interface SensitiveFeature {
Promise<double> getTheSecretDouble();
};
// あるいは：
interface AnotherSensitiveFeature {
[`SecureContext$] void doThatPowerfulThing();
};
7.4. 旧来の特色機能の制約-法
~INFORMATIVE上述の~listには、明白に，現在は非保安的~channel越しでも~webに可用な，既存の機能性も含まれている。 そのような旧来の機能性は、適度に可能な限り，早急に`保安的~文脈$を要求し始めるよう改変する `W3C-PROCESS$r ことが推奨される — そのような特色機能が： ◎ The list above clearly includes some existing functionality that is currently available to the web over non-secure channels. We recommend that such legacy functionality be modified to begin requiring a secure context as quickly as is reasonably possible [W3C-PROCESS].
- 広範に実装されていない場合：
- 即時に、`保安的~文脈$への制約を含むよう，仕様を`改変する$xことが推奨される。 ◎ If such a feature is not widely implemented, we recommend that the specification be immediately modified to include a restriction to secure contexts.
- 広範に実装されているが，まだ広範には利用されていない場合：
- 早急に、新たな特色機能の制約-法に述べた検査を既存の実装に追加して，`保安的~文脈$に制約した上で、それに則って仕様も`改変する$xことが推奨される。 ◎ If such a feature is widely implemented, but not yet in wide use, we recommend that it be quickly restricted to secure contexts by adding a check as described in §7.3 Restricting New Features to existing implementations, and modifying the specification accordingly.
- 広範に利用されている場合：
- 非推奨にすることが推奨される。 すなわち，当の仕様を，この文書に概説した制約に適合しないことを注記するように`改変する$xことに加えて、特色機能の適合的~versionを提供して，既存の利用者をその新たな~versionに移行してもらう計画が開発されるべきである。 ◎ If such a feature is in wide use, we recommend that the existing functionality be deprecated; the specification should be modified to note that it does not conform to the restrictions outlined in this document, and a plan should be developed to both offer a conformant version of the feature and to migrate existing users into that new version.
7.4.1. 例： Geolocation
`GEOLOCATION-API$r は、そのような特色機能の格好の具体~例である。 それは、広範に実装され，多数の非保安的~siteで利用されている。 適度な移行過程は、次の様になるであろう： ◎ The [GEOLOCATION-API] is a good concrete example of such a feature; it is widely implemented and used on a large number of non-secure sites. A reasonable path forward might look like this:
-
`保安的~文脈$に対する検査を含めるように，仕様~内の［ `getCurrentPosition()$m ／ `watchPosition()$m ］~algoを実行する前の箇所に次を挿入するように`改変する$x： ◎ Modify the specification to include checks against secure context before executing the algorithms for getCurrentPosition() and watchPosition().
-
~UAは次を走らすべきである：
-
~IF［ `現在の設定群~obj$は`保安的~文脈$でない ］：
- 次を引数に，渡された %errorCallback を呼出す ⇒ 次のようにされた新たな `PositionError^I ~obj ⇒ `code^m 属性 ~SET `PERMISSION_DENIED^m
- ~RET
-
-
- ~UAは、［ 非保安的~文脈に対しては、~APIを特定の日付にて不能化すること ］の明白な意向を公告した上で、それに則って開発者にも（例えば ~console~messageを介して）警告するべきである。 ◎ The user agent should announce clear intentions to disable the API for non-secure contexts on a specific date, and warn developers accordingly (via console messages, for example).
-
~UAは、その日が来る前に，非推奨~についての期日を公告して、［ ~site作者に，~codeが道連れに機能停止する前に改変する必要を認識してもらう ］こと, および［ さしあたり，利用者を保護する ］ことを確保するべきである。 そのような計画は、次のうちいくつかを含むであろう： ◎ Leading up to the flag day, the user agent should announce a deprecation schedule to ensure both that site authors recognize the need to modify their code before it simply stops working altogether, and to protect users in the meantime. Such a plan might include any or all of:
- 非保安的~生成元を是認するような持続的~許可を不許可にする。 ◎ Disallowing persistent permission grants to non-secure origins
- 非保安的~生成元に対しては、~APIの精度を粗くする（おそらく，地番~levelでなく府県~levelの~dataを一貫して返すようにするなど）。 ◎ Coarsening the accuracy of the API for non-secure origins (perhaps consistently returning city-level data rather than high-accuracy data)
- 利用者や~site作者に~riskを伝えるような，~UIの改変。 ◎ UI modifications to inform users and site authors of the risk
8. 謝辞
この文書は、 Chrome Security ~teamによる `POWERFUL-NEW-FEATURES$r に対する 仕事に大きく基づいている。 特に従事されていた `Chris Palmer, Ryan Sleevi, David Dorwin^en 各氏に。 とりわけ参考になる~feedbackを寄せられた `Anne van Kesteren, Jonathan Watt, Boris Zbarsky, Henri Sivonen^en 各氏にも。 ◎ This document is largely based on the Chrome Security team’s work on [POWERFUL-NEW-FEATURES]. Chris Palmer, Ryan Sleevi, and David Dorwin have been particularly engaged. Anne van Kesteren, Jonathan Watt, Boris Zbarsky, and Henri Sivonen have also provided very helpful feedback.