はじめに

この記事では1st-Partyと3rd-Partyの違いを説明する。

文脈によってニュアンスが異なる場合があるが、AppleのITPに関する公式リリースから読み取れる内容を正として記載する。

• 1st-Partyクッキー
• 1st-Partyドメイン
• 1st-Partyストレージ

などと使われるものである。

※本記事を執筆した目的は社内向けにITPの理解を深めるためであり、対象には非エンジニアも含まれるため、技術的に平易な知見についても厚く補足している。
とはいえhttpリクエストとCookieについてざっくりでも理解していないと難しい。

参考1：ITP公式リリース
https://webkit.org/blog/7675/intelligent-tracking-prevention/

参考2：トラッキング防止ポリシー
https://webkit.org/tracking-prevention-policy/
※WebKitはSafariに標準搭載されているレンダリングエンジンで、Appleが中心となって開発しているOSSであるので、信頼出来る一次情報源となる。

1st-Partyと3rd-Party

言葉上の意味

1st-Party = 当事者
3rd-Party = 部外者

webブラウジングにおいては(少し乱暴だが)、

「ユーザー（ブラウザ）」と閲覧対象の「webサイト」が当事者（=1st-Party）
それ以外が第三者（=3rd-Party）

という考え方で良いだろう。

※2nd-Partyという概念は基本的に無い。
（敢えて言えばユーザーかwebサイトのどちらかが2ndになるのであろうが、
どちらも当事者という意味の1stで括られている。）

WebKitのトラッキング防止ポリシーでは次の様に定義されている。

A first party is a website that a user is intentionally and knowingly visiting, as displayed by the URL field of the browser, and the set of resources on the web operated by the same organization

敢えて直訳気味に訳すと以下の様になる。

1st-Partyとは、
ブラウザのURL欄で明示されていて、
更に同機関が運営するweb上のリソース群で表示されていて、
ユーザーが意図的に、
且つユーザー自身にも分かる形で、
訪問しているwebサイトの事である。

ちなみに3rd-Partyに関しては「上記以外の全て」と表現されている。

具体的に1st-Partyは何で、3rd-Partyはどの様な形で介入するのか？

具体例

トップページにTwitterのツイートボタンが設置してある「example.com」というサイトにアクセスした、
という例で考える。

この場合、サイトを閲覧できる様になるまで以下の様なステップを踏む。
（1st/3rd-Partyの理解に必要なステップのみ示す。）

1. 使用しているブラウザからexample.comにhttpリクエストを送る
2. ブラウザがexample.comからhtmlファイルを受け取る(httpレスポンス)
3. ブラウザがhtmlファイルを解析し画像やスクリプトなどのリソースを一つずつ取得していく。
4. 取得が全て終わった時点で完全な閲覧が可能。

1st-Party

上記例において、
「example.com」が1st-Partyドメインである。
2.のステップでCookieが付与されればそれは1st-Party-Cookieである。

3rd-Party

引き続き上記の例において、
htmlファイルに以下のリソースが含まれていた場合。
（これはTwitterが提供しているツイートするボタンを挿入するコードである）

<a href="https://twitter.com/intent/tweet?button_hashtag=example&ref_src=twsrc%5Etfw" class="twitter-hashtag-button" data-show-count="false">Tweet #example</a><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

以下のURLにリクエストを送ってリソースを取得してくることになる。
これは上記の例でいうと3.のステップで行われる。

https://platform.twitter.com/widgets.js

まさにこの場合のtwitterはユーザーでも閲覧対象のサイトでもない第三者であり、3rd-Partyである。
この場合のtwitter.comを3rd-Partyドメインと呼ぶ。

例えば今回の例がTwitterのボタンではなくGoogle Adsenseであればその時のgoogleは3rd-Partyである。

3.のステップで取得する際にCookieがブラウザに付与されれば、それは3rd-Party-Cookieである。
（実際にtwitter.comからCookieが付与されるかは確認していないので悪しからず。）

補足：リダイレクト計測の場合

広告効果計測についてリダイレクト方式でCookieを付与する場合がままある。
以下の様な遷移パターンである。

1. サイトA（ユーザーがサイトB（実際は広告サーバー）に誘導するリンクをクリック）
2. 広告サーバー（サーバーがCookie付与して即座にリダイレクト）
3. サイトB（ユーザーが閲覧する遷移先）

この場合、ユーザーは広告サーバーが配信しているサイトを閲覧していない。
（広告関係やエンジニアとしての知識が無ければ存在すら知らないはずである。）
そのため、言葉上の意味だと3rd-Partyと解釈できる。
はじめに紹介したWebKitのトラッキング防止ポリシーを確認してもそう解釈できる。

しかし、WebKitは、少なくともITP1.0の時点では、このパターンの広告サーバーは1st-Partyという扱いをしている。

その根拠として以下二点を挙げる。

• ITP2.0のリリースにおいて、このパターンの広告サーバーは「First Party Bounce Trackers」と表現されている。
• 同時にこの「First Party Bounce Trackers」について対策をした（=1.0の時点では対策をしていなかった）事が記述されている。

つまり、少なくともこの時点での技術的な3rd-Partyの定義としては、

• 現在表示しようとしているサイトのURLとは異なるリソースの取得先

であり、1st-Partyの定義は

• 閲覧のためのリクエスト先（たとえ結果として即座にユーザーがリダイレクトされたとしても）

であったと解釈できる。