起源

起源 (Web)

[24] Webのセキュリティーモデルである同一起源ポリシー (same-origin policy) において、 URLドメイン等によって定まる資源の管理の単位を起源 (オリジン) (origin) といいます。

[85] 同一起源ポリシーの項もご覧ください。

[292] 起源は、URL schemeホストポートなどによって決まる資源群の範囲であり、スクリプトなどが通常相互にアクセスできる領域を定めるものとなっています。

[310] 例えば <http://www.example.com/hoge?aa>iframe<http://www.example.org/fuga?bb> が埋め込まれているとします。外側の Window起源(http, www.example.com, 80) で、内側の Window起源(http, www.example.org, 80) です。両者は異なる起源に属しますから、 一方のスクリプトから他方の DOM にはアクセスできません。

仕様書

[293] 以前は RFC 6454 >>23 に定義がありましたが、 現在では事実上廃止されたものとみなされています。 IETF の手続き上は未だに現行仕様扱いになっているので、 気付かずに参照する人がいます。 しかし内容が数世代古く曖昧なところもありますから、 注意が必要です。

呼称

[5] 起源 (origin) は、日本語生成元源泉オリジンなどと訳されることもあります。 起源セキュリティーモデルはデータの出所に基づきセキュリティー的なデータの分離境界を定めるものであり、 「起源」の語にもこの“データの出所”のような意味があります。

起源オブジェクト

[25] 起源 (origin) は、 不透明起源または項組起源です >>135

[50] Webブラウザーアドレスバーdata: URL を指定して開かれた文書の起源は、その時点で新たに作成された不透明起源です。

[8] 起源は、オブジェクトです。複数の箇所から同じ起源オブジェクトが参照されることがあります。 例えば複数の文書起源が同じオブジェクトに設定されるかもしれません。 その場合、当然ながら起源オブジェクトの編集はすべての参照箇所に影響します。

[47] 起源の複製が他の箇所に設定されることもあります。 これは複製時点の起源オブジェクトの構成値が同じ新しいオブジェクトを作ることを意味します。 その後一方の起源オブジェクトを編集しても、他方には波及しません。

[48] document.domain に値を設定すると、 起源オブジェクトが編集されることがあります。

[79] 起源には、実効ドメインが定義されます。

[226] 2016年の改訂までは起源を他の起源の「別名 (alias) 」 とできるとされ、 document.domain の動作を説明するために用いられていましたが、 実際にはこの方法ではうまく説明できないことがわかり、改められました。

項組起源

[2] 項組起源 (tuple origin) は、 schemeホストポートドメインで構成される項組です >>135

[73] 項組起源オブジェクトは、 URL から作られます。 この元となる URLURLの構文解析により正規化した結果なので、 起源の各項も、正規化済みの値になります。

[74] scheme は、すべて小文字です。

[75] ホストは、すべて ASCII小文字です。

[76] ポートは、整数null です。既定のポート番号は使わずに null とします。

[39] HTTP などで起源をやり取りする必要がある時は、 URL の構文の部分集合によって直列化して表します (>>160)。

[40] 例えば http://www.example.com/foo/bar起源は (http, www.example,com, 80) の3項組によって表されます。 これを HTTPOrigin: 欄に含める時は、 http://www.example.com と表現します。

[78] かつては URL schemeホストポートの3項だったので、 3項組 (triple) ということもありました。

[19] かつてはポートは「手動上書き」なる特別な値を取ることがありました。 これは document.domain の規定に使われていましたが、 実効スクリプト起源起源の統合により、 特別な値を使わない形に改められました。

不透明起源

[3] 不透明起源 (opaque origin) は、 何らかの内部的な値で表されます >>135。 自身 (同じ起源オブジェクトやその複製として作られた起源オブジェクト) とは同じとみなされますが、それ以外とは異なるとみなされるものです。

[38] 不透明な識別子は利用者エージェントの外やスクリプトに露出することが無いので、 特定プロセス内の連番など任意の方法で決定できます。 他の起源と同じか異なるかさえ判断できれば、どんな方法で実装しても構いません。

[37] かつては、 不透明な識別子 (opaque identifier) 大域的に固有な識別子 (globally unique identifier) と呼ばれていました。

