[17] eTLD+1, サイトsite は、同一の管理主体の管理下にあると思われるドメイン名空間の単位です。 Web においては起源の次に大きなセキュリティーその他の制御上の重要な構造として扱われています。

仕様書

呼称

eTLD+1

[31] 従来 (平成時代後期頃まで) Web では、 eTLD にサブドメイン1階層分を足したもの、というくらいの意味で eTLD+1 と呼ばれるのが一般的でした。

[32] ただし、概念として安定していなかったこともあり、 他のドメイン名系の用語や、説明的な表現も使われていました。

サイト

[33] 平成時代後期頃、 eTLD+1 の概念を直接的に表現するプロトコル要素がいよいよ必要となるとそれを表す用語が検討されました。 結果選ばれたのがサイト (site) でした。

[34] 一般語としてのサイト (Webサイト) は90年代からよく使われていました。 (おそらくWeb以前からあったネットワーク分野の語からの派生でしょう。) eTLD+1 とWebサイトは必ずしも一致しませんが、 おおよそ対応関係にあるということで選ばれたのでしょう。

[29] かつて (90年代末頃から) IE は Site-Enter:、Site-Exit: というHTTPヘッダーを実装していました。

[30] 現在の「サイト」の定義とこれらのヘッダーの挙動は違うと思われます。

[35] サイトは、ドメイン名が関係しない data: や about:blank のような URL に対しても定義されます。

ドメイン名系の用語

[13] public suffix に一階層加えたドメインを、 naked domain、apex domain、zone apex、root domain などと呼ぶことがあります。

[14] example.com は naked domain です。 www.example.com は naked domain ではありません。

[15] DNS では TLD より上位の名前の無い階層 (.) のことを root domain と呼んでおり、 naked domain のことを root domain と呼ぶのは適切ではありません。

[16] 「CNAME を使えない」といった話題でよく使われる用語です。

[74] DNS の設定ではサブドメインではなくこのドメインを表すために @ がサブドメイン (ホスト名特殊ホスト名) であるかのように使われることがよくあります。

意味

[6] PSL も参照。

比較

[37] サイトの比較 (等価性) は、 URL scheme を考慮する同じサイトと、 考慮しない schemeなしで同じサイトの2種類があります。

[38] 起源 A と起源 B がschemeなしで同おなじサイトschemelessley same siteであるか否かは、 次によります。 >>36

  1. [39] A の不透明起源であるが真で、 B の不透明起源であるが真で、 A が B の場合、
    1. [40] 真を返します。
  2. [41] それ以外で、 A の項組起源であるが真で、 B の項組起源であるが真の場合、
    1. [42] ホストA を、 A のホストに設定します。
    2. [43] ホストB を、 B のホストに設定します。
    3. [44] ホストAとホストBが等しいホストhost equalsで、 ホストAの登録可能ドメインが null でない場合、
      1. [45] 真を返します。
    4. [46] それ以外で、 ホストAの登録可能ドメインがホストBの登録可能ドメインで、 ホストAの登録可能ドメインが null でない場合、
      1. [47] 真を返します。
    5. [48] それ以外の場合、
      1. [49] 偽を返します。
  3. [50] それ以外の場合、
    1. [51] 偽を返します。

[52] 起源 A と起源 B が同おなじサイトsame siteであるか否かは、 次によります >>36。

  1. [53] A と B がschemeなしで同じサイトでない場合、
    1. [57] 偽を返します。
  2. [58] それ以外で、 A の不透明起源であるが真で、 B の不透明起源であるが真の場合、
    1. [59] 真を返します。
  3. [60] それ以外で、 A の項組起源であるが真で、 B の項組起源であるが真で、 A の schemeURL scheme が B の schemeURL scheme である場合、
    1. [61] 真を返します。
  4. [54] それ以外の場合、
    1. [56] 偽を返します。
[62] 同じ起源かどうかとは違って、 ポートの違いは無視されます。 [63] 起源のドメインは無視されます。 従って document.domain の影響は受けません。

[55] これら比較方法の定義は、 の HTML Standard 改定で追加されました >>36。

[68] それ以前は URL Standard で規定されていましたが、 same site が後の schemelessly same site の意味でした >>67。

[69] これらは PSL の相互運用性の問題に由来するセキュリティーの懸念から >>67、 可能なら避けるべきで、 同じ起源かどうかによることが好ましいとされています >>36。 実際にはいくつかの新しい機能で採用されています。

文脈

[4] Storage Standard

[5] Web Storage のサイズ制限 (ストレージ (Web) 参照)。

歴史

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

# [09:47] <annevk> I want a term for eTLD+1, I was thinking "site" but a URL's site just seems rather wrong

# [09:48] <annevk> That's one of the things blocking a more formal definition of public suffixes in URL

[3] Allow POSTs to same eTLD+1 endpoints. · w3c/webappsec-credential-management@d30032e ( 版) https://github.com/w3c/webappsec-credential-management/commit/d30032e1a439089460a6801987a7748d8d6de010

