當瀏覽器全面禁用三方 Cookie

時間 2020-04-17

原文原文鏈接

蘋果公司前不久對 Safari 瀏覽器進行一次重大更新，此次更新徹底禁用了第三方 Cookie，這意味着，默認狀況下，各大廣告商或網站將沒法對你的我的隱私進行追蹤。而微軟和 Mozilla 等也紛紛採起了措施禁用第三方 Cookie，可是因爲這些瀏覽器市場份額較小，並無給市場帶來巨大的衝擊。前端

從 2017 年截至 2019 年末， Google 面臨的罰款總額已經超過 93 億歐元，其中一大緣由即是侵犯用戶數據隱私。迫於巨大壓力，Google Chrome 官方團隊前不久也宣佈，爲了提高用戶隱私和安全，將來兩年將徹底禁用第三方 Cookie。git

在徹底不能寫入三方 Cookie 的狀況下，將會對前端的數據讀寫方式，甚至是整個廣告行業帶來巨大影響。github

Cookie 的意義

衆所周知，HTTP 協議是無狀態的協議，若是你在同一個客戶端向服務器發送屢次請求，服務器不會知道這些請求來自同一客戶端。算法

這正是 HTTP 協議得以普遍應用的緣由，試想一下，若是它是有狀態協議，你必需要時刻與服務器創建連接，那麼若是鏈接意外斷開，整個會話就會丟失，從新鏈接以後通常須要從頭開始；而若是是無狀態協議，使得會話與鏈接自己獨立起來，這樣即便鏈接斷開了，會話狀態也不會受到嚴重傷害，保持會話也不須要保持鏈接自己。canvas

若是 HTTP 協議只是用來訪問靜態文件，那不會有任何問題，可是若是你要爲廣大用戶提供更好的服務，服務器就須要知道每一個請求具體來自於哪一個用戶，好比你在逛淘寶的時候你只須要登陸一次，當你發起一次購買請求，服務器就已經知道你登陸過了，不會再讓你進行登陸。後端

因此 HTTP 協議須要佔用瀏覽器的一小塊存儲，存儲當前訪問用戶的一些」狀態「，而後每次發起 HTTP 請求，請求中就會攜帶這些狀態，從而讓服務器知道你是誰。 Cookie 出現的的意義就是爲了解決這個問題，讓無狀態的 HTTP 協議擁有一小塊記憶。跨域

可是， Cookie 一經出現，就成了各大廣告和購物網站窺探用戶隱私的利器，他們使用第三方 Cookie 不斷獲取你的數據，那麼什麼第三方 Cookie 呢？瀏覽器

第三方 Cookie

若是是你正常的正在逛着天貓，天貓會把你的信息寫入一些 Cookie 到 .tmall.com 這個域下，然而打開控制檯你會看到，並非全部 Cookie 都是 .tmall.com 這個域下的，裏面還有不少其餘域下的 Cookie ，這些全部非當前域下的 Cookie 都屬於第三方 Cookie，雖然你可能歷來沒訪問過這些域，可是他們已經悄悄的經過這些第三方 Cookie來標識你的信息，而後把你的我的信息發送過去了。安全

而 .tmall.com 這個域下的 Cookie 都屬於第一方 Cookie，那麼爲何還須要第三方 Cookie 呢？再打開 taobao.com，你會發現你已經不須要再登陸了，由於淘寶、天貓都屬於阿里旗下的產品，阿里爲他們提供統一的登陸服務，同時，你的登陸信息也會存到這個統一登陸服務的域下，因此存到這個域下的 Cookie 就成了三方 Cookie。服務器

咱們再打開已經徹底禁用了第三方 Cookie 的 Safari，發現只剩下 .tmall.com 這個域下的 Cookie 了。

這時你會發現即便你已經登陸了天貓，再訪問淘寶也仍是須要登陸的，你已經沒法享用這樣的功能了，而三方 Cookie 可不只僅就這麼點用途，在 Web 開發中，三方 Cookie 的應用很是之廣，下面咱們再來具體看幾個應用場景：

三方Cookie的用途

前端日誌打點

