<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Stateful Tracking on Web Tracking 筆記</title><link>https://web-tracking.dante.tw/docs/stateful-tracking/</link><description>Recent content in Stateful Tracking on Web Tracking 筆記</description><generator>Hugo</generator><language>en</language><atom:link href="https://web-tracking.dante.tw/docs/stateful-tracking/index.xml" rel="self" type="application/rss+xml"/><item><title>如何儲存 identifier：Cookie 以及那些意想不到的地方</title><link>https://web-tracking.dante.tw/docs/stateful-tracking/storing-identifier/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://web-tracking.dante.tw/docs/stateful-tracking/storing-identifier/</guid><description>&lt;h1 id="如何儲存-identifiercookie-以及那些意想不到的地方">
 如何儲存 identifier：Cookie 以及那些意想不到的地方
 &lt;a class="anchor" href="#%e5%a6%82%e4%bd%95%e5%84%b2%e5%ad%98-identifiercookie-%e4%bb%a5%e5%8f%8a%e9%82%a3%e4%ba%9b%e6%84%8f%e6%83%b3%e4%b8%8d%e5%88%b0%e7%9a%84%e5%9c%b0%e6%96%b9">#&lt;/a>
&lt;/h1>
&lt;p>此文我們將討論 stateful 的 tracker 可以如何儲存它的 identifier。一個簡單的直覺是，不就存在 cookie 裡面嗎？是的，的確可以儲存在 cookie 內，但我們還有其他地方可以儲存，所以此文將介紹數個常見的儲存位置，以及他們的優劣。&lt;/p>
&lt;p>只要可以儲存 identifier，就一定可以作到 same-site tracking，畢竟網站 A 存進去的 identifier，網站 A 當然讀得到。不過 cross-site tracking 卻不是如此，如果要做到 cross-site tracking，則追蹤者需要在不同網站維持同一個 identifier，如此才能知道兩個網站的訪客是同一個人，而在不同網站維持同個 identifier 並不是一個簡單的問題。因為cross-site tracking 的隱私危害遠大於 same-site tracking，故此文也會討論每個方法是否支援 cross-site tracking。其中 cookie 的 cross-site tracking 因為能討論的太多了，所以會放到明天的文章。&lt;/p>
&lt;h2 id="cookie">
 Cookie
 &lt;a class="anchor" href="#cookie">#&lt;/a>
&lt;/h2>
&lt;p>若論 stateful tracking，一個簡單的直覺是直接儲存於 cookie 中。確實，identifier 可以直接儲存於 cookie 中。事實上這也是最普遍的 web tracking 形式，更甚至可說是始祖等級的技術。因此這個章節無疑地應該以 cookie 作為開頭。&lt;/p></description></item><item><title>如何達成 Cross-site Tracking：Third Party Cookie &amp; Cookie Syncing</title><link>https://web-tracking.dante.tw/docs/stateful-tracking/cross-site-tracking-with-cookie/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://web-tracking.dante.tw/docs/stateful-tracking/cross-site-tracking-with-cookie/</guid><description>&lt;h1 id="如何達成-cross-site-trackingthird-party-cookie--cookie-syncing">
 如何達成 Cross-site Tracking：Third Party Cookie &amp;amp; Cookie Syncing
 &lt;a class="anchor" href="#%e5%a6%82%e4%bd%95%e9%81%94%e6%88%90-cross-site-trackingthird-party-cookie--cookie-syncing">#&lt;/a>
&lt;/h1>
&lt;p>在前一篇文章，我們討論了如何儲存 identifier，介紹了數個方法。其中幾個方法的介紹中，有提到這可以用來做 cross-site tracking，包含 cookie, HSTS supercookie, document cache, HTTP redirection cache 與 ETag。除了 Cookie 以外，在前文也都討論過可以如何防止了。此文將著重討論 cookie 如何作到 cross-site tracking，如何防禦。此外，我們將介紹一個與之相關的技術稱為 cookie syncing。&lt;/p>
&lt;p>首先複習一下，在上一篇文章提過，cookie 以 domain 為單位區分，也就是 Same-origin Policy (SOP)，&lt;code>blog.example&lt;/code> 和 &lt;code>news.example&lt;/code> 的 cookie 是獨立、互不干擾也不能互相存取的；此外，cookie 會被自動夾帶於 HTTP requests，且可以用 HTTP response 設定。這兩個特性非常重要，之後會不斷用到。&lt;/p>
&lt;h2 id="first-party--third-party-cookie">
 First-party &amp;amp; Third-party Cookie
 &lt;a class="anchor" href="#first-party--third-party-cookie">#&lt;/a>
