本文轉(zhuǎn)載自微信公眾號「微醫(yī)大前端技術(shù)」，作者廖宜康。轉(zhuǎn)載本文請聯(lián)系微醫(yī)大前端技術(shù)公眾號。

前言

作為前端開發(fā)，cookie是我們經(jīng)常需要打交道的東西。我們用它來鑒權(quán)，用它來實(shí)現(xiàn)行為跟蹤，用它給無狀態(tài)的 http 協(xié)議以“狀態(tài)”。本文就聚焦這個(gè)小小的 cookie，把 cookie 掰開了，揉碎了講一講， 它是如何被我們利用的。

本文以 Chrome 瀏覽器 96.0.4664.55 版本作為客戶端環(huán)境，后續(xù)所有代碼說明都基于該版本的瀏覽器。主要闡述以下四點(diǎn)：

• cookie 的現(xiàn)有屬性
• cookie 如何被用來跟蹤我們
• cookie 前端管理實(shí)踐
• cookie 的未來

話不多說，開沖!

一、cookie 的屬性們

在詳細(xì)的屬性說明之前，我們先讓新老朋友重新熟悉一下 cookie。

cookie 官方定義：魔法曲奇餅，不是

An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to a user's web browser. The browser may store the cookie and send it back to the same server with later requests. Typically, an HTTP cookie is used to tell if two requests come from the same browser—keeping a user logged in, for example. It remembers stateful information for the stateless HTTP protocol. 

由官方定義可知，cookie 是一個(gè)存儲(chǔ)在用戶端設(shè)備上的小塊數(shù)據(jù)。這里的定義指的是由 HTTP 請求的響應(yīng)頭set-cookie創(chuàng)建的 cookie?，F(xiàn)在我們也可以使用 document.cookie來訪問和手動(dòng)創(chuàng)建第一方 cookie。

1.1 為什么要 cookie

大家都知道，因?yàn)橛行枨笏圆庞惺袌觯夹g(shù)也一樣，cookie 就是這樣出現(xiàn)的。cookie 的由來是著名的 Netscape 在給客戶開發(fā)電子商務(wù)程序時(shí)，客戶要求服務(wù)端不必須存儲(chǔ)事務(wù)狀態(tài)。那沒辦法，服務(wù)端不想存，只能客戶端出力了。由此 cookie 誕生了。我們常用的 http 協(xié)議是無狀態(tài)的協(xié)議，這也是為什么他這么快的原因之一。但很多時(shí)候我們需要知道是誰給我們發(fā)過來的請求，我們需要記錄用戶狀態(tài)。

所以 cookie 誕生的原因：

• 服務(wù)端不想存狀態(tài)
• 我們需要存狀態(tài)

可能有人會(huì)說，那我這個(gè)狀態(tài)存在sessionStorage里行不行，存在localStorage里行不行，甚至我自己放個(gè)自定義的參數(shù)放請求頭里來表示狀態(tài)行不行。

既然這么說了，當(dāng)然是行的，瀏覽器發(fā)展到現(xiàn)在，很多存儲(chǔ)方式被用來替代 cookie，但是 cookie 仍然存在其獨(dú)特性。比如同域之間可共享，服務(wù)端可設(shè)置......所以具體怎樣的方案取決于你的實(shí)際場景。

1.2 屬性詳解

打開瀏覽器的devtool面板

可以看到，上面有 cookie 發(fā)展至今的所有屬性，那這些屬性分別代表什么呢?

cookie 屬性說明表

不廢話了，讓我們一個(gè)個(gè)開始講。(標(biāo)綠色的屬性表示前端可以通過 js 直接操作的屬性)

name

name 主要注意同名的問題，cookie 設(shè)置時(shí)不同 domain，不同 path 可以使用相同的 name。如果 domain、path 相同，那么后設(shè)置的 cookie 會(huì)覆蓋先設(shè)置的。

除此之外還要注意一點(diǎn)，通過 js 操作cookie時(shí)，第一項(xiàng)永遠(yuǎn)對應(yīng)的是name=value。即document.cookie="path=/;name=test"這樣設(shè)置的結(jié)果不會(huì)是我們看上去的在/路徑下配置了一個(gè) value 為test的cookie。而是設(shè)置了一個(gè)cookie的 name 是path value 是/。

value

cookie 的值，僅支持字符串，如果使用其他類型，會(huì)調(diào)用 toString()方法進(jìn)行轉(zhuǎn)換。

