蘋果公司前不久對 Safari 瀏覽器進行一次重大更新，這次更新完全禁用了第三方 Cookie，這意味著，默認情況下，各大廣告商或網(wǎng)站將無法對你的個人隱私進行追蹤。而微軟和 Mozilla 等也紛紛采取了措施禁用第三方 Cookie，但是由于這些瀏覽器市場份額較小，并沒有給市場帶來巨大的沖擊。
從 2017 年截至 2019 年底， Google 面臨的罰款總額已經(jīng)超過 93 億歐元，其中一大原因便是侵犯用戶數(shù)據(jù)隱私。迫于巨大壓力，Google Chrome 官方團隊前不久也宣布，為了提升用戶隱私和安全，未來兩年將完全禁用第三方 Cookie。
在完全不能寫入三方 Cookie 的情況下，將會對前端的數(shù)據(jù)讀寫方式，甚至是整個廣告行業(yè)帶來巨大影響。
眾所周知，HTTP 協(xié)議是無狀態(tài)的協(xié)議，如果你在同一個客戶端向服務(wù)器發(fā)送多次請求，服務(wù)器不會知道這些請求來自同一客戶端。
這正是 HTTP 協(xié)議得以廣泛應(yīng)用的原因，試想一下，如果它是有狀態(tài)協(xié)議，你必須要時刻與服務(wù)器建立鏈接，那么如果連接意外斷開，整個會話就會丟失，重新連接之后一般需要從頭開始；而如果是無狀態(tài)協(xié)議，使得會話與連接本身獨立起來，這樣即使連接斷開了，會話狀態(tài)也不會受到嚴重傷害，保持會話也不需要保持連接本身。
如果 HTTP 協(xié)議只是用來訪問靜態(tài)文件，那不會有任何問題，但是如果你要為廣大用戶提供更好的服務(wù)，服務(wù)器就需要知道每個請求具體來自于哪個用戶，比如你在逛淘寶的時候你只需要登錄一次，當你發(fā)起一次購買請求，服務(wù)器就已經(jīng)知道你登錄過了，不會再讓你進行登錄。
所以 HTTP 協(xié)議需要占用瀏覽器的一小塊存儲，存儲當前訪問用戶的一些 ”狀態(tài)“，然后每次發(fā)起 HTTP 請求，請求中就會攜帶這些狀態(tài)，從而讓服務(wù)器知道你是誰。 Cookie 出現(xiàn)的的意義就是為了解決這個問題，讓無狀態(tài)的 HTTP 協(xié)議擁有一小塊記憶。
但是， Cookie 一經(jīng)出現(xiàn)，就成了各大廣告和購物網(wǎng)站窺探用戶隱私的利器，他們使用第三方 Cookie 不斷獲取你的數(shù)據(jù)，那么什么第三方 Cookie 呢？
如果是你正常的正在逛著天貓，天貓會把你的信息寫入一些 Cookie 到 .tmall.com 這個域下，然而打開控制臺你會看到，并不是所有 Cookie 都是 .tmall.com 這個域下的，里面還有很多其他域下的 Cookie ，這些所有非當前域下的 Cookie 都屬于第三方 Cookie，雖然你可能從來沒訪問過這些域，但是他們已經(jīng)悄悄的通過這些第三方 Cookie來標識你的信息，然后把你的個人信息發(fā)送過去了。
而 .tmall.com 這個域下的 Cookie 都屬于第一方 Cookie，那么為什么還需要第三方 Cookie 呢？再打開 taobao.com，你會發(fā)現(xiàn)你已經(jīng)不需要再登錄了，因為淘寶、天貓都屬于阿里旗下的產(chǎn)品，阿里為他們提供統(tǒng)一的登錄服務(wù)，同時，你的登錄信息也會存到這個統(tǒng)一登錄服務(wù)的域下，所以存到這個域下的 Cookie 就成了三方 Cookie。
我們再打開已經(jīng)完全禁用了第三方 Cookie 的 Safari，發(fā)現(xiàn)只剩下 .tmall.com 這個域下的 Cookie 了。
這時你會發(fā)現(xiàn)即使你已經(jīng)登錄了天貓，再訪問淘寶也還是需要登錄的，你已經(jīng)無法享用這樣的功能了，而三方 Cookie 可不僅僅就這么點用途，在 Web 開發(fā)中，三方 Cookie 的應(yīng)用非常之廣，下面我們再來具體看幾個應(yīng)用場景：
大多數(shù) Web 站點都會引用一些第三方 SDK 來進行前端異?；蛐阅鼙O(jiān)控，這些 SDK 會通過一些接口將監(jiān)控到的信息上傳到他們的服務(wù)器。一般它們都需要標識每個用戶來方便排查問題或者統(tǒng)計 UV 數(shù)據(jù)，所以當你一此請求這個站點的時候，它們可能會在你的站點上 set 一個 Cookie，后續(xù)所有的日志上報請求都會帶上這個 Cookie 。
由于一般這些第三方 SDK 都是用于監(jiān)控的通用服務(wù)，它們肯定會擁有自己獨立的域名，比如 log.com，它在你的域名 mysite.com 下種下的 Cookie 就屬于第三方 Cookie。
在電商業(yè)務(wù)中，追蹤流量、導(dǎo)流量、轉(zhuǎn)換率、銷售額這些都是商家最關(guān)心的問題。這時候你就可以使用 Facebook Pixel，簡單來說 Facebook Pixel 像素就是一串 JavaScript 代碼，可以追蹤廣告的轉(zhuǎn)化量、改進受眾定位、使廣告花費回報最大化。
當訪客進入到被設(shè)有 Facebook Pixel 的頁面時，便會觸發(fā)這段代碼。比如，查看了商品或者加入購物車， Facebook Pixel 便會向系統(tǒng)發(fā)送請求來記錄這些行為，系統(tǒng)可以利用這些收到的行為信息進一步的做追蹤和優(yōu)化。
舉一個實際例子，我們進入一個國外的電商網(wǎng)站 Brava Fabrics ，你會發(fā)現(xiàn)已經(jīng)被寫入了一堆 facebook.com 下的三方 cookie：
我猜測這個 fr 應(yīng)該就是用來標識我身份信息的 cookie，然后點擊幾個頁面，在 network 里面找到了幾個 facebook 發(fā)送的請求，下面是其中一個：
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
復(fù)制代碼查看詳情你會發(fā)現(xiàn)，有下面幾個主要的參數(shù)：
dl: https://bravafabrics.com/collections/a-moment-of-blissrl: https://bravafabrics.com/復(fù)制代碼這時 facebook 已經(jīng)知道了我從 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 關(guān)聯(lián)起來，然后他就可以好好的分析你的行為了：
而如此強大的追蹤能力，只需要你復(fù)制一段 Facebook Pixel 的 JavaScript 腳本到你的頁面上就可以了。而這一切能力就建立在一個小小的 Cookie 的基礎(chǔ)上，因為有了這個 Cookie ，Facebook 才能將這些行為與它的賬號體系進行關(guān)聯(lián)。
再來看一個我們國內(nèi)的例子，平時我們在國內(nèi)的搜索引擎或視頻網(wǎng)站上搜索到一些東西，然后打開購物網(wǎng)站就可以收到各種你興趣的相關(guān)推薦，這已經(jīng)是大眾習(xí)以為常的事情了，各大購物網(wǎng)站、廣告商，會通過第三方 Cookie 收集你的年齡、性別、瀏覽歷史等從而判斷你的興趣喜好，然后帶給你精準的信息推薦。
比如，我們在瀏覽百度、優(yōu)酷、天貓等網(wǎng)站時，都能看到幾個 .mmstat.com 這個域下的 Cookie
百度：
優(yōu)酷：
天貓：
當你在百度、優(yōu)酷、淘寶等進行一系列的操作時，.mmstat.com 已經(jīng)悄悄的通過三方 Cookie 把你的個人信息運送到了他們那邊。 .mmstat.com 應(yīng)該就是阿里旗下的大數(shù)據(jù)營銷平臺阿里媽媽旗下的域名（只是個人猜測）。打開阿里媽媽首頁，可以看到，其號稱是更懂消費者的數(shù)據(jù)金礦，已經(jīng)建立起5億用戶的身份識別體系。你的每一次搜索、每一次購買、都會讓它變的更精準，下一次你就收到更精準的推薦。
當然，三方 Cookie 只是眾多獲取你喜好信息的一種方式，只不過這種方式更便捷，成本更低。
最近幾大瀏覽器針對 Cookie 策略的頻繁改動，意味著三方 Cookie 被全面禁用已經(jīng)不遠了：
在 Safari 13.1、Firefox 79 版本中，三方 Cookie 已經(jīng)被默認禁用，但是由于這些游覽器市場份額較小，并沒有給市場帶來巨大的沖擊。因為阿里的登錄信息是統(tǒng)一存在一個三方 Cookie 下的，淘寶剛開始的處理方式，甚至是彈個框出來，告訴用戶手動開啟三方 Cookie ：
但是這樣的處理方式對于龐大的用戶來講肯定體驗是極低的，解決方案可能是先將 Cookie 種在當前域下，所有就有了我們上面的測試結(jié)果，淘寶、天貓兩個網(wǎng)站需要登錄兩次。
但是三方 Cookie做的事情遠不止這些，等到 Chrome 全面禁用之前，一定要提前作出改變。
還好由于三方 Cookie 對 Google 的廣告業(yè)務(wù)影響較大，所以其沒有立即進行禁用，而是一直陸續(xù)修改一些小的策略來對三方 Cookie 進行限制，比如 SameSite
SameSite 是 Chrome 51 版本為瀏覽器的 Cookie 新增的了一個屬性， SameSite 阻止瀏覽器將此 Cookie 與跨站點請求一起發(fā)送。其主要目標是降低跨源信息泄漏的風(fēng)險。同時也在一定程度上阻止了 CSRF 攻擊。
SameSite 可以避免跨站請求發(fā)送 Cookie，有以下三個屬性：
Strict 是最嚴格的防護，將阻止瀏覽器在所有跨站點瀏覽上下文中將 Cookie 發(fā)送到目標站點，即使在遵循常規(guī)鏈接時也是如此。因此這種設(shè)置可以阻止所有 CSRF 攻擊。然而，它的用戶友好性太差，即使是普通的 GET 請求它也不允許通過。
例如，對于一個普通的站點，這意味著如果一個已經(jīng)登錄的用戶跟蹤一個發(fā)布在公司討論論壇或電子郵件上的網(wǎng)站鏈接，這個站點將不會收到 Cookie ，用戶訪問該站點還需要重新登陸。
不過，具有交易業(yè)務(wù)的網(wǎng)站很可能不希望從外站鏈接到任何交易頁面，因此這種場景最適合使用 strict 標志。
對于允許用戶從外部鏈接到達本站并使用已有會話的網(wǎng)站站，默認的 Lax 值在安全性和可用性之間提供了合理的平衡。 Lax 屬性只會在使用危險 HTTP 方法發(fā)送跨域 Cookie 的時候進行阻止，例如 POST 方式。同時，使用 JavaScript 腳本發(fā)起的請求也無法攜帶 Cookie。
例如，一個用戶在 A 站點 點擊了一個 B 站點（GET請求），而假如 B 站點 使用了Samesite-cookies=Lax，那么用戶可以正常登錄 B 站點。相對地，如果用戶在 A 站點提交了一個表單到 B站點（POST請求），那么用戶的請求將被阻止，因為瀏覽器不允許使用 POST 方式將 Cookie 從A域發(fā)送到Ｂ域。
瀏覽器會在同站請求、跨站請求下繼續(xù)發(fā)送 Cookies，不區(qū)分大小寫。
在舊版瀏覽器，如果 SameSite 屬性沒有設(shè)置，或者沒有得到運行瀏覽器的支持，那么它的行為等同于 None，Cookies 會被包含在任何請求中——包括跨站請求。
但是，在 Chrome 80+ 版本中，SameSite 的默認屬性是 SameSite=Lax。換句話說，當 Cookie 沒有設(shè)置 SameSite 屬性時，將會視作 SameSite 屬性被設(shè)置為Lax 。如果想要指定 Cookies 在同站、跨站請求都被發(fā)送，那么需要明確指定 SameSite 為 None。具有 SameSite=None 的 Cookie 也必須標記為安全并通過 HTTPS 傳送。這意味著所有使用 JavaScript 腳本收集用戶信息的請求默認將不能攜帶三方 Cookie。
然而這個改動并不會造成太大的影響，它只是給各大網(wǎng)站提了一個信號，因為你只需要把你想要發(fā)送的 Cookie 的屬性手動設(shè)置為 none 即可：
真正可怕的是我們將無法直接指定 SameSite 為 None，只能用戶自己去選擇，這才是真正的默認禁用。
Chrome 也宣布，將在下個版本也就是 Chrome 83 版本，在訪客模式下禁用三方 Cookie，在 2022 年全面禁用三方 Cookie，到時候，即使你能指定 SameSite 為 None 也沒有意義，因為你已經(jīng)無法寫入第三方 Cookie 了。
現(xiàn)在，我們想象一下，當瀏覽器禁用了三方 Cookie，而我們又沒有作出任何改變的情況下，會發(fā)生什么：
可能有一天你會突然發(fā)現(xiàn)，你的 UV 暴漲，但是 PV 卻沒有什么變化，那可能是你的打點 SDK 使用的三方 Cookie 被禁用掉了。
這時這個 SDK 將無法在你的域下寫入一個三方 Cookie，導(dǎo)致你的每次刷新頁面它都會帶一個新的 Cookie 回來，后端接受到的信號就是這些都是不同用戶的請求，所以都會計入 UV。同時你在排查問題時，你也無法將用戶的行為串聯(lián)起來，導(dǎo)致排查非常困難。
上面我們提到，廣告服務(wù)通過你的年齡、性別、行為來推斷你的喜好，從而推送給你精準的廣告，使用了三方 Cookie 來進行信息追蹤的廣告主將無法獲得你的這些喜好，從而無法推薦給你感興趣的廣告。
這時，廣告主只能在你當時的訪問環(huán)境進行預(yù)定義廣告，比如你正在訪問寵物網(wǎng)站，就給你推薦寵物用品等等。
同時，可能之前廣告主還會通過 Cookie 判斷你閱讀某個廣告的次數(shù)，一旦你閱讀同一個廣告多次但是沒有發(fā)生轉(zhuǎn)化，其就會停止向你推送該廣告。或者你已經(jīng)購買過了這個商品，那你也不會再看到這個廣告了。如果沒有了頻率控制，那么你可能要連續(xù)很多天盯著一個你永遠也不會去點的廣告，或者你會持續(xù)看到一個你已經(jīng)購買過的產(chǎn)品廣告。
當你查看一則廣告時，該廣告會在你的瀏覽器中放置一個 Cookie，表示你已經(jīng)看到它。如果隨后你進入轉(zhuǎn)化階段（購買、下載等），廣告主們需要能追蹤每一個他們投放到你網(wǎng)站上的轉(zhuǎn)化率，這樣他們才能計算投放的效果，從而作出優(yōu)化策略，如果你無法再追蹤廣告轉(zhuǎn)化率了，那么也很難再進行投放了。
當然，以上只是建立在你沒有進行任何改變的基礎(chǔ)上，距離全面禁用三方 Cookie 還有一年多的時間，這應(yīng)該是一個足夠的時間讓你及時作出應(yīng)對。
雖然，這對你帶來的可能是糟糕的廣告體驗，但是全面禁用三方 Cookie 對我們用戶來講肯定是一件好事，因為你的信息不會被輕而易舉的就被別人追蹤了，你的隱私信息也不會容易被泄漏。
然而事情真的那么簡單么？貪婪的廣告商絕對不會直接放棄對你的信息追蹤，首先他們已經(jīng)對你掌握了足夠多的信息，而且三方 Cookie 只是眾多獲取你信息的一種手段，只不過這種方法更方便簡單，為了利益，他們一定會找到更多的替代方案：
如果我們引入了一個三方的 SDK，比如 google analytics ，說明我們對其是信任的，它對我們的信息收集追蹤都是在允許范圍內(nèi)的。所以這些 SDK 依然可以使用第一方 Cookie 來完成用戶身份標識符。
比如，gtag.js 和 analytics.js 會設(shè)置以下 Cookie 用戶標識用戶信息：
但是，這些 Cookie 并不是第三方 Cookie，而是設(shè)在你的域下的第一方 Cookie，比如打開 twitter 的 Cookie 信息：
我們發(fā)現(xiàn) _ga 、_gid 這兩個 Cookie 正是設(shè)置在其自己域下面的。
如果使用正常的 Set-Cookie 的形式，google analytics 是無法直接將 Cookie 設(shè)置到 twitter.com 這個域下面的，而且 google analytics 發(fā)起的日志收集請求也無法攜帶 twitter.com 這個域下的 Cookie。
打開 sdk 的代碼我發(fā)現(xiàn)里面有使用 js 設(shè)置 Cookie 的代碼：
并且，收集日志的請求中也又沒攜帶任何 Cookie，而是把這信息帶在了參數(shù)中：
這樣的方式就模擬了使用三方 Cookie 標識用戶信息的過程，并且完全可以替代它。總而言之禁用三方 Cookie 對這種三方 SDK 的影響并不大，只要稍微改變一下思維即可。
當然，由于 Safari 和 Firefox 已經(jīng)全面禁用了三方 Cookie，一些廣告營銷服務(wù)也正在給出使用一方 Cookie 的替代方案，比如 Facebook Pixel：
你允許了其讀取一方 Cookie 就意味著它能獲取你更多的數(shù)據(jù)，這意味著你需要承擔(dān)更大的用戶信息泄漏的風(fēng)險。而且使用一方 Cookie 也不像使用三方 Cookie 那樣靈活，在某些場景下也是有很大限制的。
三方 Cookie 的主要作用是標識你的身份，從而在你下一次訪問時知道你是誰，那么如果有一種技術(shù)直接就可以獲取你的唯一標識時，那么就不需要再存儲 Cookie 了，這個技術(shù)就是 “瀏覽器指紋” 。
“瀏覽器指紋”是一種通過瀏覽器對網(wǎng)站可見的配置和設(shè)置信息來跟蹤 Web 瀏覽器的方法，瀏覽器指紋就像我們?nèi)耸稚系闹讣y一樣，每個人擁有一份接近于獨一無二的配置。
如果單單拿出一個配置來講可能很多人和你擁有一樣的配置，比如下面的：
Mac OS X 10_14_611.91% 的人與我的配置相同8 個人中有一個和我配置相同Chrome 版本：Chrome，并且版本是：81.0.4044.920.08% 的人與我的配置相同1250 個人中有一個和我配置相同UTC+8 時間：UTC+8 時間是 2020.4.15 23:00:002.30% 的人與我的配置相同43 個人中有一個和我配置相同如果單獨看每個配置，那他們都不能作為你獨一無二的特征，但是綜合起來看呢？比如就看這三項，三項的配置與你都相同的人的概率就會大大減小了。以上只是一些簡單的特征，比如系統(tǒng)版本，瀏覽器版本，這些只需要一個簡單的 navigator.userAgent 屬性就可以拿到。
像這樣的屬性還有非常多個，他們可能來自 HTTP Header、Javascript attributes、瀏覽器插件 等等
上面的 HTTP Header 中就包含了大量的定制化特性，可以看到每一項配置中與我相同的概率是非常低的，然而這些信息屬于普通的瀏覽器指紋，普通指紋可以理解為容易被發(fā)現(xiàn)并且容易修改的部分，而且你也可以輕易的篡改他們，有些配置比如 User-Agent 、language 使用 JavaScript 的 navigator 對象獲取是最準確而且不會被篡改的。下面還有一些其他常見的 JavaScript 屬性：
這里面包含一些使用 Javascript 很容易獲取的一些配置：
Screen width：屏幕寬度Screen height：屏幕高度Cookies enabled：是否允許 CookieContent language：語言信息List of fonts：字體信息Timezone：時區(qū)信息Navigator properties：Navigator 對象中包含的屬性信息以上這些信息非常容易獲取，而且?guī)в械男畔⑤^少，最后生成出來的指紋可能碰撞的概率就越大，實際上通過 JS 能獲取的遠不止這些，下面還有一些重復(fù)率非常低的指標：
Canvas 是 HTML5 中用于在網(wǎng)頁上繪制 2D 圖形元素。瀏覽器在繪制圖形時，會調(diào)用操作系統(tǒng)的繪圖接口，即便使用 Cavans 繪制相同的元素，但是由于系統(tǒng)的差別，不同瀏覽器使用了不同的圖形處理引擎、不同的圖片導(dǎo)出選項、不同的默認壓縮級別、對抗鋸齒、次像素渲染等算法也不同。
具體獲取流程如下：在畫布上渲染一些文字，再用 toDataURL 轉(zhuǎn)換出來，你就會得到屬于你的 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");
復(fù)制代碼上面的圖中可以看到，Canvas 指紋和我相同的概率是 <0.01% 的，可見這是一個在瀏覽器指紋中非常重要的指標。
WebGL 是一種用于在網(wǎng)頁上呈現(xiàn)3D圖像的 JavaScript 瀏覽器API。網(wǎng)站可利用 WebGL 來識別你的設(shè)備指紋：
WebGL 報告 —— 完整的 WebGL 瀏覽器報告表是可獲取、可被檢測的。在一些情況下，它會被轉(zhuǎn)換成為哈希值以便更快地進行分析。WebGL 圖像 —— 渲染和轉(zhuǎn)換為哈希值的隱藏3D圖像。由于最終結(jié)果取決于進行計算的硬件設(shè)備，因此此方法會為設(shè)備及其驅(qū)動程序的不同組合生成唯一值。這種方式為不同的設(shè)備組合和驅(qū)動程序生成了唯一值。WebRTC （網(wǎng)頁實時通信，Web Real Time Communication），是可以讓瀏覽器有音視頻實時通信的能力，通常被需要快速直接連接的網(wǎng)絡(luò)應(yīng)用程序所應(yīng)用。即便你使用了代理，網(wǎng)站也能借此獲取你真實的公共和本地IP地址。該插件可被用于泄漏你的本地 IP 地址或追蹤媒體設(shè)備。WebRTC 會暴露你的：
就算用戶禁用了 JavaScript ，網(wǎng)站也可以通過純 CSS 來獲取到一些信息，比如這樣：
@media(device-width: 1920px) { body { background: url("https://example.org/1920.png"); }}復(fù)制代碼通過統(tǒng)計 1920.png 這個圖片的請求日志，便可知道有哪些用戶的窗口寬度是 1920px。
綜合以上的指標特征，可以計算出一個屬于你自己的唯一的 uuid，這就是你的 "瀏覽器指紋" 了。當然，計算時不能簡單的將上述指標進行疊加，因為某些指標在一些場景下聚合度比較高，每個指標帶來的信息量也不相同，一般每個指標都擁有一個自己的 "信息熵" :
信息熵（entropy）是接收的每條消息中包含的信息的平均量，熵越高，則能傳輸越多的信息，熵越低，則意味著傳輸?shù)男畔⒃缴佟?/p>
在計算 uuid 時，一般信息熵較大的指標會擁有較大的權(quán)重，這樣可以大大降低碰撞率，提高 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);
復(fù)制代碼你也可以單獨獲取這些信息：
const client = new ClientJS();
client.getBrowserData();
client.getFingerprint();
client.getCustomFingerprint(...);
client.isCanvas();
client.getCanvasPrint();
client.getFlashVersion();
client.isSilverlight();
client.getSilverlightVersion();
// 。。。
復(fù)制代碼作為一名普通用戶，我會感嘆，太難了，我很難保護我的個人隱私，收集我信息的平臺無處不在，收集我信息的手段也是各種各樣。。。
在現(xiàn)實世界里，沒有什么會保持不變的。
作為一名開發(fā)者，你要時刻保持警惕，有危機意識，第一時間更新你的技術(shù)以應(yīng)對外部環(huán)境的變化，否則你就會被淘汰。
文中如有錯誤，歡迎在評論區(qū)指正，如果這篇文章幫助到了你，歡迎點贊和關(guān)注。
想閱讀更多優(yōu)質(zhì)文章、可關(guān)注我的github博客，你的star?、點贊和關(guān)注是我持續(xù)創(chuàng)作的動力！
推薦關(guān)注我的微信公眾號【code秘密花園】，每天推送高質(zhì)量文章，我們一起交流成長。
