[24] Webのセキュリティーモデル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 の起源は (httphttp:, www.example.com, 80) で、内側の Window の起源は (httphttp:, www.example.org, 80) です。両者は異なる起源に属しますから、 一方のスクリプトから他方の DOM にはアクセスできません。

仕様書

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

呼称

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

起源オブジェクト

[25] 起き源げんoriginは、 不透明起源または項組起源です >>135。

[49] http:、https:、ftp: の URLの起源は、項組起源です。

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

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

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

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

[168] 新しい起源 (https, example.com, 443) を作成し、 新しい起源 (https, example.com, 443) を作成すると、 どちらも同じ起源を表すとしても、 一方を編集したときに他方には影響しないという意味で、 別のものです。

[167] 例えば起源の決定を参照。

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

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

項組起源

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

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

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

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

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

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

[40] 例えば http://www.example.com/foo/bar の起源は (http, www.example,com, 80) の3項組によって表されます。 これを HTTP の Origin: 欄に含める時は、 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 を使っており、 独自の起源を規定しています。

[172] Firefox の開発ツールで fetch すると Origin: ヘッダーの値が resource://devtools になります。

[173] 開発者ツールがサーバーに観測可能なのは問題なのでは...

[176] URLの起源も参照。

比較

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

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

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

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

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

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

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

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

  • [206] Cross-Origin Resource Sharing ( 版) http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin

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

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

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

[166] 他に、より緩い比較として、 同じサイトやschemeなしで同じサイトがあります。

直列化

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

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

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

ASCII 直列化

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

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

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

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

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

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

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

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

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

  • [132] Origin: (HTTP)
  • [133] Origin: (Web Sockets)
  • [288] Access-Control-Allow-Origin: (HTTP)
  • [286] X-Frame-Options: (HTTP)
  • Timing-Allow-Origin: (HTTP)
  • ALTSVC フレームHTTP/2フレームの起源ALTSVC欄
  • Blob URLの直列化
  • origin (MessageEvent)
  • document.origin (DOM)
  • originlocation.origin (URLUtils)
  • ancestorOrigins
  • self.origin

項組起源の直列化

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

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

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

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

[71] かつての RFC や HTML の定義ではポート番号を最小の桁数で (つまり先導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] IDNA、authority も参照。

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

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

その他の直列化

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

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

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

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

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

  1. [90] 起源が不透明起源なら、
    1. [9] null を返します。
  2. [52] それ以外なら、
    1. [53] ホストを、起源のホストに設定します。
    2. [55] ホストがドメインなら、
      1. [54] ホストを、ホストに domain to Unicode を適用した結果に設定しま す。
    3. [58] 項組起源 (起源のschemeURL 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] これは次の場面で使われていました。

  • [134] origin (MessageEvent)
  • [275] document.origin (DOM)
  • [287] originlocation.origin (URLUtils)
  • ancestorOrigins
  • self.origin
  • VAPID JWT の audVAPID
  • Blob URL

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

[158] VAPID は未だに使っているようです。

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

[18] なぜ素直に標準的なASCII直列化を使わないのかは謎です。
  • [17] RFC 7486 - HTTP Origin-Bound Authentication (HOBA) ( 版) https://tools.ietf.org/html/rfc7486#page-8

ワイルドカード

[170] サーバー側の実装では起源の一致条件の記述のためワイルドカードドメイン名が使えることがあります >>171。

[171] CORS configuration - Amazon Simple Storage Service, , https://docs.aws.amazon.com/AmazonS3/latest/userguide/ManageCorsUsing.html

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

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

  • 文書の実効スクリプト起源
  • 環境設定群オブジェクトの実効スクリプト起源
  • フォントの起源

XMLHttpRequest 起源

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

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

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

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

スタイルシートの起源

  • [273] @import で参照されているスタイルシート >>272
    • 輸入元のスタイルシートの起源と同じ

性質

[41] 起源の性質

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

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

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

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

関連

[155] 部分起源も参照。

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

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

歴史

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

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

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

... と定義されています。 >>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 を、 URL の scheme 部分を小文字化したものとします。
  3. [29] 実装が url-scheme により表されるプロトコルに対応していないなら、 新しい大域的に固有な識別子を生成し、それを返します。
  4. [30] url-scheme が file なら、 実装定義の値を返して構いません。
  5. [32] url-host を、 URL の host 部分を小文字化したものとします。
    • 小文字化には RFC 4790 の i;ascii-casemap を使います。
    • IDNA により Uラベルは既にAラベルに変換されているものと仮定しています。
  6. [33] URL に port 部分がなければ、
    1. url-port を、 url-scheme で表されるプロトコルの既定のポートとします。
  7. [34] そうでなければ、
    1. url-port を、 URL の port 部分とします。
  8. [35] (url-scheme, url-host, url-port) の3項組を返します。

[36] 仕様上明記されていませんが、 >>32 や >>34 で host や port を正準化する必要がありそうです。[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 のピンと結び付けることで証明書を超えて同一性を保てるかもしれません。 しかしそのような実装の動きも無さそうです。
  • [147] Web Applications 1.0 r1839 Allow the origin to include extra data, such as the host's certificate. (credit: el) ( 版) http://html5.org/tools/web-apps-tracker?from=1838&to=1839
  • [148] Web Applications 1.0 r6728 Defer to the origin spec for URL origin. ( 版) http://html5.org/tools/web-apps-tracker?from=6727&to=6728
  • [13] 689835 – Dns rebinding attack using cached resources ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=689835#c13

[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 Standard、Fetch Standard、HTML Standard によって RFC 6454 は廃止されました >>308, >>309, >>7。

  • [307] Define URL's origin · c65766a · whatwg/url ( 版) https://github.com/whatwg/url/commit/c65766a674c6f4c3c521b6dc843f07c1fd23b4d2
  • [308] Fix origin xref mess; obsolete ORIGIN · d94f125 · whatwg/fetch ( 版) https://github.com/whatwg/fetch/commit/d94f125e97592c078e023d5490b65b4210ebe8dc
  • [309] ORIGIN is no more · d354f76 · whatwg/dom ( ( 版)) https://github.com/whatwg/dom/commit/d354f769a18fd567c9c3d763116048ab6c2d383e
  • [1] Opaque identifier is a type, not a value https://www.w3.org/Bugs/Public/... · 09d81f5 · whatwg/url ( 版) https://github.com/whatwg/url/commit/09d81f55e4a788980101fe7f88b1e3c6c8fe7435
  • [7] Web Applications 1.0 r8787 Move the reference for URL origin from Web Origin to URL. ( 版) https://html5.org/r/8787

[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

[161] Suggest use of origin in public suffix warning (mozfreddyb著, ) https://github.com/whatwg/url/commit/0c6e51d2927dbfd2fcb6448795b3e1537b555728

[162] Use ASCII serialization for origins (#1151) (jungkees著, ) https://github.com/w3c/ServiceWorker/commit/a47c6d86c1436a4fff573d2a5da92b0e14891fa2

[164] Use ASCII serialization for origins by jungkees · Pull Request #1151 · w3c/ServiceWorker () https://github.com/w3c/ServiceWorker/pull/1151

[165] Use ASCII serialization for origins · Issue #1142 · w3c/ServiceWorker () https://github.com/w3c/ServiceWorker/issues/1142

[169] Add TAO check (npm1, , ) https://github.com/whatwg/fetch/commit/9dd531988b04f4fadd43022a0613a90b42ce46d4

[174] The Origin API, , https://mikewest.github.io/origin-api/

[175] GitHub - mikewest/origin-api: An `Origin` object might be nice to have., https://github.com/mikewest/origin-api