domain

domain 要注意的點(diǎn)有很多，我們可以用它來實(shí)現(xiàn)前端跨域訪問，單點(diǎn)登錄(二級域名同域)，跟蹤用戶.....主要要注意的有以下幾個(gè)

• js 設(shè)置 cookie 配置 domain時(shí)，只能設(shè)置第一方的。如在 example.com 使用js設(shè)置cookie，如document.cookie = token=123;domain=test.com是不會(huì)生效的。
• js 設(shè)置cookie配置 domain時(shí)，如上一個(gè)例子，只要是手動(dòng)配置該屬性，無論這個(gè)屬性前面有沒有寫明**“."**符號，都會(huì)自動(dòng)加上 domian=.test.com，被配置通配域名的形式。
• js 獲取cookie時(shí)，目前通用的訪問方式仍然是document.cookie這一個(gè) API，所以在獲取的時(shí)候我們是不知道當(dāng)前的cookie是具體是屬于哪一個(gè)domain的。

path

• 設(shè)置cookie的該屬性時(shí)，該屬性的必須存在于當(dāng)前url的pathname中，和domain類似，否則無法設(shè)置。
• 設(shè)置 path 時(shí)如果設(shè)置配置的是相對路徑，則會(huì)自動(dòng)匹配設(shè)置為完整的pathname,如當(dāng)前url為https://test.com/ab/cd，設(shè)置document.cookie = token=123;;path=ab，那么最終path就會(huì)是/ab/cd。
• 大家都知道cookie會(huì)在發(fā)送http請求時(shí)自動(dòng)放入請求頭。如果cookie設(shè)置了該屬性，則會(huì)去匹配請求的路徑中是否包含該屬性的值，包含則會(huì)發(fā)送這個(gè)cookie。這里要注意一下path采用的是匹配的模式。如path為/test，那么/testtest也會(huì)匹配到。
• path屬性還存在一個(gè)作用，提升cookie的排序，通常我們設(shè)置cookie時(shí)，先設(shè)置的在前，后設(shè)置的在后。但是當(dāng)cookie有path這個(gè)屬性時(shí)，有path的會(huì)被提升到最前面(chrome 瀏覽器，其他瀏覽器未實(shí)驗(yàn)。)

這里還要注意下，設(shè)置path時(shí)，值要包含在當(dāng)前url。但是我們最常用的ajax請求一般不是當(dāng)前路徑，所以會(huì)攜帶不上這個(gè)cookie。要注意區(qū)分，不是當(dāng)前路徑下的所有請求都會(huì)攜帶，而是請求的地址包含這個(gè)path才會(huì)攜帶。

Max-Age

cookie的刪除都是利用過期時(shí)間來實(shí)現(xiàn)，將其過期時(shí)間Max-Age設(shè)置為<= 0的整數(shù)則可以刪除該cookie。

• Max-Age如果設(shè)置的是非整數(shù)，則過期時(shí)間默認(rèn)為session，即到頁面關(guān)閉即失效。
• Max-Age的時(shí)間是秒，設(shè)置為 10，則表示 10 秒后過期，是符合我們的預(yù)期的。注意和下面講的expires的區(qū)別。

Expires

Expires也是表示的過期時(shí)間，只不過相對max-age其出現(xiàn)的時(shí)間更早(對 IE8 以下有更好的兼容性)?，F(xiàn)在更推薦使用Max-Age。使用Expires來設(shè)置過期時(shí)間有時(shí)候會(huì)出現(xiàn)一些我們困惑的情況。

• Expires首先接受的是一個(gè)Date對象，其次特別要注意的是，cookie的過期時(shí)間是基于UTC時(shí)間。而國內(nèi)的標(biāo)準(zhǔn)時(shí)間是 GMT時(shí)間，比UTC時(shí)間要快 8 小時(shí)。我們通過該屬性設(shè)置過期時(shí)間時(shí)，如expires=${new Date()}。這里看著是把過期時(shí)間設(shè)置為了當(dāng)前，cookie會(huì)立即失效，但是我們實(shí)際是把cookie的過期UTC時(shí)間設(shè)置為了當(dāng)前時(shí)間，距離cookie真正失效還有 8 小時(shí)。有時(shí)我們通過expires去清除cookie時(shí)卻沒有清掉可能就是這個(gè)原因。

