[OUTDATED] First-Party Sets 和 SameParty 屬性

許多機構都有具有不同網域名稱的相關網站,例如 brandx.sitefly-brandx.site,或是不同國家/地區適用的網域,例如 example.comexample.rsexample.co.uk 等。

瀏覽器即將改為提供第三方 Cookie 已過時 旨在強化網路使用者的隱私,但這類網站經常使用 Cookie 來保護使用者 需要跨網域維持及存取狀態的功能 例如單一登入和同意聲明管理。

第一方集合可允許由 如果第一方和「廣告放送」 其他第三方則以不同方式處理。當中的網域名稱 系統會將第一方集合視為同一方,且能標記哪些 Cookie 屬於 是在相同派對情境中設定或傳送。目的在於找出 防止第三方跨網站追蹤,同時 維護一個不會破壞有效用途的路徑。

第一方集合提案目前處於測試中 階段,請繼續閱讀以瞭解其運作方式 以及如何試用

第一方和第三方 Cookie 有何不同?

Cookie 本質上不是第一方或第三方,取決於目前的 若是包含 Cookie 的內容可能是指 在 JavaScript 中透過 cookie 標頭或 document.cookie 傳送。

舉例來說,如果你在瀏覽期間,video.sitetheme=dark Cookie 並向 video.site 發出 video.site 要求,而該要求是相同網站 背景資訊,以及 且已納入第一方 Cookie。

不過,如果您使用 my-blog.site 嵌入含有 iframe 播放器的 video.site,要求從 my-blog.site 發出至 video.site 時 ,且 theme Cookie 為「第三方」

這張圖表顯示 video.site 在兩個情境中的 Cookie。如果頂層結構定義是 video.site,則 Cookie 是同一個網站。如果頂層內容為 my-blog.site,在 iframe 中顯示 video.site,則此 Cookie 為跨網站。

是否納入 Cookie 取決於 Cookie 的 SameSite 屬性:

  • 同網站 背景資訊,以及 SameSite=LaxStrictNone 會讓 Cookie 成為第一方
  • 使用 SameSite=None 的「跨網站情境」,會將 Cookie 設為第三方

但有時跳出的手法並非如此。假設brandx.site是旅遊行程 預訂網站且使用 fly-brandx.sitedrive-brandx.site 區分航班和租車服務在預訂一趟歷程中,訪客 會在這些網站之間選擇不同的選項 - 他們期待 「購物車」和所選 Cookie 的設定brandx.siteSameSite=None Cookie 管理使用者的工作階段 跨網站結構定義缺點是 Cookie 缺少跨網站 要求偽造假冒 (CSRF) 防護。如果 evil.site 包含 brandx.site,就會加入該 Cookie!

Cookie 是跨網站 Cookie,但這些網站均由同一個 Cookie 自有自營 並根據貴機構的使命 價值觀和目標進行調整訪客也知道這同一個組織,也希望 也就是相同的身分

這張圖表顯示當網站也屬於同一個第一方集合,但因跨網站環境設定而遭拒時,跨網站結構定義可能會如何納入 Cookie。

第一方集合政策

First-Party Sets 建議 方法,在多個網站上明確定義此關係的方法 由同一方自有自營這會讓「brandx.site」 定義自身與 fly-brandx.site 的第一方關係。 drive-brandx.site (依此類推)。

驅動的隱私權模型 每項 Privacy Sandbox 提案都是根據分區的概念 因此在網站之間畫出界線,可避免跨網站追蹤。 限制存取任何可用來識別使用者的資訊。

這張圖表顯示可在多個跨網站環境中存取相同的第三方 Cookie 的未分區狀態,而相較於分區模型,每個頂層模型都有個別的跨網站 Cookie 執行個體,防止跨網站連結活動。

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

這張圖表顯示了當一組 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。

圖表顯示在跨網站環境中允許或封鎖 Brandx.site Cookie 的圖表。

在廣泛支援 SameParty 之前,請一併使用 SameSite 屬性和 定義 Cookie 的備用行為您可以把 SameParty 屬性,就是設定 SameSite=LaxSameSite=None

  • SameSite=Lax; SameParty擴充 Lax 功能,以便 包含相同方情境 (如果支援),但改為使用 Lax 以及限制
  • SameSite=None; SameParty限制「None」功能 就會使用範圍較廣的 None權限。

還有幾項額外規定:

  • SameParty 個 Cookie 必須包含 Secure
  • SameParty Cookie 不得包含 SameSite=Strict

Secure」仍屬於跨網站性質,因此應採取相應措施 的風險。同樣地,由於這是 跨網站關係,SameSite=Strict 無效,因為仍可 站內緊密的站點式 CSRF 防護

第一方集合適合哪些用途?

如果機構需要 可以在不同的頂層網站共用身分在這個範例中的共同身分 這可以是完整的單一登入解決方案,也可以是只需要 偏好設定。

貴機構可能有不同的頂層網域:

  • 應用程式網域office.comlive.commicrosoft.com
  • 品牌網域amazon.comaudible.com / disney.compixar.com
  • 可啟用本地化功能的國家/地區專屬網域google.co.ingoogle.co.uk
  • 使用者從未直接與互動,但提供的服務網域 gstatic.com fbcdn.netgithubassets.com
  • 使用者從未直接與其中互動的沙箱網域 安全性原因:googleusercontent.comgithubusercontent.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.sitefly.brandx.sitedrive.brandx.site,那麼 是同一個網站內的不同子網域Cookie 可以使用 SameSite=Lax,而且不用設定。
  • 您為其他網站提供第三方嵌入項目。這次簡介中範例是 內嵌於 my-blog.sitevideo.site 影片是明確的第三方 。網站由不同機構經營,使用者也能看到 視為獨立實體這兩個網站不可同時存在。
  • 您提供第三方社交登入服務。識別資訊提供者 OAuth 或 OpenID 連線等項目經常仰賴第三方 Cookie, 為使用者提供更流暢的登入體驗。此用途確實有效 適合第一方集合,因為機構組織有明顯差異。 WebID 等早期提案為 並探索如何實現這些用途