&lt;/h2>
&lt;p>Cookie 可以被分為兩種：first-party cookie 與 third-party cookie。兩者沒什麼根本性的不同，都是在瀏覽器儲存一些 key-value pairs。它們的差異如同其名稱所示， first-party cookie 是直接儲存於使用者造訪的 domain 底下，而 third-party cookie 則是儲存於其他 domain 底下。&lt;/p></description></item><item><title>殺死 Third-party Cookie，一樣可以做 Cross-site Tracking：CNAME Cloaking, Bounce Trackers, and Link Decorations</title><link>https://web-tracking.dante.tw/docs/stateful-tracking/cross-site-tracking-without-cookie/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://web-tracking.dante.tw/docs/stateful-tracking/cross-site-tracking-without-cookie/</guid><description>&lt;h1 id="殺死-third-party-cookie一樣可以做-cross-site-trackingcname-cloaking-bounce-trackers-and-link-decorations">
 殺死 Third-party Cookie，一樣可以做 Cross-site Tracking：CNAME Cloaking, Bounce Trackers, and Link Decorations
 &lt;a class="anchor" href="#%e6%ae%ba%e6%ad%bb-third-party-cookie%e4%b8%80%e6%a8%a3%e5%8f%af%e4%bb%a5%e5%81%9a-cross-site-trackingcname-cloaking-bounce-trackers-and-link-decorations">#&lt;/a>
&lt;/h1>
&lt;p>先前我們介紹了 third-party cookie 如何用於 web tracking，尤其 cross-site tracking。多數瀏覽器都已經封鎖或即將封鎖 third-party cookie，更何況在許久之前便已有不少人藉由 browser extension 或其他工具阻擋 third-party cookie，這使得傳統的 cross-site tracking 技術不再是穩定可用的。為此，追蹤者也開發了數種其他 cross-site tracking 的方法。在此章節，我們將介紹三種不使用 third-party cookie的 cross-site tracking 技術，分別是 CNAME cloaking、bounce trackers 以及 link decoration。&lt;/p>
&lt;h2 id="cname-cloaking">
 CNAME Cloaking
 &lt;a class="anchor" href="#cname-cloaking">#&lt;/a>
&lt;/h2>
&lt;h3 id="cname-cloaking-是什麼">
 CNAME Cloaking 是什麼
 &lt;a class="anchor" href="#cname-cloaking-%e6%98%af%e4%bb%80%e9%ba%bc">#&lt;/a>
&lt;/h3>
&lt;p>CNAME 是一種 DNS record 的型態，其所表達的意思大概是「我被稱為 &lt;code>tracker.example&lt;/code>，但其實我就是 &lt;code>tracker-real.example&lt;/code>」。&lt;/p></description></item><item><title>如何對付傳統追蹤技術 (I)：Content Blocking (Ad Blocking)</title><link>https://web-tracking.dante.tw/docs/stateful-tracking/content-blocking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://web-tracking.dante.tw/docs/stateful-tracking/content-blocking/</guid><description>&lt;h1 id="如何對付傳統追蹤技術-icontent-blocking-ad-blocking">
 如何對付傳統追蹤技術 (I)：Content Blocking (Ad Blocking)
 &lt;a class="anchor" href="#%e5%a6%82%e4%bd%95%e5%b0%8d%e4%bb%98%e5%82%b3%e7%b5%b1%e8%bf%bd%e8%b9%a4%e6%8a%80%e8%a1%93-icontent-blocking-ad-blocking">#&lt;/a>