當(dāng)我們同時(shí)設(shè)置Expires和Max-Age時(shí)，Max-age具有更高的優(yōu)先級。

HttpOnly

該屬性主要是用來做基礎(chǔ)的 xss 攻擊防御，js 在設(shè)置cookie時(shí)是無法配置該屬性的。只有服務(wù)端通過set-cookie響應(yīng)頭返回的字段才能配置該字段。但是這也只是防君子罷了，不用太過依賴該屬性。

Secure

secure和HttpOnly一樣，都是為了cookie安全打出的組合拳。和HttpOnly不同的是，它允許通過 js 配置。

這里插入一點(diǎn)我在實(shí)踐中發(fā)現(xiàn)的問題。有時(shí)候我們需要內(nèi)網(wǎng)部署一些應(yīng)用，通過前置機(jī) ng 轉(zhuǎn)發(fā)請求的形式來訪問云端的服務(wù)。而訪問前置機(jī)一般是直接訪問ip的形式，這時(shí)候肯定不是 https 協(xié)議了。但是云端服務(wù)的響應(yīng)頭set-cookie中如果含有secure屬性。(1)雖然可以通過 ng 傳回來，但是是寫不到內(nèi)網(wǎng)機(jī)器里面的。(2)出現(xiàn)這種問題我們的處理方案通常是在 ng 這一層處理掉響應(yīng)頭的secure。這里要注意一下360 瀏覽器會(huì)檢測到這種行為(不清楚具體原理)，仍然無法寫入cookie 。當(dāng)前版本的 Chrome 則可以成功寫入，不排除未了來 Chrome 更新阻止的可能。

SameSite

本屬性是 chrome 51 新增的一個(gè)重要屬性。三個(gè)值的意義如下

• Strict: 僅允許發(fā)送同站點(diǎn)請求的的cookie。
• Lax: 允許部分第三方請求攜帶cookie，即導(dǎo)航到目標(biāo)網(wǎng)址的 get 請求。包括超鏈接 ，預(yù)加載和 get 表單三種形式發(fā)送cookie 。chrome 80+ 版本后，默認(rèn)就是該值。
• None: 任意發(fā)送cookie，設(shè)置為 None，必需要同時(shí)設(shè)置Secure=true，也就是說網(wǎng)站必須采用 https。

這里要區(qū)分一下跨站(cross-site)和跨域(cross-origin)兩者不是一個(gè)概念?？缬蚴侵?portal、host、port 之中的任意一個(gè)不同都被視為跨域。而跨站則比較寬松，只要二級域名相同就是同站(二級域名指 .com 這種頂級域名的下一級，如 test.com)。

默認(rèn)配置該屬性為Lax之后，主要影響的應(yīng)該是我們的 post 表單、iframe、ajax 和 image，大家要注意。

SameParty

SameParty是 Chrome 為了 cookie的安全第三記組合拳。主要用來配合First-Party策略。所有開啟了 First-Party Sets 域名下需要共享的 Cookie 都需要增加 SameParty 屬性。如Set-Cookie:name=test;Secure;SameSite=Lax;SameParty。SameParty自身是沒有值的，但是設(shè)置他必須設(shè)置了Secure且SameSite不能是 strict

First-Party 策略在后面“Chrome 是如何做的”中會(huì)詳細(xì)說明。

Priority

上面說了很多可能有點(diǎn)啰嗦，這個(gè)屬性就。。。沒什么好說的，看上面的表格。

二、cookie 如何被用來跟蹤我們

上面一大段介紹看完，大家應(yīng)該對現(xiàn)在的cookie有了全面的了解。那cookie又是如何被我們利用的呢?

cookie最廣泛的用途大家肯定都知道，無非傳遞傳遞鑒權(quán)信息，做做單點(diǎn)登錄，這也是用的最多的用法。但是cookie自誕生以來就是各大廣告商窺探用戶隱私的利器。例如我今天在某貓搜了個(gè) xx 杯，第二天貼吧，微博到處都是這個(gè)東西的推銷廣告。仿佛全世界都知道我看了這個(gè)東西(事實(shí)上他們確實(shí)知道)。那么他們是如何做到的呢?

2.1 第三方 cookie

了解普遍的做法之前，我們先區(qū)分一下第一方cookie和第三方cookie。我們一般認(rèn)為cookie的 domain 存在于當(dāng)前域名或當(dāng)前域名的父級的cookie稱為第一方cookie，否則為第三方cookie。雖然很多情況下“第三方”的cookie也是我們主動(dòng)注入的罷了。