大多數 Web 站點都會引用一些第三方 SDK 來進行前端異常或性能監控，這些 SDK 會經過一些接口將監控到的信息上傳到他們的服務器。通常它們都須要標識每一個用戶來方便排查問題或者統計 UV 數據，因此當你一此請求這個站點的時候，它們可能會在你的站點上 set 一個 Cookie，後續全部的日誌上報請求都會帶上這個 Cookie 。

因爲通常這些第三方 SDK 都是用於監控的通用服務，它們確定會擁有本身獨立的域名，好比 log.com，它在你的域名 mysite.com 下種下的 Cookie 就屬於第三方 Cookie。

廣告營銷神器 - Facebook Pixel

在電商業務中，追蹤流量、導流量、轉換率、銷售額這些都是商家最關心的問題。這時候你就可使用 Facebook Pixel，簡單來講 Facebook Pixel 像素就是一串 JavaScript 代碼，能夠追蹤廣告的轉化量、改進受衆定位、使廣告花費回報最大化。

當訪客進入到被設有 Facebook Pixel 的頁面時，便會觸發這段代碼。好比，查看了商品或者加入購物車， Facebook Pixel 便會向系統發送請求來記錄這些行爲，系統能夠利用這些收到的行爲信息進一步的作追蹤和優化。

舉一個實際例子，咱們進入一個國外的電商網站 Brava Fabrics ，你會發現已經被寫入了一堆 facebook.com 下的三方 cookie：

我猜想這個 fr 應該就是用來標識我身份信息的 cookie，而後點擊幾個頁面，在 network 裏面找到了幾個 facebook 發送的請求，下面是其中一個：

https://www.facebook.com/tr/?id=382444918612794&ev=PageView&dl=https%3A%2F%2Fbravafabrics.com%2Fcollections%2Fa-moment-of-bliss&rl=https%3A%2F%2Fbravafabrics.com%2F&if=false&ts=1586868288778&sw=1680&sh=1050&ud[ct]=eb045d78d273107348b0300c01d29b7552d622abbc6faf81b3ec55359aa9950c&ud[country]=eb045d78d273107348b0300c01d29b7552d622abbc6faf81b3ec55359aa9950c&v=2.9.15&r=stable&ec=0&o=30&fbp=fb.1.1586867082370.951509876&it=1586868284974&coo=false&rqm=GET

查看詳情你會發現，有下面幾個主要的參數：

dl: https://bravafabrics.com/collections/a-moment-of-bliss
rl: https://bravafabrics.com/

這時 facebook 已經知道了我從 https://bravafabrics.com/ 來到了 https://bravafabrics.com/collections/a-moment-of-bliss 這個頁面，同時，這個請求會攜帶 fr=09wX7ui8MrvCh2SIa..BdNoGz.f.F6R.0.0.Belanb.AWXCDx 這個 Cookie。

來到 facebook，當你登陸後，facebook 會把剛剛這些 Cookie 和你的 facebook Id 關聯起來，而後他就能夠好好的分析你的行爲了：

有人在你的網站上完成了購買。
有人註冊進行試用，或者以其餘方式將本身標識爲你網站上的潛在客戶。
有人在你網站上的購買過程當中輸入他們的付款信息。
有人將產品添加你網站上的購物車中。
有人選擇特定版本的產品，例如選擇某種顏色。
有人發起告終帳，但沒有付款
...

而如此強大的追蹤能力，只須要你複製一段 Facebook Pixel 的 JavaScript 腳本到你的頁面上就能夠了。而這一切能力就創建在一個小小的 Cookie 的基礎上，由於有了這個 Cookie ，Facebook 才能將這些行爲與它的帳號體系進行關聯。

無處不在的的 mmstat

再來看一個咱們國內的例子，平時咱們在國內的搜索引擎或視頻網站上搜索到一些東西，而後打開購物網站就能夠收到各類你興趣的相關推薦，這已是大衆習覺得常的事情了，各大購物網站、廣告商，會經過第三方 Cookie 收集你的年齡、性別、瀏覽歷史等從而判斷你的興趣喜愛，而後帶給你精準的信息推薦。

好比，咱們在瀏覽百度、優酷、天貓等網站時，都能看到幾個 .mmstat.com 這個域下的 Cookie