&lt;/h1>
&lt;p>在所有反制 web tracking 的方法中，最古早也最普遍被使用的方法是 content blocking。正如其名，content blocking 的邏輯很簡單，就是直接把 tracker 阻擋掉。假設現在 &lt;code>example.com/tracker.js&lt;/code> 是個用於 web tracking 的 script，它會偷偷把使用者的瀏覽紀錄傳回 &lt;code>example.com&lt;/code>，我們當然可以用各種方式（像是阻擋 third-party cookie）讓它沒辦法正確地辨識出我是誰，但有個更簡單的方式是：一開始不要讓 &lt;code>example.com/tracker.js&lt;/code> 載入，不就沒問題了？這就是 content blocking 的核心精神。&lt;/p>
&lt;p>Content blocking 聽起來像是一個很複雜的技術名詞，但有個與之密切相關且大家都聽過的東西叫做 &amp;ldquo;ad blocker&amp;rdquo;，現在主流的 ad blocker 幾乎都是藉由 content blocking 達到，也就是直接把取得廣告用的 Javascript 或其他資源（e.g. 圖片、影片等）的 request 阻擋掉。&lt;/p>
&lt;p>在此文我不會嚴格區分 content blocker 與 ad blocker，因為兩者非常類似，很難界定。例如，幾乎所有的知名 ad blocker 同時都會阻擋 tracker，即便 tracker 並沒有在投放廣告。為了避免讀者誤以為 ad blocker 只是在阻擋可見的廣告，我將使用 content blocker 來稱呼這一系列的工具。&lt;/p></description></item><item><title>如何對付傳統追蹤技術 (II)：如何繞過基於 Filter List 的 Content Blocking</title><link>https://web-tracking.dante.tw/docs/stateful-tracking/content-blocking-circumvention/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://web-tracking.dante.tw/docs/stateful-tracking/content-blocking-circumvention/</guid><description>&lt;h1 id="如何對付傳統追蹤技術-ii如何繞過基於-filter-list-的-content-blocking">
 如何對付傳統追蹤技術 (II)：如何繞過基於 Filter List 的 Content Blocking
 &lt;a class="anchor" href="#%e5%a6%82%e4%bd%95%e5%b0%8d%e4%bb%98%e5%82%b3%e7%b5%b1%e8%bf%bd%e8%b9%a4%e6%8a%80%e8%a1%93-ii%e5%a6%82%e4%bd%95%e7%b9%9e%e9%81%8e%e5%9f%ba%e6%96%bc-filter-list-%e7%9a%84-content-blocking">#&lt;/a>
&lt;/h1>
&lt;p>正如任何資安領域，只要有攻擊，就會有防禦，只要有防禦，就會有繞過。既然 content blocking 會阻擋 tracking script，也就有人會嘗試繞過。如同前面所提到的，content blocker 在識別 tracking script 與廣告的手段中，最主流的是使用黑名單。因此，如何繞過黑名單自然會是最受人矚目的問題。此文將整理數個技術上可行的辦法，有些很常見，有些則是可遇不可求甚至很奇葩的。&lt;/p>
&lt;p>稍微複習一下。Filter list 可以分成兩種型態：&lt;/p>
&lt;ul>
&lt;li>Resource blocking：封鎖整個 domain 或特定 URL path，讓 request 無法發出&lt;/li>
&lt;li>Element hiding：隱藏或刪除特定的 DOM element&lt;br>
因為後者主要是做 ad blocking，對於防禦 tracker 沒什麼幫助，所以本文會著重在 resource blocking 的繞過。&lt;/li>
&lt;/ul>
&lt;h2 id="常見的繞過方式">
 常見的繞過方式
 &lt;a class="anchor" href="#%e5%b8%b8%e8%a6%8b%e7%9a%84%e7%b9%9e%e9%81%8e%e6%96%b9%e5%bc%8f">#&lt;/a>
&lt;/h2>
&lt;h3 id="更改-url-paths">
 更改 URL paths
 &lt;a class="anchor" href="#%e6%9b%b4%e6%94%b9-url-paths">#&lt;/a>
&lt;/h3>
&lt;p>一個很直覺的方法是，既然 URL path 會被封鎖，那我就把 URL path 改掉，不就繞過 filter list 了？舉例來說，假設 &lt;code>tracker.example/tracker.js&lt;/code> 被封鎖了，那就改成 &lt;code>tracker.example/tracker2.js&lt;/code>，如果又被封鎖了，就繼續改。出乎意料的是，這方法超級有效。因為多數 filter list 是靠社群夥伴通報與維護，如果追蹤者更改 URL path，往往要等到有人發現並通報後，maintainer 才能將其加入 filter list。改檔案位置只需要花幾分鐘的時間，但 filter list maintainer 可能要好幾天甚至好幾個月後才會發現 filter list 被繞過了。&lt;/p></description></item><item><title>如何對付傳統追蹤技術 (III)：Apple’s Intelligent Tracking Prevention (ITP)</title><link>https://web-tracking.dante.tw/docs/stateful-tracking/apple-itp/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://web-tracking.dante.tw/docs/stateful-tracking/apple-itp/</guid><description>&lt;h1 id="如何對付傳統追蹤技術-iiiapples-intelligent-tracking-prevention-itp">
 如何對付傳統追蹤技術 (III)：Apple’s Intelligent Tracking Prevention (ITP)
 &lt;a class="anchor" href="#%e5%a6%82%e4%bd%95%e5%b0%8d%e4%bb%98%e5%82%b3%e7%b5%b1%e8%bf%bd%e8%b9%a4%e6%8a%80%e8%a1%93-iiiapples-intelligent-tracking-prevention-itp">#&lt;/a>