[4] 不透明起源は、直列化できません。 null や値なしなどとして表す場合もありますが、いったんそうするとどの不透明起源を表していたかはわかrなくなります。

その他の起源

[100] 仕様上はありませんが、実装上はそれ以外の起源も存在するかもしれません。

[104] file: は実装依存の独自形式の起源かもしれません。

[111] jar: が実装されている場合、独自形式の起源かもしれません。

[116] ブラウザー拡張が実装されている場合、項組起源かもしれませんし、 独自形式の起源かもしれません。

[140] テレビ業界は独自の URL scheme を使っており、 独自の起源を規定しています。

比較

[150] 起源 A起源 B同じ起源 (same origin) であるとは、 次の手順を返すことを言います >>135

  1. [98] AB が共に不透明起源なら、
    1. [109] AB が同じなら、を返してここで停止します。
  2. [101] AB が共に項組起源なら、
    1. [102] ABschemeホストポートがそれぞれ同じなら、を返してここで停止します。
  3. [105] を返します。

[106] 不透明起源項組起源の比較は、常にを返します。 項組起源ドメインは、無視されます。 項組起源ポートnull となることもありますが、 null 同士なら、一方のみ null ならを返します。 起源schemeホストポートは作成時点で正規化されているので、 比較の際の正規化は不要です。

[153] 同じ起源であるかどうかとは、基本的にはその対象の出自が同じサーバーであるかどうかを表しています。 Webセキュリティーの最も基礎となる関係です。


[107] 起源 A起源 B同じ起源ドメイン (same origin-domain) であるとは、 次の手順を返すことを言います >>135

  1. [110] AB が共に同じ不透明起源なら、
    1. [108] AB が同じなら、を返してここで停止します。
  2. [112] AB が共に項組起源なら、
    1. [113] ABドメインが共に null なら、
      1. [117] ABschemeホストポートがそれぞれ同じなら、を返してここで停止します。
    2. [114] ABドメインが共に null 以外なら、
      1. [115] ABschemeドメインがそれぞれ同じなら、 を返してここで停止します。
  3. [105] を返します。

[154] 同じ起源ドメインであるかどうかとは、同じ起源かどうかと多くの場合は一致しますが、 document.domain を考慮する点が異なっています。

[207] 同一起源でないことを起源横断 (クロスオリジン) (cross-origin) であるといいます。

[159] RFC 6454 の定義 (>>81) とは違って HTML Standard の定義はすべての場合を明確に規定していました。

[97] HTML Standard は追加データが同一であることも同じ起源の条件としていました。

[92] その後2016年3月に実効スクリプト起源との統合で改訂され、 同じ起源ドメインの比較方法も新たに規定されました。

直列化

[160] 起源直列化 (文字列化) は、 1つのASCII文字列起源を表現するものです。

[11] 不透明起源null と表現されます。 直列化から元の起源を復元することはできなくなります。

[96] 項組起源ドメインは、直列化に反映されません。

ASCII 直列化

[88] 起源起源直列化 (serialization) (旧ASCII直列化 (serialization) ) は、 次のようにして得られる文字列です >>135

  1. [99] 起源不透明起源なら、
    1. [61] null を返します。
  2. [62] それ以外なら、
    1. [63] 起源項組起源として直列化した結果を返します。

[64] かつての RFC >>25 6.1. は、項組起源の場合にホストをそのまま出力するとしていました。

[65] かつての HTML Standard >>135 は、 項組起源の場合にホストIDNA2003 ToASCII 演算を適用た結果を出力するとしていました。 この時、 AllowUnassignedUseSTD3ASCIIRules の2つのフラグは設定した状態にすることとされていました。 またホストのいずれかの部品ToASCII が失敗したら、 空文字列を返して直列化手続きを停止することになっていました。

[141] HTML の定義に従えば、 LDHラベル化できない host だった場合に起源空文字列によって表されることになります。 RFC の定義によれば空文字列になることはありません。

[66] HTML Standard の定義はその後 URL Standard の演算を参照する形となりました。