百度：

優酷：

天貓：

當你在百度、優酷、淘寶等進行一系列的操做時，.mmstat.com 已經悄悄的經過三方 Cookie 把你的我的信息運送到了他們那邊。 .mmstat.com 應該就是阿里旗下的大數據營銷平臺阿里媽媽旗下的域名（只是我的猜想）。打開阿里媽媽首頁，能夠看到，其號稱是更懂消費者的數據金礦，已經創建起5億用戶的身份識別體系。你的每一次搜索、每一次購買、都會讓它變的更精準，下一次你就收到更精準的推薦。

固然，三方 Cookie 只是衆多獲取你喜愛信息的一種方式，只不過這種方式更便捷，成本更低。

瀏覽器的策略

最近幾大瀏覽器針對 Cookie 策略的頻繁改動，意味着三方 Cookie 被全面禁用已經不遠了：

Firefox、Safari —— 默認禁用

在 Safari 13.1、Firefox 79 版本中，三方 Cookie 已經被默認禁用，可是因爲這些遊覽器市場份額較小，並無給市場帶來巨大的衝擊。由於阿里的登陸信息是統一存在一個三方 Cookie 下的，淘寶剛開始的處理方式，甚至是彈個框出來，告訴用戶手動開啓三方 Cookie ：

可是這樣的處理方式對於龐大的用戶來說確定體驗是極低的，解決方案多是先將 Cookie 種在當前域下，全部就有了咱們上面的測試結果，淘寶、天貓兩個網站須要登陸兩次。

可是三方 Cookie作的事情遠不止這些，等到 Chrome 全面禁用以前，必定要提早做出改變。

Chrome —— SameSite Cookie

還好因爲三方 Cookie 對 Google 的廣告業務影響較大，因此其沒有當即進行禁用，而是一直陸續修改一些小的策略來對三方 Cookie 進行限制，好比 SameSite

SameSite 是 Chrome 51 版本爲瀏覽器的 Cookie 新增的了一個屬性， SameSite 阻止瀏覽器將此 Cookie 與跨站點請求一塊兒發送。其主要目標是下降跨源信息泄漏的風險。同時也在必定程度上阻止了 CSRF 攻擊。

SameSite 能夠避免跨站請求發送 Cookie，有如下三個屬性：

Strict

Strict 是最嚴格的防禦，將阻止瀏覽器在全部跨站點瀏覽上下文中將 Cookie 發送到目標站點，即便在遵循常規連接時也是如此。所以這種設置能夠阻止全部 CSRF 攻擊。然而，它的用戶友好性太差，即便是普通的 GET 請求它也不容許經過。

例如，對於一個普通的站點，這意味着若是一個已經登陸的用戶跟蹤一個發佈在公司討論論壇或電子郵件上的網站連接，這個站點將不會收到 Cookie ，用戶訪問該站點還須要從新登錄。

不過，具備交易業務的網站極可能不但願從外站連接到任何交易頁面，所以這種場景最適合使用 strict 標誌。

Lax

對於容許用戶從外部連接到達本站並使用已有會話的網站站，默認的 Lax 值在安全性和可用性之間提供了合理的平衡。 Lax 屬性只會在使用危險 HTTP 方法發送跨域 Cookie 的時候進行阻止，例如 POST 方式。同時，使用 JavaScript 腳本發起的請求也沒法攜帶 Cookie。

例如，一個用戶在 A 站點點擊了一個 B 站點（GET請求），而假如 B 站點使用了Samesite-cookies=Lax，那麼用戶能夠正常登陸 B 站點。相對地，若是用戶在 A 站點提交了一個表單到 B站點（POST請求），那麼用戶的請求將被阻止，由於瀏覽器不容許使用 POST 方式將 Cookie 從A域發送到Ｂ域。

None

瀏覽器會在同站請求、跨站請求下繼續發送 Cookies，不區分大小寫。

策略更新

在舊版瀏覽器，若是 SameSite 屬性沒有設置，或者沒有獲得運行瀏覽器的支持，那麼它的行爲等同於 None，Cookies 會被包含在任何請求中——包括跨站請求。

