仕様書

TLS 必須の機能

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

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

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

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

[87] 保安文脈と非保安文脈で分断される機能

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

判定

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

  1. [89] 文脈オブジェクトの関連設定群オブジェクトの文脈的保安を返します >>82。

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

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

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

  1. [92] 大域を、設定群の大域オブジェクトに設定します。
  2. [93] 大域が WorkerGlobalScope の場合、
    1. [94] 大域の所有者集合の各文書文書について、
      1. [95] 文書の関連設定群オブジェクトの文脈的保安が偽の場合、
        1. [96] 偽を返し、ここで停止します。
  3. [98] それ以外の場合、
    1. [99] 文書を、設定群の有責文書に設定します。
    2. [102] 設定群のHTTPS状態が deprecatedHTTPS状態 の場合、
      1. [101] 偽を返し、ここで停止します。
    3. [100] 文書の親閲覧文脈が null でなく、 文書の親閲覧文脈の活性文書の関連設定群オブジェクトの文脈的保安が偽の場合、
      1. [103] 偽を返し、ここで停止します。
    4. [104] 文書の活性砂箱化フラグの砂箱化起源閲覧文脈フラグが真で、 設定群の作成子URLについて Is url potentially trustworthy? が Not Trustworthy の場合、
      1. [105] 偽を返し、ここで停止します。
    5. [106] 文書の活性砂箱化フラグの砂箱化起源閲覧文脈フラグが偽で、 設定群の起源環境設定群オブジェクトの起源が潜在的に信頼できる起源でない場合、
      1. [107] 偽を返し、ここで停止します。
  4. [108] 真を返します。

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

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

  1. [132] URL が about:blank または about:srcdoc の場合、
    1. [133] 真を返し、ここで停止します。
  2. [134] URL の schemeURL scheme が datadata: の場合、
    1. [135] 真を返し、ここで停止します。
  3. [136] URL の起源URLの起源が潜在的に信頼できる起源か否かを返します。
[137] blob: や filesystem: のとき、 URLの起源は作成元の起源になりますので、その信頼できるかどうかが引き継がれます。

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

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

  1. [111] 起源が不透明起源の場合、
    1. [112] 偽を返し、ここで停止します。
  2. [113] 起源のschemeURL schemeが httpshttps: か wsswss: の場合、これは a priori authenticated URL に相当します。
    1. [114] 真を返し、ここで停止します。
  3. [115] 起源のホストURL hostが 127.0.0.0/8 または ::1/128 に一致する場合、
    1. [116] 真を返し、ここで停止します。
  4. [117] 起源のホストURL hostが localhost であるかまたは .localhost で終わるものであって、 利用者エージェントが let-localhost-be-localhost 名前解決規則を使う場合、
    1. [118] 真を返し、ここで停止します。
  5. [119] 起源のschemeURL schemeが filefile: の場合、
    1. [120] 真を返し、ここで停止します。
  6. [121] 起源のschemeURL schemeが、 利用者エージェントが認証済とみなすURL schemeの場合、
    1. [122] 真を返し、ここで停止します。
  7. [123] 起源が信頼できる起源trustworthy originと設定信頼できる起源の設定されている場合、
    1. [124] 真を返し、ここで停止します。
  8. [125] 偽を返します。

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

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

SecureContext 拡張属性

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

歴史

特別な HTTPS の時代

[147] WebKit Page Cache I – The Basics | WebKit, https://webkit.org/blog/427/webkit-page-cache-i-the-basics/

As a result, in an effort to err on the side of extreme caution, WebKit has disallowed all HTTPS sites from its Page Cache since the very beginning.

[146] どこでもはてなスター

強力機能の制限

[140] 非保安文脈への強力な新機能追加の停止は Chrome 開発チームによって提唱されました。 >>2

[1] MIX: Introduce a definiton of 'authenticated origin/environment'. · 5e594d0 · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/5e594d044ecf9a1b87a082e768adf02bb600bb52

[2] Prefer Secure Origins For Powerful New Features - The Chromium Projects ( ( 版)) http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features