[67] 更に2016年3月には、 URL Standard に合わせて再度整理されました。 起源オブジェクトの作成時に使われた URL が既に URLの構文解析時点で ASCII 形に正規化されているため、ASCII直列化時点での演算は不要となっています。

[21] 起源を構成する URL schemehost は元々小文字に正規化されているはずですから、 ASCII直列化もすべて小文字となるはずです。

[298] これは次の場面で使われています。

項組起源の直列化

[69] ASCII直列化Unicode直列化における項組起源起源直列化は、 次のものを順に連結した文字列です >>135

  1. 起源scheme
  2. ://
  3. 起源ホストホスト直列化器を適用した結果
  4. 起源ポートnull でない場合、
    1. :
    2. 起源ポート整数の直列化を適用した結果

[103] かつての RFCHTML の定義では、 既定のポート番号と等しい場合にはポートを付加しない、 という規定になっていました。

[70] 2016年3月の改訂により、既定のポート番号の場合の起源ポート番号null と (仕様書上は) 扱われるよう整理されたため、 現在は null かどうかの分岐になっています。

[71] かつての RFCHTML の定義ではポート番号を最小の桁数で (つまり先導0なしで) 表現するよう要求していませんでしたが、 この整理により明確化されました。

file: URL の起源の直列化

[200] file: URL起源は実装依存となっており (>>31)、 そもそもそれがどのような形で表されるのか不明確です。項組起源かもしれませんし、 不透明起源かもしれません。どちらでもない独自の形式かもしれません (それが仕様上明確に認められているわけではありませんが)

[201] 直列化の算法を素直に適用すれば、 null が得られるはずです。 しかし実装はそれ以外の値を使うことがあります。

[124] file: 参照。

特別な値

[208] Access-Control-Allow-Origin: 欄では任意の起源を表す * という特別な値も認められています。

[142] Blob URLの直列化では null の場合にかわりに実装定義の値が使われることになっています。 実際には完全に任意の値とできるわけではなく、項組起源と衝突しない値であることが期待されます。

[31] postMessage では、著者 (スクリプト) が起源を指定するために URL (または特別な値 */) を使っています。

IDNA との関係

[91] IDNAauthority も参照。

[120] IDN について、起源の定義が URI であることから起源の決定に ToASCII が必要となる場合があること、Unicode直列化を使う場面があることから起源の表記のために ToUnicode が必要となる場合があることにより、起源IDNA に依存しています。

[122] RFC 上の起源の定義は IDNA2008 に拠っていますが、 IDNA2003IDNA2008 のどちらを実装するかによって結果が異なることへの注記もあります >>23 8.4HTML起源の定義は IDNA2003 に拠っています。 現実のWebブラウザーが実装しているものは厳密にはどちらの仕様とも異なっています。

その他の直列化

[296] ASCII直列化できないhostを含む起源空文字列によって表されます。

[297] RFC 6454 の定義ではそのような起源の存在は考慮されていませんでした。


[136] 起源直列化については、 RFC 6454HTML で微妙に定義が異なっていました。 >>25 6., >>135 [137] 元々 HTML にあった定義をコピーして IETF 版を作った時に政治的な理由か何かで書き換わったのでしょう。


[20] ポートの特別な値「手動上書き」の直列化の方法は規定されていませんが、 これを直列化しなければならない場面は無いと思われます。

[89] 起源起源Unicode直列化 (serialization) は、 次のようにして得られる文字列です >>135

  1. [90] 起源不透明起源なら、
    1. [9] null を返します。
  2. [52] それ以外なら、
    1. [53] ホストを、起源ホストに設定します。
    2. [55] ホストドメインなら、
      1. [54] ホストを、ホストdomain to Unicode を適用した結果に設定しま す。
    3. [58] 項組起源 (起源scheme, ホスト, 起源ポート) を直列化した結果を返します。
  3. [56] それ以外なら、
    1. [57] 起源項組起源として直列化した結果を返します。

[59] かつての RFC >>25 6.1.HTML >>135 は、ホスト部分の直列化を次のように規定していました。

  1. [93] 起源ホストの各部品を次の手順により変換しつつ、 . で連結して返します。
    1. [139] RFC の定義:
      1. [94] 部品が IDNA2008 Aラベルなら、対応するUラベルにします。
      2. [95] そうでなければ、部品をそのまま使います。
    2. [138] HTML の定義: 部品に IDNA2003 ToUnicode 演算を適用します。