可是，在 Chrome 80+ 版本中，SameSite 的默認屬性是 SameSite=Lax。換句話說，當 Cookie 沒有設置 SameSite 屬性時，將會視做 SameSite 屬性被設置爲Lax 。若是想要指定 Cookies 在同站、跨站請求都被髮送，那麼須要明確指定 SameSite 爲 None。具備 SameSite=None 的 Cookie 也必須標記爲安全並經過 HTTPS 傳送。這意味着全部使用 JavaScript 腳本收集用戶信息的請求默認將不能攜帶三方 Cookie。

然而這個改動並不會形成太大的影響，它只是給各大網站提了一個信號，由於你只須要把你想要發送的 Cookie 的屬性手動設置爲 none 便可：

真正可怕的是咱們將沒法直接指定 SameSite 爲 None，只能用戶本身去選擇，這纔是真正的默認禁用。

Chrome 也宣佈，將在下個版本也就是 Chrome 83 版本，在訪客模式下禁用三方 Cookie，在 2022 年全面禁用三方 Cookie，到時候，即便你能指定 SameSite 爲 None 也沒有意義，由於你已經沒法寫入第三方 Cookie 了。

當三方 Cookie 被全面禁止

如今，咱們想象一下，當瀏覽器禁用了三方 Cookie，而咱們又沒有做出任何改變的狀況下，會發生什麼：

前端日誌異常

可能有一天你會忽然發現，你的 UV 暴漲，可是 PV 卻沒有什麼變化，那多是你的打點 SDK 使用的三方 Cookie 被禁用掉了。

這時這個 SDK 將沒法在你的域下寫入一個三方 Cookie，致使你的每次刷新頁面它都會帶一個新的 Cookie 回來，後端接受到的信號就是這些都是不一樣用戶的請求，因此都會計入 UV。同時你在排查問題時，你也沒法將用戶的行爲串聯起來，致使排查很是困難。

智能廣告推薦消失

上面咱們提到，廣告服務經過你的年齡、性別、行爲來推斷你的喜愛，從而推送給你精準的廣告，使用了三方 Cookie 來進行信息追蹤的廣告主將沒法得到你的這些喜愛，從而沒法推薦給你感興趣的廣告。

這時，廣告主只能在你當時的訪問環境進行預約義廣告，好比你正在訪問寵物網站，就給你推薦寵物用品等等。

同時，可能以前廣告主還會經過 Cookie 判斷你閱讀某個廣告的次數，一旦你閱讀同一個廣告屢次可是沒有發生轉化，其就會中止向你推送該廣告。或者你已經購買過了這個商品，那你也不會再看到這個廣告了。若是沒有了頻率控制，那麼你可能要連續數日盯着一個你永遠也不會去點的廣告，或者你會持續看到一個你已經購買過的產品廣告。

沒法追蹤轉化率

當你查看一則廣告時，該廣告會在你的瀏覽器中放置一個 Cookie，表示你已經看到它。若是隨後你進入轉化階段（購買、下載等），廣告主們須要能追蹤每個他們投放到你網站上的轉化率，這樣他們才能計算投放的效果，從而做出優化策略，若是你沒法再追蹤廣告轉化率了，那麼也很難再進行投放了。

固然，以上只是創建在你沒有進行任何改變的基礎上，距離全面禁用三方 Cookie 還有一年多的時間，這應該是一個足夠的時間讓你及時做出應對。

是好是壞

雖然，這對你帶來的多是糟糕的廣告體驗，可是全面禁用三方 Cookie 對咱們用戶來說確定是一件好事，由於你的信息不會被垂手可得的就被別人追蹤了，你的隱私信息也不會容易被泄漏。

然而事情真的那麼簡單麼？貪婪的廣告商絕對不會直接放棄對你的信息追蹤，首先他們已經對你掌握了足夠多的信息，並且三方 Cookie 只是衆多獲取你信息的一種手段，只不過這種方法更方便簡單，爲了利益，他們必定會找到更多的替代方案：

使用一方 Cookie 替代三方 Cookie

若是咱們引入了一個三方的 SDK，好比 google analytics ，說明咱們對其是信任的，它對咱們的信息收集追蹤都是在容許範圍內的。因此這些 SDK 依然可使用第一方 Cookie 來完成用戶身份標識符。