如下圖以某寶舉例：

.taobao.com下的就是第一方cookie，而這個(gè).mmstat.com 很明顯就是第三方cookie了。

2.2 廣告與隱私

上面說到第三方cookie，可以說它是各種網(wǎng)絡(luò)廣告的罪魁禍?zhǔn)?，而且是最便捷成本最低的那種。我們繼續(xù)以上面的某寶舉例。大家都能發(fā)現(xiàn)這個(gè).mmstat.com這個(gè)域名。那這個(gè)網(wǎng)站是干什么的呢。

我首先去百度了下這個(gè)域名，域名本身無法訪問，但是在百度的結(jié)果下面倒是發(fā)現(xiàn)一些好玩的詞條??。

實(shí)際上他并不是什么不健康的網(wǎng)站，他是阿里旗下的一個(gè)廣告營銷平臺(tái)。

這里不是打廣告...只是讓大家知道他是做廣告營銷的就行了。

那他是如何運(yùn)作的呢，我們可以根據(jù)請求來看。

標(biāo)記用戶

首先我們打開某寶，可以看到第一次訪問 mmstat.com 這個(gè)域名是下面這個(gè)請求：

加載了一張幾乎不可見的 gif 圖片，同時(shí)通過 set-cookie 將第三方cookie寫入。

之后又請求了這張 gif 圖片。

將第一次獲得的信息傳入，完成了用戶的標(biāo)記，阿里媽媽成功的知道了你是誰。當(dāng)你打開其他接入阿里媽媽的網(wǎng)站時(shí)，比如視頻播放站某酷，你會(huì)看到你們存在一個(gè)相同的標(biāo)記 ID。阿里媽媽知道是你小子剛才打開了我家的某寶然后又跑來某酷看電視來了。

獲取用戶足跡

我們知道用戶投廣告，希望看到的是廣告的高轉(zhuǎn)化率，那如何提高轉(zhuǎn)化率呢?最好的方式自然是將商品推薦給需要他的人群。那如何知道用戶需不需要這個(gè)商品呢?自然是記錄用戶的某寶搜索記錄，瀏覽記錄。將這些數(shù)據(jù)標(biāo)記下來，就可以獲得商品的目標(biāo)人群。

我們依然以某寶舉例，當(dāng)我點(diǎn)進(jìn)一個(gè)商品時(shí)，發(fā)送了這樣 5 個(gè)請求

最后一個(gè)請求沒什么好說的，就是傳入了一個(gè) tmall 的跳轉(zhuǎn)路徑，因?yàn)槲尹c(diǎn)擊的商品在 tmall 而不是某寶。我們重點(diǎn)看一下前四個(gè)請求。

根據(jù) cookie的基本作用我們知道，這四個(gè)請求都攜帶了我們第一次打開某寶時(shí)所寫入的cookie信息，也就是標(biāo)記我們是誰的信息，同時(shí)在這四個(gè)請求里傳入了一些參數(shù)來標(biāo)記我們的行為，我們拉出來一個(gè)個(gè)分析下。

我們從上面的圖中可以看到，第一個(gè)和第二個(gè)，第三個(gè)和第四個(gè)請求幾乎是一摸一樣的。首先看下第一個(gè)和第二個(gè)請求

第一個(gè)請求參數(shù) 1-1

第二個(gè)請求參數(shù) 1-2

可以看到兩個(gè)請求參數(shù)幾乎是相同的，唯一的不同在于第一個(gè)請求的 gokey 中多了一個(gè) aws=1的參數(shù)，當(dāng)然不是某寶的開發(fā)我們自然是不知道每個(gè)參數(shù)的作用的，但是我們可以通過參數(shù)中包含的信息來推測。這里可以看到_p_url這個(gè)參數(shù)中包含的信息時(shí)比較明顯的。

從這個(gè)參數(shù)的值來分析，發(fā)現(xiàn)這個(gè)參數(shù)包含的信息就是我們是如何找到這個(gè)商品的。參數(shù)中明確的寫出我們是通過 s.taobao.com來搜索 q=%E8%83%8C%E5%8C%85到達(dá)此頁面的，q 的值就是我搜索的商品名“背包”。同時(shí)鏈接上還攜帶了一些其他參數(shù)，比如sourceId等。通過這些參數(shù)和一開始植入的第三方cookie，這里阿里媽媽就知道是"你在某寶首頁通過搜索背包進(jìn)入的該商品頁"。那么你就被標(biāo)記為了“一個(gè)需要背包的用戶”。搜索作為一種主動(dòng)行為，占的權(quán)重肯定是比較高的，那這個(gè)信息就是非常有用的。