[3] Defining secure-enough origins. ( (Mike West 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0107.html

[4] Bug 25972 – Please require a secure origin ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972

[5] MIX: 'data:' and 'javascript:' are not authenticated origins. · c17d4f4 · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/c17d4f4c2dd33b2d2d280f40b36d79ceef942a15

[6] Proposal: Prefer secure origins for powerful new web platform features ( (Chris Palmer 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0222.html

[7] Re: Proposal: Prefer secure origins for powerful new web platform features ( (Chris Palmer 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0078.html

[8] IRC logs: freenode / #whatwg / 20140928 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140928#l-228

[9] IRC logs: freenode / #whatwg / 20141001 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20141001

[10] IRC logs: freenode / #whatwg / 20141031 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20141031#l-377

[11] MIX: Rework the 'powerful features' algorithms. · ab1894a · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/ab1894a2ad9b9155c1d1e5a2281e354f0d30a3ed

[12] POWER: Strawman 'powerful features' document. · 3c1b2f6 · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/3c1b2f63ac14de88dc7ccf3966e5959446d98986

[13] "Requirements for Powerful Features" strawman. ( (Mike West 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0315.html

[14] Requirements for Powerful Features ( ( 版)) https://w3c.github.io/webappsec/specs/powerfulfeatures/

[15] MIX: Drop powerful features. · 52a9881 · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/52a9881829877ebe7ee9a7aad340f873d9b99210

[16] Requirements for Powerful Features ( ( 版)) http://www.w3.org/TR/2014/WD-powerful-features-20141204/

[17] Proposal: Marking HTTP As Non-Secure ( (Chris Palmer 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0062.html

[18] Privileged context features and JavaScript (Anne van Kesteren 著, 版) https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0142.html

[19] Secure Contexts: It's worth taking another look. (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0068.html

[20] Secure Contexts ( 版) https://w3c.github.io/webappsec-secure-contexts/

[21] w3c/webappsec-secure-contexts ( 版) https://github.com/w3c/webappsec-secure-contexts

[22] Defining secure global objects. · w3c/webappsec-secure-contexts@d676950 ( 版) https://github.com/w3c/webappsec-secure-contexts/commit/d67695029560dd9d635495f973c4c369a39301ee

[23] Replace "potentially secure origins" with "secure contexts" · w3c/webappsec-subresource-integrity@b2ee530 ( 版) https://github.com/w3c/webappsec-subresource-integrity/commit/b2ee530a405afeeacd4108e7aaeba93da7a9e6ee

[24] Discuss the `[SecureContext]` attribute. · w3c/webappsec-secure-contexts@6ad8e91 ( 版) https://github.com/w3c/webappsec-secure-contexts/commit/6ad8e91b895bc06415e3e50e9654822989f448ac

[26] Interact with BLE devices on the Web | Web Updates - Google Developers ( 版) https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web

Because the Web Bluetooth API is a powerful new feature added to the Web, Google Chrome aims to make it available only to secure contexts.

[27] Use [SecureContext] before it's cool · whatwg/storage@67fcb15 ( 版) https://github.com/whatwg/storage/commit/67fcb1510a03afce89f1542203f783103c0c1407

[28] Merge branch 'secure-context' into gh-pages · heycam/webidl@710b36c ( 版) https://github.com/heycam/webidl/commit/710b36c501ffd130bb4e7b9af43d9be4981a6631

[29] Secure Contexts ( 版) https://www.w3.org/TR/2016/WD-powerful-features-20160413/

[30] Re: [secure-contexts] `*.localhost` + DNS ( (Mike West著, )) https://lists.w3.org/Archives/Public/public-webappsec/2016May/0009.html

A better solution, I think, is for browser vendors to provide an override

mechanism for origins you specifically care about: Chrome

has `--unsafely-treat-insecure-origin-as-secure="

http://project.laptop.example.com"`, and I assume Safari, Opera, Firefox,

and Edge could be prevailed upon to provide similar controls as suggested

in https://www.w3.org/TR/secure-contexts/#development-environments.

[31] Remove support for [Constructor] on dictionaries (fixes #109). ( (Ms2ger著, )) https://github.com/heycam/webidl/commit/1982dc3f17002c07f93b39e22f69846478e4a9e2

[32] Clarify recommendation for restricting new features. (mikewest著, ) https://github.com/w3c/webappsec-secure-contexts/commit/f99c8970d432647a23fe65e3913fb5202d4561a9

[33] Secure Contexts () https://www.w3.org/TR/2016/WD-secure-contexts-20160718/

[34] Rewrite algorithm to handle sandboxes inside 'http://127.0.0.1/' (mikewest著, ) https://github.com/w3c/webappsec-secure-contexts/commit/4e14df58c1148bcb448992d4b579a50f4f881051

[35] Secure Contexts () https://www.w3.org/TR/2016/WD-secure-contexts-20160719/

[36] CfC: Transition "Secure Contexts" to CR; deadline August 2nd. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0032.html

[37] Re: CfC: Transition "Secure Contexts" to CR; deadline August 2nd. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2016Aug/0001.html

[38] Reference 'Securing the Web' (mikewest著, ) https://github.com/w3c/webappsec-secure-contexts/commit/9562a4b1bffe99fff8eca6207234bb672e8233cb

[39] Secure Contexts () https://www.w3.org/TR/2016/CR-secure-contexts-20160915/

[40] Adding [SecureContext] extended attribute. (tobie著, ) https://github.com/w3c/sensors/commit/9af53599d8bbe1c1a3bc1df1d3cd1b486bc3c6f3

[41] DeviceOrientation Event Specification () https://w3c.github.io/deviceorientation/spec-source-orientation.html#security-and-privacy

fire events only on secure browsing contexts [SECURE-CONTEXTS],

[42] draft-thomson-http-omnomnom-00 - Expiring Aggressively Those HTTP Cookies () https://tools.ietf.org/html/draft-thomson-http-omnomnom-00

[43] Merge pull request #55 from w3c/issue-52-secure-context (mikewest著, ) https://github.com/w3c/webappsec-credential-management/commit/7988cf32aab6b69a1522763cb1911d781ba995fd

[44] Deprecations and Removals in Chrome 58  |  Web  |  Google Developers ( ()) https://developers.google.com/web/updates/2017/03/chrome-58-deprecations

[45] Google Online Security Blog: Next Steps Toward More Connection Security () https://security.googleblog.com/2017/04/next-steps-toward-more-connection.html

[46] Linked Data Notifications () https://linkedresearch.org/ldn/#authenticated-inboxes

Authentication involving token passing must be done over HTTPS.

[47] Deprecations and Removals in Chrome 60  |  Web  |  Google Developers () https://developers.google.com/web/updates/2017/06/chrome-60-deprecations

[48] mikewest/http-is-https: Post-`forbes.com`, I think we can say that "http" => "https". () https://github.com/mikewest/http-is-https

[49] Google ウェブマスター向け公式ブログ: Chrome の HTTP 接続におけるセキュリティ強化に向けて () https://webmaster-ja.googleblog.com/2017/07/next-steps-toward-more-connection.html

[50] Merge pull request #284 from beverloo/secure-context (martinthomson著, ) https://github.com/w3c/push-api/commit/976d9161c723eed1e8fea173c8c46215250111f7

[51] Merge pull request #109 from andrey-logvinov/restrict-to-secure-context (andrey-logvinov著, ) https://github.com/w3c/wake-lock/commit/8dbbf28db9456cb13dbdf289e4d4ec1e094f406e

[52] Restrict Wake Lock API to secure context by andrey-logvinov · Pull Request #109 · w3c/wake-lock () https://github.com/w3c/wake-lock/pull/109

[53] Deprecations and Removals in Chrome 61  |  Web  |  Google Developers () https://developers.google.com/web/updates/2017/08/chrome-61-deprecations

[54] RFC 3744 - Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol () https://tools.ietf.org/html/rfc3744#section-13

Implementation of the ACL spec requires that Basic authentication, if

used, MUST only be supported over secure transport such as TLS.

[55] Remove the 'opener' restriction. (mikewest著, ) https://github.com/w3c/webappsec-secure-contexts/commit/98f2c2634f7371bca6ffacbf73e984b22af521ab

[56] Should opener be taken into consideration when determining if a context is secure? · Issue #42 · w3c/webappsec-secure-contexts () https://github.com/w3c/webappsec-secure-contexts/issues/42

[57] Cleaning up algorithms and issues. (mikewest著, ) https://github.com/w3c/webappsec-secure-contexts/commit/2cc0b2f634b5062f82d540349233d30cab84e0c3

[58] Merge pull request #315 from pozdnyakov/remove_explicit_secure_contex… (pozdnyakov著, ) https://github.com/w3c/sensors/commit/74e879fb672965a527505be048b0a1abc8218ae9

[59] Remove the extra secure context check by pozdnyakov · Pull Request #315 · w3c/sensors () https://github.com/w3c/sensors/pull/315

[60] Editorial: Clarifying secure context integration with Shared Workers (mikewest著, ) https://github.com/whatwg/html/commit/6f9d81839133072355c15efa4b934beaf85ea259

[61] Editorial: Clarifying secure context integration with Shared Workers. by mikewest · Pull Request #3243 · whatwg/html () https://github.com/whatwg/html/pull/3243

[62] Add support for interface mixins (tobie著, ) https://github.com/heycam/webidl/commit/45e8173d40ddff8dcf81697326e094bcf8b92920

[63] What is the expected interaction of [SecureContext] with mixins? · Issue #118 · heycam/webidl () https://github.com/heycam/webidl/issues/118

[64] Secure Contexts Everywhere | Mozilla Security Blog () https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/

[65] Reintroduce the dependency on a parent's security. (#55) (@bzbarsky著, ) https://github.com/w3c/webappsec-secure-contexts/commit/322bd8fa3dfde726715776e93787d2e76eeb320f

[66] Should secure iframes of insecure parents be considered secure? Spec is self-contradictory. · Issue #54 · w3c/webappsec-secure-contexts () https://github.com/w3c/webappsec-secure-contexts/issues/54

[67] Reintroduce the dependency on a parent's security. by mikewest · Pull Request #55 · w3c/webappsec-secure-contexts () https://github.com/w3c/webappsec-secure-contexts/pull/55

[68] Google Developers Japan: ウェブ上の安全なアプリのホーム、.app のご紹介 () https://developers-jp.googleblog.com/2018/05/introducing-app-more-secure-home-for.html

[69] Deprecations and removals in Chrome 69  |  Web  |  Google Developers () https://developers.google.com/web/updates/2018/09/chrome-70-deps-rems

[70] Deprecating Non-Secure HTTP | Mozilla Security Blog () https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

[71] Restrict application caches to secure contexts (annevk著, ) https://github.com/whatwg/html/commit/81344cc9f567bfafaed57805fd9cdf9f4a4237bf

[72] Clarify the restrictions on SecureContext combinations. (#763) (Ms2ger著, ) https://github.com/heycam/webidl/commit/5c57dc1688fb13ca57015c956b0326b6ef71e637

[73] Clarify the restrictions on SecureContext combinations. by Ms2ger · Pull Request #763 · heycam/webidl () https://github.com/heycam/webidl/pull/763

[74] [SecureContext] handling for mixins seems to be slightly broken · Issue #762 · heycam/webidl () https://github.com/heycam/webidl/issues/762

[75] Clarify the relation between the secure context definitions. (Ms2ger著, ) https://github.com/heycam/webidl/commit/fa38f6cc151c7fbf4ecbfb47ce67e13882519b3d

[76] Clarify the relation between the secure context definitions. by Ms2ger · Pull Request #785 · heycam/webidl () https://github.com/heycam/webidl/pull/785

[77] Add async_iterable support (Ms2ger著, ) https://github.com/heycam/webidl/commit/d6caf50f9e21b467dfe54ee37b443f96c09f7333

[81] w3c/webappsec-secure-contexts: WebAppSec Secure Contexts () https://github.com/w3c/webappsec-secure-contexts

[127] SECURE:APIを紹介します。 ・W3C / webappsec @ 7dc0655 ( 版) https://github.com/w3c/webappsec/commit/7dc065520e76668ef87111780ce2762629581ee9

[128] SECURE: Use the getter's global · w3c/webappsec@0bf1021 ( 版) https://github.com/w3c/webappsec/commit/0bf1021910b54268d7efc2ecdb874f00ec49a4e4

[129] Update 'isSecureContext' definition. (@domenic著, ) https://github.com/w3c/webappsec-secure-contexts/commit/040600a350763ea0fdf679df2f9eff7cdc2343aa

[130] Cleaning up algorithms and issues. (mikewest著, ) https://github.com/w3c/webappsec-secure-contexts/commit/2cc0b2f634b5062f82d540349233d30cab84e0c3

[142] Restrict (un)registerProtocolHandler to secure contexts (ericlaw1979, , ) https://github.com/whatwg/html/commit/6772a0342e6ffebc922c60c770dce87371b6c968

[143] Add SecureContext limitation for [un]registerProtocolHandler API by ericlaw1979 · Pull Request #5080 · whatwg/html () https://github.com/whatwg/html/pull/5080

[144] Secure contexts · Issue #23 · WICG/uuid () https://github.com/WICG/uuid/issues/23

[145] should URLPattern require a SecureContext? · Issue #29 · WICG/urlpattern () https://github.com/WICG/urlpattern/issues/29

[148] 最近の Chrome はシークレットウィンドウで http: へ navigate するとその旨のエラー画面を表示し、そこでボタンを押すと実際に navigate します。再読込や同じ起源の navigate でも、必ずではないものの高確率で (条件不明) 同じエラー画面を表示します。うざすぎます。リスクを受け入れる選択をした利用者に対する使いづらさのバランスが悪いですね。