[7] RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC) ( ()) https://tools.ietf.org/html/rfc7489#section-3.2

Thus, since "com" is an IANA-registered TLD, a subject domain of

"a.b.c.d.example.com" would have an Organizational Domain of

"example.com".

[8] View the Public Suffix List ( ()) https://publicsuffix.org/list/

The registered or registrable domain is the public suffix plus one additional label.

[9] Re: VC meeting to discuss Permissions spec ( (Anne van Kesteren著, )) https://lists.w3.org/Archives/Public/public-webappsec/2016Jun/0036.html

[10] publicsuffix: cannot derive eTLD+1 for domain "s3.cn-north-1.amazonaws.com.cn" · Issue #14734 · golang/go ( ()) https://github.com/golang/go/issues/14734

"s3.cn-north-1.amazonaws.com.cn" is in https://publicsuffix.org/list/public_suffix_list.dat , so I think this is working as intended.

[11] Web Authentication: An API for accessing Scoped Credentials ( ()) https://w3c.github.io/webauthn/#etld1

Also known as a Registered Domain [PSL], an eTLD+1 is an effective Top-Level Domain Name (eTLD), plus the next domain name label, proceding from right to left.

[12] Clear entire eTLD+1 for cookies. (@annevk著, ) https://github.com/w3c/webappsec-clear-site-data/commit/9b510bfa74223535670aba8a00177af883b28a8a

[18] For users on very slow connections, block document.written scripts · Issue #17 · WICG/interventions () https://github.com/WICG/interventions/issues/17

[19] AWS | Elastic Load Balancing | Classic Load Balancer のよくある質問 ( ()) https://aws.amazon.com/jp/elasticloadbalancing/classicloadbalancer/faqs/

Q: 自分のドメイン (例えば、http://example.com) の zone apex へのトラフィックのロードバランスを実行できますか?

はい。詳細については、Elastic Load Balancing 開発者ツールをご参照ください。

[20] For users on very slow connections, block document.written scripts · Issue #17 · WICG/interventions () https://github.com/WICG/interventions/issues/17

[21] Intelligent Tracking Prevention | WebKit () https://webkit.org/blog/7675/intelligent-tracking-prevention/

[22] Define hosts' public suffix and registrable domain, as well as same site (mikewest著, ) https://github.com/whatwg/url/commit/6a9f7eacaae962b325547f33d6e30134789986a8

[23] Define hosts' public suffix and registrable domain. by mikewest · Pull Request #391 · whatwg/url () https://github.com/whatwg/url/pull/391

[24] Build upon URL rather than PSL (annevk著, ) https://github.com/whatwg/html/commit/326c64415ddff5f619433028bd5d99408dad6430

[25] Define Cross-Origin-Resource-Policy response header (annevk著, ) https://github.com/whatwg/fetch/commit/0cec471b1ba938d775415e2ea08a2d2be4e72413

[26] Intelligent Tracking Prevention 2.0 | WebKit () https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/

[27] Restructure URL rendering section and add additional guidance (estark37著, ) https://github.com/whatwg/url/commit/8809598ddfd1d935432c8a0cad53f13d70e24bc6

[28] Unfurling links in messages | Slack (Slack, ) https://api.slack.com/reference/messaging/link-unfurling#configuring_domains

Domains must have a TLD and cannot be a TLD alone (example.com and another.example.com are valid, example is not and nor is .com).

[66] Treat http://foo.com -> https://foo.com requests as `Sec-Fetch-Site: cross-site`. · Issue #34 · w3c/webappsec-fetch-metadata · GitHub, https://github.com/w3c/webappsec-fetch-metadata/issues/34

[70] Tighten 'same site' checks to include 'scheme'. by mikewest · Pull Request #449 · whatwg/url · GitHub, https://github.com/whatwg/url/pull/449

[67] Let HTML handle the "same site" definition (domenic, , ) https://github.com/whatwg/url/commit/3703f92854207564b21301418d28a0ac647be06d

[36] Define (schemelessly) same site for origins, domenic, , https://github.com/whatwg/html/commit/d0149490ef2dd11e3be53481516d59298694e4c9

[64] Consider introducing a "same-site" concept that includes scheme. · Issue #448 · whatwg/url · GitHub, https://github.com/whatwg/url/issues/448

[65] Define (schemelessly) same site for origins by domenic · Pull Request #5076 · whatwg/html · GitHub, https://github.com/whatwg/html/pull/5076

[71] Let HTML handle the "same site" definition by domenic · Pull Request #457 · whatwg/url · GitHub, https://github.com/whatwg/url/pull/457

[72] Editorial: use origin-based "schemelessly same site" (domenic, , ) https://github.com/whatwg/fetch/commit/493c02127f49d6e9a4df5d56e2fcfa7fbaff48b2

[73] Editorial: use origin-based "same site" definition by domenic · Pull Request #965 · whatwg/fetch · GitHub, https://github.com/whatwg/fetch/pull/965