第三個(gè)請求和第四個(gè)請求的情況類似于第一、第二個(gè)，只不過包含的信息更詳細(xì)。第三個(gè)和第四個(gè)請求的地址相同，參數(shù)也幾乎相同，唯一的不同也是aws這個(gè)值。

我們以第三個(gè)分析一下：

可以看到，大量信息被放入 gokey 中。

轉(zhuǎn)碼后可以看到一些被發(fā)送的信息，例如

• serach_radio_all
• GongYingLianDIsts
• list_model
• isp4p
• item_click_form

上述信息大家通過定義的名稱也大致能猜出其包含的數(shù)據(jù)信息。通過以上信息阿里媽媽就記錄了你的這些行為：

• 你打開了淘寶
• 你在淘寶首頁搜索了背包
• 你在第一頁點(diǎn)進(jìn)了一款背包
• 你只是看了看沒有購買
• ......

有了這些信息之后，當(dāng)我們打開接入了阿里媽媽廣告的網(wǎng)站，比如某酷。你會(huì)發(fā)現(xiàn)他也有mmstat.com的第三方cookie嗎，并且存在一個(gè)id信息和你在逛某寶的時(shí)候是相同的。這時(shí)候廣告平臺(tái)就知道了：你小子剛才想買個(gè)包，現(xiàn)在又跑到某酷看劇來了，等會(huì)就給你推送點(diǎn)包的廣告，嘿嘿嘿!

而這一切的基礎(chǔ)就是通過一個(gè)小小的第三方cookie來對我們進(jìn)行標(biāo)記，完成用戶畫像，再將這些信息整合把商品推送給我們嗎，那賺我們的錢就像“搶劫”一樣。本來你只是產(chǎn)生了買個(gè)包的想法但是沒決定到底買不買，結(jié)果人家通過廣告投放不間斷的告訴你買個(gè)包吧，買個(gè)包吧，你的錢就這樣花出去了。

總結(jié)

簡單總結(jié)一下廣告跟蹤你基本就是三步走

• 首次訪問網(wǎng)站時(shí)通過第三方cookie植入將你標(biāo)記。
• 瀏覽網(wǎng)站時(shí)通過植入的cookie不斷的向營銷平臺(tái)發(fā)送你的瀏覽足跡(幾乎精確到了每一步操作，一個(gè)點(diǎn)擊，一個(gè)停滯都會(huì)被記錄)。
• 在訪問其他社交網(wǎng)站時(shí)會(huì)值入相同的第三方cookie將你標(biāo)記，同時(shí)給你推送相關(guān)廣告。

具體到實(shí)現(xiàn)的操作會(huì)比這復(fù)雜的多，希望大家可以根據(jù)上方的分析有所了解。

到這里大家可能就覺得有一種被監(jiān)控的感覺。上述只是對購物網(wǎng)站的基礎(chǔ)分析，像我們?nèi)粘Ｓ玫淖疃嗟陌俣?，微博等都接入了類似的廣告營銷平臺(tái)，再加上廣告聯(lián)盟的存在，可以說我們每個(gè)人在網(wǎng)絡(luò)上的每一步足跡都是被記錄在案的。只是這些數(shù)據(jù)可能分散在不同的廠商，加上國家監(jiān)管，各大廠商也不會(huì)肆無忌憚。不過被監(jiān)控的感覺始終是不舒服的，這也是為什么 Google 收到了超 100 億美元的關(guān)于隱私問題的罰款。而這一切都源于一個(gè)小小的cookie。

注：以上是我根據(jù)請求對廣告行為與cookie相關(guān)的一些分析，對某寶的分析僅僅是舉例，大家知道廣告平臺(tái)是怎么操作的即可。

三、cookie 前端管理實(shí)踐

說完了cookie的基本屬性與對我們的日常影響，我來談?wù)勗趯?shí)踐中我是如何管理cookie的，供大家參考。

3.1 前端 cookie 常見問題

在聊如何做的之前我們先說說我在cookie上遇到過的一些問題：

