許多機構都有具有不同網域名稱的相關網站,例如
brandx.site
和 fly-brandx.site
,或是不同國家/地區適用的網域,例如
example.com
、example.rs
、example.co.uk
等。
瀏覽器即將改為提供第三方 Cookie 已過時 旨在強化網路使用者的隱私,但這類網站經常使用 Cookie 來保護使用者 需要跨網域維持及存取狀態的功能 例如單一登入和同意聲明管理。

第一方集合可允許由 如果第一方和「廣告放送」 其他第三方則以不同方式處理。當中的網域名稱 系統會將第一方集合視為同一方,且能標記哪些 Cookie 屬於 是在相同派對情境中設定或傳送。目的在於找出 防止第三方跨網站追蹤,同時 維護一個不會破壞有效用途的路徑。
第一方集合提案目前處於測試中 階段,請繼續閱讀以瞭解其運作方式 以及如何試用
第一方和第三方 Cookie 有何不同?
Cookie 本質上不是第一方或第三方,取決於目前的
若是包含 Cookie 的內容可能是指
在 JavaScript 中透過 cookie
標頭或 document.cookie
傳送。
舉例來說,如果你在瀏覽期間,video.site
有 theme=dark
Cookie
並向 video.site
發出 video.site
要求,而該要求是相同網站
背景資訊,以及
且已納入第一方 Cookie。
不過,如果您使用 my-blog.site
嵌入含有 iframe 播放器的
video.site
,要求從 my-blog.site
發出至 video.site
時
,且 theme
Cookie 為「第三方」。

是否納入 Cookie 取決於 Cookie 的 SameSite
屬性:
- 同網站
背景資訊,以及
SameSite=Lax
、Strict
或None
會讓 Cookie 成為第一方。 - 使用
SameSite=None
的「跨網站情境」,會將 Cookie 設為第三方。
但有時跳出的手法並非如此。假設brandx.site
是旅遊行程
預訂網站且使用 fly-brandx.site
和 drive-brandx.site
區分航班和租車服務在預訂一趟歷程中,訪客
會在這些網站之間選擇不同的選項 - 他們期待
「購物車」和所選 Cookie 的設定brandx.site
以 SameSite=None
Cookie 管理使用者的工作階段
跨網站結構定義缺點是 Cookie 缺少跨網站
要求偽造假冒 (CSRF) 防護。如果 evil.site
包含
brandx.site
,就會加入該 Cookie!
Cookie 是跨網站 Cookie,但這些網站均由同一個 Cookie 自有自營 並根據貴機構的使命 價值觀和目標進行調整訪客也知道這同一個組織,也希望 也就是相同的身分

第一方集合政策
First-Party Sets 建議
方法,在多個網站上明確定義此關係的方法
由同一方自有自營這會讓「brandx.site
」
定義自身與 fly-brandx.site
的第一方關係。
drive-brandx.site
(依此類推)。
驅動的隱私權模型 每項 Privacy Sandbox 提案都是根據分區的概念 因此在網站之間畫出界線,可避免跨網站追蹤。 限制存取任何可用來識別使用者的資訊。

雖然預設選項是按網站劃分,因此可以解決許多第一方問題
brandx.site
範例顯示,第一方 Cookie 規模較小
而非單一網站

第一方集合提案的一大關鍵,就是確保政策 也能防止濫用或濫用舉例來說,第一方集合不得 例如跨不相關的網站交換使用者資訊 。概念就是確保 第一方集合對應了使用者瞭解的第一方第一方區隔 用於在不同方之間分享身分資訊。
網站註冊第一方集合的方法可能是網站 將建議的網域群組提交至公開追蹤程式 (例如 專屬 GitHub 存放區),以及滿足瀏覽器需求所需的資訊 政策。
根據政策確認第一方集合斷言後,瀏覽器 然後透過更新程序擷取集合清單。
來源試用已定義政策 (並非最終),但原則為 可能會保持不變:
- 第一方集合中的網域都必須是相同的自有自營網域 並根據貴機構的使命 價值觀和目標進行調整
- 網域應可供使用者識別為一個群組。
- 網域應共用通用的隱私權政策。
如何定義第一方集合
指定成員和機構第一方擁有者後 然後將您提議的組合送交審核。與 程序仍在討論中。
如要宣告第一方集合,請列出成員和擁有者的靜態 JSON 資源
都應由各叢集的頂層 /.well-known/first-party-set
代管
加入的網域
在 brandx
第一方集合的範例中,擁有者網域會代管
追蹤
https://brandx.site/.well-known/first-party-set
:
{
"owner": "brandx.site",
"version": 1,
"members": ["fly-brandx.site", "drive-brandx.site"]
}
集合的每個成員也會代管一個靜態 JSON 資源,指向回頭
集合擁有者。
https://fly-brandx.site/.well-known/first-party-set
的退款金額如下:
{ "owner": "brandx.site" }
並在 https://drive-brandx.site/.well-known/first-party-set
:
{ "owner": "brandx.site" }
第一方組合設有以下限制:
- 一組資源集只能有一位擁有者。
- 每個成員只能屬於一個集合,不得重疊或混合。
- 成員清單的用意是相對容易理解, 超過 1000 個物件
第一方集合如何影響 Cookie?
我們提議使用餅乾愛用的食材是提議的SameParty
屬性。指定 SameParty
指示瀏覽器在 Cookie 內容與網址相同時
設為頂層情境
也就是說,如果 brandx.site
設定這個 Cookie:
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
然後,當訪客處於 fly-brandx.site
狀態且要求前往
brandx.site
,則 session
Cookie 會包含在該項要求中。
舉例來說,如果其他網站並不屬於第一方集合,
hotel.xyz
,傳送要求給 brandx.site
,但系統不會納入這個 Cookie。