[60] HTML Standard の定義はその後 URL Standard の演算を参照する形に変更されました。

[68] 更に2016年3月に改めて URL Standard の規定に基づき整理されました。

[299] これは次の場面で使われていました。

[12] Unicode直列化Mozilla では実装されていたものの、 他の Webブラウザーでは実装されていませんでした。 ASCII直列化に統合される形で廃止されました。


[16] HOBA は、独自の直列化の方式を規定しています。 RFC 3986 URI から URL schemeauthority (hostname の意か?)、 port を連結したもの >>17 とされています。ただし既定のポート番号はなく、 必ず port を明示する必要があります >>17

[18] なぜ素直に標準的なASCII直列化を使わないのかは謎です。

概念やオブジェクトの起源

[6] Web 上の色々なオブジェクト概念に対して起源が定義されています。

XMLHttpRequest 起源

[234] XMLHttpRequest起源 (origin) は、基本的には XMLHttpRequest文書起源です。 >>232, >>231 つまりは XMLHttpRequest に対応する Window オブジェクト文書起源です。

[230] ワーカーにあっては、 XMLHttpRequest 起源 (origin) スクリプト起源です >>229

[235] 匿名フラグが立っている場合は、大域的に固有な識別子です。 >>232

[236] XMLHttpRequest 起源は、 XHR要求する資源同じ起源かどうかの判定に使われます。また、 responseXMLDocument起源としても使われます (文書の起源参照)。

スタイルシートの起源

分類

[41] 起源は、その性質により次のように分類されることがあります。

起源と適用範囲が異なる機能

[10] Web 上のいくつかの機能は、歴史的その他の理由で起源とは異なる適用範囲を持っています。 場合によってはセキュリティー上の問題となることがありますから、 注意が必要です。

[126] 同一起源ポリシーの適用対象外の項も参照してください。

[118] ブラウザー拡張ウィジェットアプリ内ブラウザーWebDriver といった類のものは必ずしも同一起源ポリシーに縛られず、 実装依存のセキュリティーモデルで管理されています。

関連

[155] 部分起源も参照。

[128] HTTP起源サーバーとは、語源は同じなのでしょうが、 意味は必ずしも一致しません。

[129] 座標系起源とは無関係です。

歴史

[227] 起源 (や SOP) の概念は Netscape による JavaScript の開発以来、 次第に明確になってきましたが、長らく仕様として文書化されるには至りませんでした。 しかし2000年代の後半になり、ようやく RFC 6454HTML によってその仕様が正確に記述されることとなりました。

RFC 6454 における同一起源の定義

[81] 2つの起源が「同じ (same) 」である時、その時に限って同一 (identical) です。 具体的には、

  • [82] 2つの起源が共に scheme/host/port3項組であるなら、 3つがそれぞれ同一 (identical) であるなら、その場合に限って同じ (same) です。
  • [83] 大域的に固有な識別子は、 scheme/host/port3項組同じ (same) であることはありません。

... と定義されています。 >>23 5.

[87] あまり意味がないからか自明だからか仕様上明記されていませんが、起源が共に大域的に固有な識別子である時も、 それが同じ値であるなら、その場合に限って、同じ起源であるはずです。

[84] 2つのURLは、その起源同じ (same) なら、同一起源 (same-origin) です。 >>23 5.

[86] 同じURLであるからといって起源も同じとは限りません。例えば data: URL は毎回新しい大域的に固有な識別子が割り振られるため、違う起源になります。

RFC 6454 における URI の起源の定義