• 主域名內(nèi)嵌子項(xiàng)目，cookie 在不同項(xiàng)目間的行為難以統(tǒng)一
• cookie 鑒權(quán)相關(guān)操作在不完全了解的情況下不敢輕易修改
• 不同項(xiàng)目使用公司統(tǒng)一的二級域名情況下，因?yàn)?cookie 的 name 相同可能造成的混亂
• 項(xiàng)目中cookie如果某個(gè)屬性要調(diào)整或者項(xiàng)目要擴(kuò)展子系統(tǒng)，可能會(huì)有遺漏
• 公司域名更改，cookie相關(guān)信息也要一并更改，可能遺漏

上述的問題不外乎三點(diǎn) (1)cookie管理混亂;(2)cookie后續(xù)維護(hù)困難;(3)不同項(xiàng)目之間的 cookie沖突。

3.2 cookie 管理

既然存在這些問題那就想辦法解決，我這邊的做法是在數(shù)據(jù)初始化時(shí)進(jìn)行管理 cookie，前端攔截未定義cookie的操作。

我想要管理好項(xiàng)目中所有的cookie,甚至處理好多項(xiàng)目同二級域名的問題，那就在項(xiàng)目初始化的時(shí)候就定義好所有要用的cookie。之后所有對cookie的操作都是對這些已定義的cookie進(jìn)行處理。

首先我們建立一個(gè)對象來聲明我們項(xiàng)目中要使用的所有的cookie

// cookie-schema.js 
{ 
  cookie1: { 
    name: 'cookie1', // cookie 名稱 
    domain: 'root', // root-根域名 sub-當(dāng)前域名及子域名 current-當(dāng)前域名（默認(rèn)值） 
    path: '/', // 匹配路徑 
    expires: 30 * 24 * 3600 * 1000, // 過期時(shí)間 30d 
    secure: false // https 傳輸 
  }, 
  cookie2: { 
    name: 'cookie2', 
    domain: 'sub', 
    expires: 30 * 24 * 3600 * 1000, // 30d 
    path: '/cookie-test', 
    secure: false 
  } 
} 

如上，cookie-schema.js中就是我們項(xiàng)目中所有要使用的cookie。這個(gè)可以是前端直接自己聲明，如果要處理不同項(xiàng)目之間沖突的問題，也可以專門建立數(shù)據(jù)中臺(tái)。將所有項(xiàng)目可用的cookie放在后臺(tái)配置，在項(xiàng)目初始化時(shí)去加載項(xiàng)目的可用cookie。

感興趣的同學(xué)可以配合使用我的這個(gè)小工具，有詳細(xì)說明：

**Cookie-Util：**https://github.com/Mrlyk/cookie-util

四、cookie 的未來

目前由于cookie帶來對種種隱私問題，各大瀏覽器廠商也開始限制第三方cookie。其中 safari 已經(jīng)完全禁止了第三方cookie，但是對市場影響最大的依然是 Chrome 還沒有這么做，所以大家的感受不是很強(qiáng)烈。

4.1 Google 是如何做的

Google 由于cookie帶來的侵犯隱私問題，已經(jīng)面臨超 100 億美元的罰款。因此 Google 在 2020 年初宣布 Chrome 將在未來的兩三年中完全禁用第三方 cookie。當(dāng)然阻力是很大的，廣告行業(yè)的抵制聲音最大，可以理解??

到現(xiàn)在已經(jīng)快兩年過去了，可以看到 Google 對cookie也是動(dòng)作不斷。從 Chrome 51 推出 SameSite，到 89 版本推出 First-Party Sets 策略，還有Trust Tokens(這個(gè)筆者還未使用過)一步步在增加對三方cookie的限制，同時(shí)對歷史問題提出解決方案。

First-Party Sets

在上面介紹廣告是如何跟蹤我們的說明中，我們可以清楚的看到mmstat.com和taobao.com不是一個(gè)同一個(gè)域名，但是他們卻來自同一家企業(yè)。這種三方cookie可以看作是我們主動(dòng)接入的，我們是不希望他們被瀏覽器干掉的。所以 Google 推出了First-Party Sets策略，配合 Chrome 的Saome-Party屬性，我們可以允許一個(gè)第一方party內(nèi)的域名之間的cookie互相訪問。

當(dāng)然為了防止該策略被濫用，Google 也做出了如下限制：

First-Party Sets 中的域必須由同一組織擁有和運(yùn)營。