好比，gtag.js 和 analytics.js 會設置如下 Cookie 用戶標識用戶信息：

可是，這些 Cookie 並非第三方 Cookie，而是設在你的域下的第一方 Cookie，好比打開 twitter 的 Cookie 信息：

咱們發現 _ga 、_gid 這兩個 Cookie 正是設置在其本身域下面的。

若是使用正常的 Set-Cookie 的形式，google analytics 是沒法直接將 Cookie 設置到 twitter.com 這個域下面的，並且 google analytics 發起的日誌收集請求也沒法攜帶 twitter.com 這個域下的 Cookie。

打開 sdk 的代碼我發現裏面有使用 js 設置 Cookie 的代碼：

而且，收集日誌的請求中也又沒攜帶任何 Cookie，而是把這信息帶在了參數中：

這樣的方式就模擬了使用三方 Cookie 標識用戶信息的過程，而且徹底能夠替代它。總而言之禁用三方 Cookie 對這種三方 SDK 的影響並不大，只要稍微改變一下思惟便可。

固然，因爲 Safari 和 Firefox 已經全面禁用了三方 Cookie，一些廣告營銷服務也正在給出使用一方 Cookie 的替代方案，好比 Facebook Pixel：

你容許了其讀取一方 Cookie 就意味着它能獲取你更多的數據，這意味着你須要承擔更大的用戶信息泄漏的風險。並且使用一方 Cookie 也不像使用三方 Cookie 那樣靈活，在某些場景下也是有很大限制的。

瀏覽器指紋

三方 Cookie 的主要做用是標識你的身份，從而在你下一次訪問時知道你是誰，那麼若是有一種技術直接就能夠獲取你的惟一標識時，那麼就不須要再存儲 Cookie 了，這個技術就是「瀏覽器指紋」。

「瀏覽器指紋」是一種經過瀏覽器對網站可見的配置和設置信息來跟蹤 Web 瀏覽器的方法，瀏覽器指紋就像咱們人手上的指紋同樣，每一個人擁有一份接近於獨一無二的配置。

若是單單拿出一個配置來說可能不少人和你擁有同樣的配置，好比下面的：

系統版本：
- 個人系統版本是 Mac OS X 10_14_6
- 大約 11.91% 的人與個人配置相同
- 大約每 8 我的中有一個和我配置相同
Chrome 版本：
- 我使用的瀏覽器是 Chrome，而且版本是：81.0.4044.92
- 大約 0.08% 的人與個人配置相同
- 大約每 1250 我的中有一個和我配置相同
UTC+8 時間：
- 個人UTC+8 時間是 2020.4.15 23:00:00
- 大約 2.30% 的人與個人配置相同
- 大約每 43 我的中有一個和我配置相同

若是單獨看每一個配置，那他們都不能做爲你獨一無二的特徵，可是綜合起來看呢？好比就看這三項，三項的配置與你都相同的人的機率就會大大減少了。以上只是一些簡單的特徵，好比系統版本，瀏覽器版本，這些只須要一個簡單的 navigator.userAgent 屬性就能夠拿到。

像這樣的屬性還有很是多個，他們可能來自 HTTP Header、Javascript attributes、瀏覽器插件 等等

HTTP Header

上面的 HTTP Header 中就包含了大量的定製化特性，能夠看到每一項配置中與我相同的機率是很是低的，然而這些信息屬於普通的瀏覽器指紋，普通指紋能夠理解爲容易被發現而且容易修改的部分，並且你也能夠輕易的篡改他們，有些配置好比 User-Agent 、language 使用 JavaScript 的 navigator 對象獲取是最準確並且不會被篡改的。下面還有一些其餘常見的 JavaScript 屬性：

Javascript attributes

這裏麪包含一些使用 Javascript 很容易獲取的一些配置：

Screen width：屏幕寬度
Screen height：屏幕高度
Cookies enabled：是否容許 Cookie
Content language：語言信息
List of fonts：字體信息
Timezone：時區信息
Navigator properties：Navigator 對象中包含的屬性信息
...