[26] ある RFC 3986 URI起源は次の手順により求められます >>23 4.

  1. [27] URL階層的でない、または絶対URLでないなら、新しい大域的に固有な識別子を生成し、 それを返します。
  2. [28] url-scheme を、 URLscheme 部分を小文字化したものとします。
  3. [29] 実装が url-scheme により表されるプロトコルに対応していないなら、 新しい大域的に固有な識別子を生成し、それを返します。
  4. [30] url-schemefile なら、 実装定義の値を返して構いません
  5. [32] url-host を、 URLhost 部分を小文字化したものとします。
  6. [33] URLport 部分がなければ、
    1. url-port を、 url-scheme で表されるプロトコル既定のポートとします。
  7. [34] そうでなければ、
    1. url-port を、 URLport 部分とします。
  8. [35] (url-scheme, url-host, url-port) の3項組を返します。

[36] 仕様上明記されていませんが、 >>32>>34hostport正準化する必要がありそうです。
[121] 仕様上厳密には RFC 3986 URI に対して起源が定義されており、 URI でない URL (IDN を使ったものなど) はまず URI に変換 (できれば) する必要があります。 URI に変換できない URL については起源が定義されていないことになります。 もちろん現実の Webブラウザーにおいては、定義を自然に拡張した URL 一般について同様に起源が定義されることになります。
[163] 以前は HTML の仕様書で URL に対して起源が定義されていましたが、 RFC に委ねるとして削除されてしまいました。

追加のデータ

[143] RFC 6454 では3項組だけでしたが、 HTML によれば更に場合によっては追加のデータ (extra data / additional data) を加えることができます。

[145] 追加のデータとしては、暗号化された接続を使っている時にサイト証明書 (certificate) を用いることが想定されています。 途中で証明書が変化した時に、証明書起源に含めることで、前後で別の起源として扱われるようになります。 >>135

[146] 従って中間者攻撃 (MITM) に対する防御となります。

[15] 実際にこの規定に従っている Webブラウザーが存在するのかは不明です。

[149] この規定は >>147 で追加されたもので、当時は URL起源に関する規定において証明書起源に含めても構わない状況が明記されていましたが、 >>148 で当該部分が RFC に委ねるとして削除され、しかし RFC には相当する規定が含まれなかったため、宙に浮いてしまっています。 (RFC にかわる URL Standard の定義にも、証明書は用いられていません。)

[14] 証明書を期限切れに伴い更新したり、を構成するホストごとに異なる公開鍵を提供していたり >>13 する場合に起源が変わってしまって以前に保存したデータにアクセスできなくなったり、 フレーム間で通信できなかったりすると不便であり、再現しづらい互換性の問題が生じますから、 これを起源の構成要素に加えるのはあまり好ましくないのかもしれません。

[22] PKPピンと結び付けることで証明書を超えて同一性を保てるかもしれません。 しかしそのような実装の動きも無さそうです。

[72] この規定は2016年3月の改訂で削除されました >>77

RFC 6454 の廃止

[209] Cross-Origin Resource Sharing ( ( 版)) <http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#origin-request-header>

[240] Errata for The Web Origin Concept ( (Anne van Kesteren 著, 版)) <http://lists.w3.org/Archives/Public/www-archive/2012Jun/0001.html>

[241] IRC logs: freenode / #whatwg / 20120619 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20120619#l-978>

[245] IRC logs: freenode / #whatwg / 20120718 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20120718#l-432>

[246] Web Applications 1.0 r7236 Recast how the origin handling is done for data: URLs in workers, and fix the shared worker origin handling for data: URLs so that you can actually reconnect to a data: shared worker. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=7235&to=7236>

[247] Web Applications 1.0 r7414 Require Cookies and Origin if you implement HTTP. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=7413&to=7414>