所有域名應(yīng)該作為一個(gè)組被用戶識別。

所有域名應(yīng)該共享一個(gè)共同的隱私政策。

同時(shí)，該策略不允許在不相關(guān)的站點(diǎn)之間交換用戶信息，所以單點(diǎn)登錄還是需要使用其他方案。

要使用該方案可以通過提供定義當(dāng)前域名與其他域名的關(guān)系的清單文件來聲明它們是一個(gè)party的成員(或所有者)，文件需要是位于.well-known/first-party-set路由下的 JSON 文件

以 Google 官方的例子，假設(shè)a.example, b.example, c.example希望形成一個(gè)由a.example擁有的 first-party。那就需要聲明如下 JSON 文件：

// https://a.example/.well-known/first-party-set 
{ 
  "owner": "a.example", 
  "members": ["b.example", "c.example"], 
  ... 
} 
 
// https://b.example/.well-known/first-party-set 
{ 
 "owner": "a.example" 
} 
 
// https://c.example/.well-known/first-party-set 
{ 
 "owner": "a.example" 
} 

注意：該方案還在試用階段，chrome 89 ~ 93 可以試用

對 Google 的隱私策略有興趣的同學(xué)可以看一下這篇開者文檔：https://developer.chrome.com/docs/privacy-sandbox/

4.2 cookie Store API

The Cookie Store API provides an asychronous API for managing cookies, while also exposing cookies to service workers.

官方也新增了對cookie操作的新 API，相對于原來使用document.cookie繁瑣操作，這個(gè) API 更加的方便，但是只能在 HTTPS 協(xié)議的下使用，同時(shí)兼容性還很差。使用方法類似于我上方的Cookie-Util工具，感興趣的同學(xué)可以看一下下面的官方文檔。

官方文檔：https://developer.mozilla.org/en-US/docs/Web/API/Cookie_Store_API

4.3 第三方 cookie 何去何從

透過上面的一系列分析，可以看出官方在未來主要打擊的是第三方cookie。不久 Chrome 也要完全禁用這種第三方cookie。那么沒了這些第三方cookie對我們的業(yè)務(wù)有什么影響呢?

• 單點(diǎn)登錄，如果之前是依賴三方cookie做淡點(diǎn)登錄的同學(xué)要特別注意尋找新方案了
• 異常追蹤工具，通常使用第三方cookie來標(biāo)記用戶。被禁止后可能會(huì)造成 UV 暴漲的問題
• 用戶行為分析工具，失去這個(gè)標(biāo)記后可能會(huì)失效
• .......

當(dāng)然我們回到cookie作用的本質(zhì)，是對用戶進(jìn)行標(biāo)記。那我們可以不可以用其他方法來標(biāo)記用戶解決一些問題呢?當(dāng)然是可以的，比如已經(jīng)有很多人在用的瀏覽器指紋。

從普通用戶的角度上說，我們當(dāng)然希望自己的隱私被保護(hù)的更好。但是隱私這堵墻也會(huì)協(xié)助這些巨無霸公司把自己的壁壘筑的越來越高。比如 Google 推出 FloC 模型來分析用戶群體的行為，當(dāng)?shù)谌絚ookie被屏蔽，廣告商要想好好的打廣告還得找回這些公司去使用他們的方案。

從技術(shù)的角度，我們更應(yīng)該關(guān)注的是這些行業(yè)規(guī)范定制者的規(guī)范變更，對任何規(guī)范的變動(dòng)保持警惕，及時(shí)處理對自己項(xiàng)目產(chǎn)生的風(fēng)險(xiǎn)。

參考

HTTP cookies: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/cookies)

Wiki cookie: https://en.wikipedia.org/wiki/HTTP_cookie

當(dāng)瀏覽器全面禁用三方 cookie: https://mp.weixin.qq.com/s?__biz=Mzk0MDMwMzQyOA==&mid=2247490361&idx=1&sn=ebc8dcc4d095cc7ba748827dff158f2b&source=41

詳解 cookie 新增的 SameParty 屬性: https://juejin.cn/post/7002011181221167118

前往微醫(yī)互聯(lián)網(wǎng)醫(yī)院在線診療平臺(tái)，快速問診，3分鐘為你找到三甲醫(yī)生。(https://wy.guahao.com/?channel=influence)

廖宜康，Happy every day 前端開發(fā)工程師！