&lt;/h1>
&lt;p>在介紹完最傳統的 content blocking 後，接下來我們來看點比較新穎的技術。傳統 content blocking 在乎的是盡可能不要載入 tracker，不過現在較為新穎的技術在乎的是，即便真的載入 tracker 了，也要把傷害降到最低。首先我認為最值得拿出來討論的是 Safari 的 Intelligent Tracking Prevention (ITP)。如果平常有在關注蘋果的發表會，應該會發現他們很喜歡強調 Safari 防止 web tracking 的機制做得多好，其中很重要的一環就是 ITP。故此文我們將介紹 ITP 的運作方式。&lt;/p>
&lt;p>在開始前想提醒一下，因為 ITP 更新的速度其實蠻快的，在我撰文時 ITP 的最新版是 3.0（其實 3.0 不是官方稱呼，不過官方好像也沒給個版本號），如果有數年後回來的讀者，可能要注意一下有些東西是過時的。原本想說這篇文章可以從我前年的筆記改寫就好，結果 ITP 改的東西多到不如重寫一篇 QQ&lt;/p>
&lt;h2 id="背景介紹">
 背景介紹
 &lt;a class="anchor" href="#%e8%83%8c%e6%99%af%e4%bb%8b%e7%b4%b9">#&lt;/a>
&lt;/h2>
&lt;p>從 2017 年起，Safari 內建了一款名為 Intelligent Tracking Prevention (ITP) 的隱私保護機制。ITP 的主要目標是解決 cross-site tracking，至於 same-site tracking，雖然也有一些防護機制，但那不是重點。因此 ITP 與之前介紹的 content blocking 的目標略有不同，content blocking 目標是所有 web tracking 機制，無論 same-site 或 cross-site。因為 ITP 內建於 Safari，而 macOS 與 iOS 又有很高的市占率，尤其 iOS 上只有 Safari 可以用（其他都是包著 Safari 皮的瀏覽器，感謝 Apple 的壟斷地位），因此 ITP 對於廣告與追蹤產業的影響力不容小覷。&lt;/p></description></item><item><title>如何對付傳統追蹤技術 (IV)：Firefox’s Tracking Protection</title><link>https://web-tracking.dante.tw/docs/stateful-tracking/firefox-tracking-protection/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://web-tracking.dante.tw/docs/stateful-tracking/firefox-tracking-protection/</guid><description>&lt;h1 id="如何對付傳統追蹤技術-ivfirefoxs-tracking-protection">
 如何對付傳統追蹤技術 (IV)：Firefox’s Tracking Protection
 &lt;a class="anchor" href="#%e5%a6%82%e4%bd%95%e5%b0%8d%e4%bb%98%e5%82%b3%e7%b5%b1%e8%bf%bd%e8%b9%a4%e6%8a%80%e8%a1%93-ivfirefoxs-tracking-protection">#&lt;/a>
&lt;/h1>
&lt;p>看完 Safari 的隱私保護，下一個來看 Firefox 的保護機制。Mozilla 也同樣在隱私上花了許多心力，開發了許多精彩的防禦機制。Firefox 的保護機制大概分成幾個部份，我們將依序介紹之。&lt;/p>
&lt;h2 id="enhanced-tracking-protection">
 Enhanced Tracking Protection
 &lt;a class="anchor" href="#enhanced-tracking-protection">#&lt;/a>
&lt;/h2>
&lt;p>Firefox 最主要的防禦機制是 Enhanced Tracking Protection (ETP)。雖然取了一個很潮的名字，但 ETP 本質上就是 content blocking，不過 Mozilla 花了許多心思在確保網站不會因為 content blocking 而壞掉。&lt;/p>
&lt;p>ETP 所使用的 filter list 來自 
 &lt;a href="https://disconnect.me/trackerprotection">Disconnect&lt;/a>，並且會去區分不同性質的 tracker（例如 social media trackers, cross-site tracking cookies, fingerprinters, cryptominers 等），此外，ETP 也有區分模式，Standard 會阻擋多數的 tracker，Strict 則會連那些躲在廣告或影片播放器裡面的 tracker 都擋掉，當然使用者也可以根據自己的需求去選擇哪些 tracker 要阻擋掉。&lt;/p></description></item></channel></rss>