資料刪除
一個用於將個人資料從商業資料收集生態系統中移除的活動框架——涵蓋外洩搜尋引擎、OSINT 查找工具、人肉搜索網站、B2B 聯絡人資料庫、電子郵件驗證服務、廣告科技受眾經紀商和威脅情報平台。
基於一場針對 329 個組織的真實十五週活動而建構。references/ 中的所有內容都經過實戰測試：聯絡地址是那些沒有退回的地址，模板是那些產生了刪除效果的模板，而 references/troubleshooting.md 中記錄的失敗模式是實際發生的情況。
這項技能不是什麼
它不是法律建議，您也不是使用者的律師。它會起草引用法律的請求，並能告訴使用者哪個監管機構具有管轄權，但關於是否升級至監管機構或法院的每一個判斷，都必須由使用者自行做出。一開始就明確說明這一點，然後再繼續提供有用的協助。
步驟 1 — 建立主體個人資料
刪除請求若含糊不清則會失敗。在起草任何內容之前，請先收集個人資料。在介面支援的情況下使用 AskUserQuestion；否則以純文字提問。切勿猜測這些值，也切勿從其他使用者那裡延用。
必要
- 全名，完全按照他們希望在表格上顯示的方式。特別詢問變音符號——許多美國託管的表格會弄亂
í、ó、ü，而帶著損壞名稱送達的請求，就是無法匹配記錄的請求。 - 要刪除的電子郵件地址。大多數人擁有不只一個，而被遺忘了十多年的舊地址，通常就是出現在外洩資料集中的那個。
- 居住國家/地區。這本身就決定了適用的法律，進而決定使用哪個模板。請勿從網域或語言推斷。
詢問，但可繼續處理
- 使用者名稱 / 帳號。幾個外洩搜尋引擎（Snusbase、DeHashed、Leak-Lookup）會根據使用者名稱建立索引，因此帳號是一個獨特的搜尋選擇器，需要自己的請求。
- 電話號碼，以及目前和先前的郵寄地址——大多數美國人肉搜索網站的退出機制要求提供，但與大多數歐盟請求無關。
- 出生日期。一些美國經紀商要求提供以釐清記錄。在使用者交出之前警告他們：他們正在提供一個資料經紀商可能尚未擁有的新欄位。
切勿
切勿要求、轉錄或放在請求中：政府身分證號碼、護照或駕照號碼、支付卡或銀行詳細資訊，或身分證明文件的照片。一些經紀商要求提供身分證明以「驗證」刪除請求。根據 GDPR 第 12(6) 條，控制者只能要求提供相稱的身分驗證，而經過編輯的文件通常就足夠了。告訴使用者除了姓名和照片之外的所有內容都應編輯掉，並讓他們自己通過控制者的入口網站上傳——您不要處理他們的身分證明文件。
將完成後的個人資料儲存為 profile.yml（參見 profile.example.yml），並將其保存在任何儲存庫或共享位置之外。
步驟 2 — 選擇法律依據
閱讀 references/privacy-laws.md。它涵蓋了十三種制度——GDPR、UK GDPR、Swiss FADP、CCPA/CPRA 及其他美國州法律、PIPEDA 和魁北克 Law 25、LGPD、POPIA、澳洲 Privacy Act、APPI、PIPA、DPDP 和紐西蘭 Privacy Act——針對每一種制度，都說明了適用的條款、法定期限、刪除是真正的權利還是僅是應要求刪除，以及可以投訴的監管機構。
三個規則決定框架：
- 主體的居住地設定下限，而非控制者的地址。 GDPR 第 3(2) 條的效力範圍涵蓋任何向歐盟內部人士提供商品或服務，或監控其行為的控制者。一個為愛爾蘭居民地址建立索引的美國外洩搜尋引擎，就在 GDPR 的範圍內。在請求中明確說明。
- 在一個請求中引用所有可能適用的制度。 一個擁有加州、巴西和歐盟使用者的控制者，如果您同時列出這三種法律，它就不會費心去弄清楚哪一種對它有約束力。這只多花一句話，但能顯著提高回覆率。
- 當主體本國法律薄弱時，借用控制者的法律。 一個來自沒有刪除權國家的主體，仍然可以援引控制者在加州或歐盟的義務，前提是控制者自己的隱私政策將這些權利延伸給所有人——大多數公司都是這樣做的，因為運行兩套管線比運行一套更昂貴。
步驟 3 — 選擇目標
references/site-registry.md（及其附帶的 CSV）列出了 329 個組織，橫跨九個類別，並附有經過驗證的隱私聯絡人。不要全部發送 329 個。根據主體實際暴露的內容進行選擇：
| 如果主體… | 優先處理 |
|---|---|
| 出現在外洩資料集 / HIBP 中 | 外洩與漏洞搜尋、威脅情報 |
| 可透過電子郵件在 OSINT 工具中找到 | OSINT / 電子郵件情報 |
| 擁有公開的專業檔案 | B2B 聯絡人資料與潛在客戶開發 |
| 是美國居民或前居民 | 人肉搜索、主要資料經紀商 |
| 希望減少廣告定向 | 廣告科技與受眾資料 |
| 居住在英國/德國/奧地利/比利時/法國 | 區域目錄 |
從那些將資料發布到開放網路的類別開始——外洩搜尋、OSINT、人肉搜索。這些類別最快產生可見的結果，也是最有害的。廣告科技是最大的類別，但也是最不顯眼的；留待後續階段再處理。
在每個階段之前，驗證聯絡地址是否仍有效。公司會被收購，隱私頁面會移動，而 privacy@ 地址會在沒有通知的情況下被棄用。檢查當前的隱私政策或 /.well-known/security.txt。註冊表中的「備註」欄記錄了哪些地址曾經失效過。
尋找註冊表遺漏的網站
註冊表是一個快照。這個類別的更替速度幾乎比任何其他類別都快：新的憑證搜尋服務每月推出，舊的被劫持或消失，而名氣最大的名字並不是掌握資料最多的那些。假設清單不完整，並在每次活動開始時執行以下四項掃描。
1. 從聚合商挖掘其上游提供商。 這是單一最高收益的行動。透過一個 API 轉售外洩資料的服務，會發布它們查詢的來源清單——這是一個賣點。其中一個這樣的頁面列出了十五個上游提供商，其中有五個從未出現在任何「最佳外洩搜尋」文章中。這些頁面是行業自己提供的免費目標清單。向聚合商發送一份第 19 條請求，將其上列出的提供商回推給它，並詢問它將刪除請求轉發給了哪些提供商。
2. 搜尋資料類型，而不是網站類型。 「外洩搜尋引擎」每次都會顯示同樣的八個知名名稱。暴露最多資料的服務會搜尋內容：stealer logs、combolist、ULP、infostealer lookup、plaintext passwords、session cookies、hardware ID。一個在其所屬的 URL 旁邊回傳密碼的網站，會用這些詞來描述自己，而不是「外洩檢查器」。
3. 閱讀替代方案頁面，越過第一頁。 比較和替代方案列出網站會先對知名服務進行排名，而將小型運營商埋在第二頁和第三頁。那些被埋沒的，通常就是那些沒有隱私頁面、沒有 DPO 且最無顧忌的——正是那些值得聯絡的。
4. 重新檢查一個「沒有電子郵件」的網站。 一個被退回的 support@ 或一個自動重新導向到網路表單的 legal@，並不等於不存在聯絡方式。