以上這些信息很是容易獲取，並且帶有的信息較少，最後生成出來的指紋可能碰撞的機率就越大，實際上經過 JS 能獲取的遠不止這些，下面還有一些重複率很是低的指標：

Canvas 指紋

Canvas 是 HTML5 中用於在網頁上繪製 2D 圖形元素。瀏覽器在繪製圖形時，會調用操做系統的繪圖接口，即使使用 Cavans 繪製相同的元素，可是因爲系統的差異，不一樣瀏覽器使用了不一樣的圖形處理引擎、不一樣的圖片導出選項、不一樣的默認壓縮級別、對抗鋸齒、次像素渲染等算法也不一樣。

具體獲取流程以下：在畫布上渲染一些文字，再用 toDataURL 轉換出來，你就會獲得屬於你的 Cavans 指紋：

const canvas = document.getElementById("canvas-fingerprint");
    const context = canvas.getContext("2d");
    context.font = "18pt Arial";
    context.textBaseline = "top";
    context.fillText("canvas-fingerprint-test", 2, 2);
    return canvas.toDataURL("image/jpeg");

上面的圖中能夠看到，Canvas 指紋和我相同的機率是 <0.01% 的，可見這是一個在瀏覽器指紋中很是重要的指標。

WebGL

WebGL 是一種用於在網頁上呈現3D圖像的 JavaScript 瀏覽器API。網站可利用 WebGL 來識別你的設備指紋：

WebGL 報告 —— 完整的 WebGL 瀏覽器報告表是可獲取、可被檢測的。在一些狀況下，它會被轉換成爲哈希值以便更快地進行分析。
WebGL 圖像 —— 渲染和轉換爲哈希值的隱藏3D圖像。因爲最終結果取決於進行計算的硬件設備，所以此方法會爲設備及其驅動程序的不一樣組合生成惟一值。這種方式爲不一樣的設備組合和驅動程序生成了惟一值。

WebRTC

WebRTC （網頁實時通訊，Web Real Time Communication），是可讓瀏覽器有音視頻實時通訊的能力，一般被須要快速直接鏈接的網絡應用程序所應用。即使你使用了代理，網站也能借此獲取你真實的公共和本地IP地址。該插件可被用於泄漏你的本地 IP 地址或追蹤媒體設備。WebRTC 會暴露你的：

公共IP地址
本地IP地址
媒體設備的數量及其哈希值

CSS

就算用戶禁用了 JavaScript ，網站也能夠經過純 CSS 來獲取到一些信息，好比這樣：

@media(device-width: 1920px) {
  body {
    background: url("https://example.org/1920.png");
  }
}

經過統計 1920.png 這個圖片的請求日誌，即可知道有哪些用戶的窗口寬度是 1920px。

UUID 的計算

綜合以上的指標特徵，能夠計算出一個屬於你本身的惟一的 uuid，這就是你的 "瀏覽器指紋" 了。固然，計算時不能簡單的將上述指標進行疊加，由於某些指標在一些場景下聚合度比較高，每一個指標帶來的信息量也不相同，通常每一個指標都擁有一個本身的 "信息熵" :

信息熵（entropy）是接收的每條消息中包含的信息的平均量，熵越高，則能傳輸越多的信息，熵越低，則意味着傳輸的信息越少。

在計算 uuid 時，通常信息熵較大的指標會擁有較大的權重，這樣能夠大大下降碰撞率，提升 uuid 的準確性。

固然，這些也不用你本身去挨個費勁的去獲取了，使用 clientjs（https://github.com/jackspirou/clientjs）能夠垂手可得的幫你獲取這些指標，並最終獲取 uuid：

// Create a new ClientJS object
const client = new ClientJS();

// Get the client's fingerprint id
const fingerprint = client.getFingerprint();

// Print the 32bit hash id to the console
console.log(fingerprint);

你也能夠單獨獲取這些信息：

const client = new ClientJS();
  client.getBrowserData();
  client.getFingerprint();
  client.getCustomFingerprint(...);
  client.isCanvas();
  client.getCanvasPrint();
  client.getFlashVersion();
  client.isSilverlight();
  client.getSilverlightVersion();
  // 。。。