[250] [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038358.html>

[251] Define Document's origin. In related news: we now have an HTML dependenc... · 922830c · whatwg/dom ( ( 版)) <https://github.com/whatwg/dom/commit/922830c931d8b04d52e3482dfd9985cdcead43fe>

[252] Define what origin and effective script origin are in various Document c... · 2f2cdf4 · whatwg/dom ( ( 版)) <https://github.com/whatwg/dom/commit/2f2cdf4a29b7ed299c38f60eb35ed98918a7f439>

[258] Cross-Origin Resource Sharing Standard ( ( 版)) <http://fetch.spec.whatwg.org/>

[259] IRC logs: freenode / #whatwg / 20130401 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130401#l-615>

[260] IRC logs: freenode / #whatwg / 20130416 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130416#l-72>

[261] <https://github.com/whatwg/fetch/commit/05a8acd40d6f65c1a6dc830896cd8366a99d267d>

[262] IRC logs: freenode / #whatwg / 20130418 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130418#l-839>

[263] IRC logs: freenode / #whatwg / 20130508 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130508#l-108>

[264] [websec] RFC6454 (Origin) vs URI schemes unlike "http" ( ( 版)) <http://www.ietf.org/mail-archive/web/websec/current/msg01512.html>

[265] Fetch Standard ( ( 版)) <http://fetch.spec.whatwg.org/#http-origin-header>

[266] [whatwg] Reorganizing and fixing "origin" ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039599.html>

[267] [whatwg] Reorganizing and fixing "origin" ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039599.html>

[268] Web Applications 1.0 r7873 Allow data: URLs to be given download= attribute names.]] ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=7872&to=7873>

[270] [whatwg] Reorganizing and fixing "origin" ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-July/040050.html>

[271] [whatwg] Fetch: Origin header ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-July/040196.html>

[274] Bug 20701 – Location security restrictions are over-restrictive ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701>

[276] Web Applications 1.0 r8307 Fix the rules on what 'Origin' header to use when navigating to a resource in an <iframe>, <object>, <embed>, or <frame> element, so that the latter two are not forgotten. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=8306&to=8307>

[277] Bug 23005 – IDNA-related bits should instead reference terminology from http://url.spec.whatwg.org/ ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23005>

[278] Web Applications 1.0 r8320 Clarify what it means for an image to have an origin ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=8319&to=8320>

[279] Using Self-Hosted Objects - Facebook開発者 ( ( 版)) <https://developers.facebook.com/docs/opengraph/using-objects/>

[280] Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 ( ( 版)) <https://gist.github.com/mala/8857629>

[281] 446344 – Implement Origin header CSRF mitigation ( ( 版)) <https://bugzilla.mozilla.org/show_bug.cgi?id=446344>

[282] Web Applications 1.0 r8262 Move the spec from a stack of incumbent scripts to a stack of script settings object. This should in theory have no concrete effects (though I may have changed some of the origin used for Web Workers started from document.domain-affected scripts that were called from other scripts with different original origins). ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=8261&to=8262>

[290] IRC logs: freenode / #whatwg / 20140426 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140426>

[291] Bug 26152 – Would it not be better to define origin as identifier, tuple, or, alias? That alias is actually a link to another origin is not super clear this way. ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=26152>

[294] 2014年には URL起源URL Standard で定義されるようになり >>307、 実質的に URL StandardFetch StandardHTML Standard によって RFC 6454 は廃止されました >>308, >>309, >>7

[311] draft-nir-websec-extended-origin-02 - A More Granular Web Origin Concept ( ( 版)) <http://tools.ietf.org/html/draft-nir-websec-extended-origin-02>

[42] origin on HTMLHyperlinkElementUtils/Location is readonly · whatwg/html@2c97ff8 ( 版) <https://github.com/whatwg/html/commit/2c97ff8e46a86911f621ee4303d0fc18ddcb9b2b>

[45] Add ids to origin's types · whatwg/html@b870180 ( 版) <https://github.com/whatwg/html/commit/b8701806808e6fc393a92207717a8bce72a91d1d>

[46] Remove the origin aliasing concept · whatwg/html@438155d ( 版) <https://github.com/whatwg/html/commit/438155d2a2255aa5ea84ae390744d8a8662ebec2>

[51] Cleanup origin serialization · whatwg/html@5dcc1ee ( 版) <https://github.com/whatwg/html/commit/5dcc1ee2124b5e54955845790bb47f5d1351d672>

[77] Merge effective script origin into origin · whatwg/html@8a843f2 ( 版) <https://github.com/whatwg/html/commit/8a843f2169a6864a3024c4329528dccb2051d275>

[119] [css-cascade] Switch term to 'cascade origin'. Dfn the various origins. · w3c/csswg-drafts@9617cdd ( 版) <https://github.com/w3c/csswg-drafts/commit/9617cdd5e117b4674e89b799fa437441f7fd80e4>