在廣泛支援 SameParty
之前,請一併使用 SameSite
屬性和
定義 Cookie 的備用行為您可以把 SameParty
屬性,就是設定 SameSite=Lax
和
SameSite=None
。
SameSite=Lax; SameParty
會擴充Lax
功能,以便 包含相同方情境 (如果支援),但改為使用Lax
以及限制SameSite=None; SameParty
會限制「None
」功能 就會使用範圍較廣的None
權限。
還有幾項額外規定:
SameParty
個 Cookie 必須包含Secure
。SameParty
Cookie 不得包含SameSite=Strict
。
「Secure
」仍屬於跨網站性質,因此應採取相應措施
的風險。同樣地,由於這是
跨網站關係,SameSite=Strict
無效,因為仍可
站內緊密的站點式 CSRF 防護
第一方集合適合哪些用途?
如果機構需要 可以在不同的頂層網站共用身分在這個範例中的共同身分 這可以是完整的單一登入解決方案,也可以是只需要 偏好設定。
貴機構可能有不同的頂層網域:
- 應用程式網域:
office.com
、live.com
、microsoft.com
- 品牌網域:
amazon.com
、audible.com
/disney.com
、pixar.com
- 可啟用本地化功能的國家/地區專屬網域:
google.co.in
、google.co.uk
- 使用者從未直接與互動,但提供的服務網域
gstatic.com
fbcdn.net
和githubassets.com
- 使用者從未直接與其中互動的沙箱網域
安全性原因:
googleusercontent.com
、githubusercontent.com
該如何參與?
如果您的網站一組符合上述條件, 提供各式各樣的選擇最便宜的投資是閱讀並加入 兩個提案的討論:
在測試階段,您可以使用
--use-first-party-set
指令列標記和提供逗號分隔的清單
。
您可以在示範網站上試用這項功能: 開始後 https://fps-member1.glitch.me/ Chrome 和以下旗標:
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
如果您想在開發環境中進行測試,或是想要在開發環境中進行測試,這項功能就能派上用場
請嘗試在實際環境中新增 SameParty
屬性,看看
則會影響 Cookie
如果你有充分的頻寬足以進行實驗和意見回饋,另外也可以提出申請 針對第一方集合的來源試用,以及 SameParty 。
如何更新來源試用的 Cookie
如果您要加入來源試用,並在以下位置測試 SameParty
屬性:
以下列出兩種模式供您參考
選項 1
首先,假設您將 Cookie 標示為 SameSite=None
,但您
您想要限制在第一方情境下,可以在「群組」欄位加入 SameParty
屬性。在來源試用的瀏覽器中,Cookie 會
跨網站傳送。
然而,對多數 來源試用以外的瀏覽器將持續傳送 Cookie 一樣可追蹤兩個跨網站間的連結不妨將這個方法視為漸進式強化。
變更前:
set-cookie: cname=cval; SameSite=None; Secure
變更後:
set-cookie: cname=cval; SameSite=None; Secure; SameParty
選項 2
第二個選項比較有效,但可讓您完全分隔來源
並利用現有功能來測試
SameSite=Lax; SameParty
組合。
變更前:
set-cookie: cname=cval; SameSite=None; Secure
變更後:
set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty
檢查傳入請求的 Cookie 時,僅應預期會看到
傳送跨網站要求中的 cname-fps
Cookie (如果牽涉的網站與
且瀏覽器正在進行來源試用。舉例來說,
同時對更新版功能
版本。
為什麼不需要第一方集合?
大多數網站的網站界線可以用來
分區或隱私邊界此為建議路線
CHIPS (具有獨立分區的 Cookie)
狀態),表示網站可自行決定是否採用
透過 Partitioned
屬性傳送的路線,仍包含這些重要的跨站點
嵌入、資源、API 和服務,同時防止系統識別
使用者的資訊
還有幾點注意事項: 組合:
- 您透過不同來源代管網站,而非不同網站。在上述範例中
如果
brandx.site
有fly.brandx.site
,drive.brandx.site
,那麼 是同一個網站內的不同子網域Cookie 可以使用SameSite=Lax
,而且不用設定。 - 您為其他網站提供第三方嵌入項目。這次簡介中範例是
內嵌於
my-blog.site
的video.site
影片是明確的第三方 。網站由不同機構經營,使用者也能看到 視為獨立實體這兩個網站不可同時存在。 - 您提供第三方社交登入服務。識別資訊提供者 OAuth 或 OpenID 連線等項目經常仰賴第三方 Cookie, 為使用者提供更流暢的登入體驗。此用途確實有效 適合第一方集合,因為機構組織有明顯差異。 WebID 等早期提案為 並探索如何實現這些用途