[123] Editorial: clarify origin invariants · whatwg/html@e337726 ( 版) <https://github.com/whatwg/html/commit/e337726ec3e20c418fb062fd3650c5830acd2b22>

[125] Clarify the "no serialisation" statement for opaque origins ( (annevk著, )) <https://github.com/whatwg/html/commit/8b69a96e95d2eea28ebf0134336bc75dccafc0ed>

[35] ARIB は次のように規定しています。

[130] ARIB TR-B39 () <http://www.arib.or.jp/english/html/overview/doc/4-TR-B39v1_0-1p4.pdf#page=254>

10.1.2.1 基本オリジン

localStorage API の動作において、受信機は HTML 文書のオリジンを以下と判断することを基 本とする。

 放送伝送の HTML 文書

arib2://aid_[app_id].oid_[org_id]

※ [app_id]は、AIT における application_id を 16 進数表現した文字列。[org_id]は、AIT におけるorganization_idを16進数表現した文字列。いずれも先頭には"0x"を付加せず、 最小桁数で表現する。

 通信伝送の HTML 文書

HTML 文書の URI に基づくスキーム、ホスト、ポート。

10.1.2.2 オリジンの読み替え

不揮発性記憶領域のうち放送領域にアクセスするキーが指定された場合、実行中のデータコンテ ンツが放送マネージドアプリケーションでかつ、アプリケーションバウンダリおよびパーミッショ ンビットマップによって放送領域へのアクセスが許されていれば、受信機は HTML 文書のオリジ ンを表 10-5 の通り判断するよう読み替える。アクセスが禁止されているコンテンツでは、 SecurityError 例外が発生し、メソッドの動作は行われない。つまり、放送マネージドアプリケー ションが各放送領域にアクセスできるかどうかは、HTML 文書の URI に基づくスキーム、ホスト、 ポート、application_id、organization_id には影響されない。

一時記憶領域へのアクセスにおいては、HTML 文書のオリジンを ARIB STD-B62 第二編 3.3.5 に基づいて判断する。

キー名を引数に取らないメソッド(localStorage.key(), localStorage.clear())とプロパティ (localStorage.length)は、オリジン読み替えを行わない。つまり、その対象は基本オリジンの領 域のみとなる。これは、オリジン読み替えを行うか否かが、アクセスするアイテムのキー名によっ て判断されるためである。

document.domain 属性を書き換えた場合は、Web Storage 仕様の規定に基づき、それ以降の localStrorage オブジェクトは無効化され、関連するメソッドは動作しなくなる。

表 10-5 読み替え先オリジン

アクセス領域 読み替え先オリジン

Ureg arib://localhost (※1)

Greg arib://localhost (※1)

放送領域

放送事業者共通領域 arib2://bs_common

放送事業者専用領域 arib2://bid_[broadcaster_id].nid_[original_network_id]

視聴者居住情報領域 arib2://localhost

一般領域 読み替えしない

※1 ARIB STD-B62 第二編 3.3.5 に基づく。

※2 [broadcaster_id]は、選局中サービスの broadcaster_id を 16 進数表現した文字列。

[original_network_id]は、選局中サービスの original_network_id を 16 進数表現した文字 列。いずれも先頭に”0x”を付加せず、英字は小文字とし、最小桁数で表現する。

[144] Remove Unicode serialization of an origin (annevk著, ) <https://github.com/whatwg/html/commit/59ebd9c094d9d532458a9ee61f307bf41bc70811>

[151] ASCII serialization (mikewest著, ) <https://github.com/w3c/webappsec-csp/commit/0b236a75ddd245d0512da28f2e11311622a07ddd>

[152] Origins serialize to ASCII these days (annevk著, ) <https://github.com/whatwg/dom/commit/fba2caf4be29c30e7e03010d5fce240a729e0bed>

[156] Explicitly block opaque origins from requesting manifests (#638) (dominickng著, ) <https://github.com/w3c/manifest/commit/c586cf0ba4923489fba995d72c638bc46b7ea33d>

[157] Explicitly block opaque origins from requesting manifests by dominickng · Pull Request #638 · w3c/manifest () <https://github.com/w3c/manifest/pull/638>