iOS 隱私與便利的前世今生

iOS 隱私與便利的前世今生

Apple 隱私原則及 iOS 歷年對隱私保護的功能調整

Theme by slidego

[2023–08–01] iOS 17 Update

對於之前演講的最新 iOS 17 隱私相關調整補充。

Link Tracking Protection

Safari 會自動移除網址的 Tracking Parameter 參數 (e.g. fbclid 、 gclid …)

• 舉例： https://zhgchg.li/post/1?gclid=124 點擊後會變 https://zhgchg.li/post/1
• 目前測試 iOS 17 Developer Beta 4， fbxxx 、 gcxxx . .等等會被移掉， utm_ 是有保留的；不確定正式版 iOS 17 或日後 iOS 18 會不會再加強。
• 如果想知道最嚴格情況下的效果可安裝 iOS DuckDuckGo 瀏覽器進行測試。
• 詳細測試細節請參考「 iOS17 Safari 的新功能會把網址裡的 fbclid 跟 gclid 砍掉 」大大的這篇文章。

Privacy Manifest .xprivacy & Report

開發者需把使用到的 User Privacy 宣告在內， 並也需要要求有使用到的 SDK 提供該 SDK 的 Privacy Manifest。

*另外也增加第三方 SDK Signature

XCode 15 能透過 Manifest 產生 Privacy Report 供開發者在 App Store 上做 App 隱私設定。

Required reason API

為避免部分有機會得出 fingerprinting 的 Foundation API 被濫用，蘋果開始針對部分 Foundation API 做管控； 需要在 Mainfest 中宣告為何要使用 。

目前比較有影響的是 UserDefault 即屬於要宣告的 API。

從 2023 年秋季開始，如果你上傳到 App Store Connect 的新 App 或 App 更新使用了需要聲明原因的 API (包括來自第三方 SDK 的內容)，而你沒有在 App 的隱私清單中提供批准的原因，那麼你會收到通知。從 2024 年春季開始，若要將新 App 或 App 更新上傳到 App Store Connect，你需要在 App 的隱私清單中註明批准的原因，以準確反映你的 App 如何使用相應 API。

如果目前批准原因的涵蓋範圍內並未包含某個需要聲明原因的 API 的用例，且你確信這個用例可讓你的 App 用戶直接受益，請告訴我們。

Tracking Domain

發送 Tracking 資訊的 API Domain 需宣告在 privacy manifest .xprivacy 並在使用者同意追蹤後才能發起網路請求，否則此 Domain 的網路請求全部都會被系統攔截。

可從 XCode Netowrk 工具中檢查 Tracking Domain 是否被攔截：

目前實測 Facebook、Google 的 Tracking Domain 都會被偵測到，需要照規定列入 Tracking Domain 並詢問權限。

• graph.facebook.com : Facebook 相關數據統計
• app-measurement.com : Google 相關數據統計：GA/Firebase….

因此請注意 FB/Google 數據統計在 iOS 17 後可能會大幅流失，因為未詢問權限、不允許追蹤，會完全收不到數據；根據以往實作詢問追蹤的成效，大約有 7 成的使用者都會按不允許。

• 開發者自己的打 API 送 Tracking 方式，蘋果也說需要同上列管 Tracking Domain
• 如果 Tracking Domain 跟 API Domain 相同則需分開一個獨立的 Tracking Domain (e.g. api.zhgchg.li -> tracking.zhgchg.li)
• 目前暫時無法知道蘋果如何控管開發者自己的 Tracking，用 XCode 15 測試自家的沒有被發現。
• 不清楚官方是否會用工具檢測行為、或是審核人員人工查看

fingerprinting 依然禁止。

前言

這次很榮幸能參加 MOPCON 演講 ，但因疫情關係改成線上直播形式蠻遺憾的，無法認識更多新朋友；這次演講的主題是「iOS 隱私與便利的前世今生」主要想跟大家分享 Apple 關於隱私的原則及這些年來 iOS 基於這些隱私原則所做的功能調整。

iOS 隱私與便利的前世今生 | Pinkoi, We Are Hiring!

相信這幾年開發者或是 iPhone 用戶應該都對以下功能調整並不陌生：

• iOS ≥ 13： 所有支援第三方登入的 App 都需要多實作 Sign in with Apple，否則無法成功上架 App
• iOS ≥ 14： 剪貼簿存取警告
• iOS ≥ 14.5： IDFA 必須允許後才能存取，幾乎等同封殺 IDFA
• iOS ≥ 15 ：Private Relay，使用 Proxy 隱藏使用者原始 IP 位址
• iOS ≥ 16 ：剪貼簿存取需使用者授權
• ….還有很多很多，會在文章後跟大家分享

Why?

如果不清楚 Apple 的隱私原則，甚至會覺得為何 Apple 這幾年不斷地在跟開發者、廣告商作對？很多大家用得很習慣的功能都被封鎖了。

再追完「 WWDC 2021 — Apple’s privacy pillars in focus 」及「 Apple privacy white paper — A Day in the Life of Your Data 」兩份文件後如夢初醒，原來我們早已在不知不覺中洩漏許多個人隱私並且讓廣告商或社群媒體賺的盆滿缽滿，在我們的日常生活中已經達到無孔不入的境界。

參考 Apple privacy white paper 改寫，以下以虛構人物哈里為例；為大家講述隱私是如何洩漏的及可能造成的危害。

首先是哈里 iPhone 上的使用紀錄。

左邊是網頁瀏覽紀錄： 可以看到分別造訪了跟車子、iPhone 13、精品有關的網站

右邊是已安裝的 App： 有投資、旅遊、社交、購物、還有嬰兒攝影機…這些 App

哈里的線下人生

線下活動會留下記錄的地方例如：發票、信用卡刷卡紀錄、行車記錄器…等等

組合

你可能會想說，我瀏覽不同的網站、裝不同的 App (甚至根本沒登入)、再到線下活動怎麼可能有機會讓某個服務串起所有資料？

答案是：就技術手段是有的，而且「可能」或是「已經」局部發生。

如上圖所示：

• 未登入時網站與網站之間可以透過 Third-Party Cookie、IP Address + 裝置資訊算出的 Fingerprint 在不同網站中識別出同個瀏覽者。
• 登入時網站與網站之間可以透過註冊資料，如姓名、生日、電話、Email、身分證字號…串起你的資料
• App 與 App 之間可以透過取得 Device UUID 在不同 App 中識別出同個使用者、URL Scheme 嗅探手機上其他已安裝的 App、Pasteboard 在 App 與 App 間傳遞資料；另外一樣也可在使用者登入後用註冊資料串起資料。
• App 與網站之間同樣可以用 Third-Party Cookie、Fingerprint、Pasteboard 傳遞資料
• 線上與線下活動的串連可能發生在，銀行端蒐集信用卡消費記錄、記帳 App、發票蒐集 App、行車記錄器 App…等等，都有機會把線下活動與線上資料串接在一起

事實證明，技術上是可行的；那究竟躲在所有網站、App 之後的第三方是誰呢？

諸如家大業大的 Facebook、Google 都靠個人廣告獲得不少收益；許多網站、App 也都會串接 Facebook、Google SDK…所以一切都很難說，這還是看得到，更多時候我們根本不知道網站、App 用了哪些第三方廣告、數據蒐集服務，在背後偷偷紀錄著我們的一舉一動。

我們假設哈里所有的活動，背後都偷藏著同一個第三方在默默收集他的資料，那麼在它的眼裡，哈里可能的輪廓如下：

左邊是個人資料，可能來自網站註冊資料、外送資料；右邊是依照哈里的活動紀錄打上的行為、興趣標籤。

在它眼中的哈里，可能比哈里還更了解自己；這些資料用在社交媒體，可以讓使用者更加沈淪；用在廣告上，可以刺激哈里過度消費或是營造鳥籠效應(EX: 推薦你買新褲子，你買了褲子就會買合適的鞋子來穿搭，買了鞋子就會再買襪子…沒完沒了)。

如果你覺得以上已經夠可怕了，還有更可怕的：

有你的個人資料又知道你的經濟狀況…要做惡的話不敢想像，例如：綁架、竊盜…

目前的隱私保護方式

• 法律規範 (EX: SGS-BS10012 個資驗證、CCPA、GDPR…)
• 隱私權協議、去識別化

主要還是透過法規約束；很難確保服務 100% 隨時遵守、網路上惡意程式也很多也難保證服務不會被駭造成資料外洩；總之還是「 要做惡技術上都可行，單靠法規跟企業良心約束 」。

除此之外更多時候，我們是「被迫」接受隱私權條款的，無法針對個別隱私授權，要馬整個服務都不用，要馬就是用但要接受全部隱私權條款；還有隱私條款不透明，不知道會怎麼被收集及應用，更不知道背後有沒有還躲著一個第三方在你根本不知道情況下蒐集你的資料。

另外 Apple 還有提到關於未成年人的個人隱私，多半也都在監護人未同意的情況下被服務蒐集。

Apple’s privacy principles

知道個人隱私洩露帶來的危害之後，來看一下蘋果的隱私原則。

節錄自 Apple Privacy White Paper 蘋果的理想不是完全封殺而是平衡，例如這幾年很多人都會直接裝 AD Block 完全阻斷廣告，這也不是蘋果想看到的；因為如果完全斷開就很難做出更好的服務。

賈伯斯在 2010 年的 All Things Digital Conference 說過：

我相信人是聰明的，有些人會比其他人更想分享數據，每次都去問他們，讓他們煩到叫你不要再問他們了，讓他們精準的知道你要怎麼使用他們的資料。 — translate by Chun-Hsiu Liu

蘋果相信隱私是基本人權

蘋果的四個隱私原則：

• Data Minimization：只取用你需要的資料
• On-Device Processing：Apple 基於強大的處理器晶片，如非必要，個人隱私相關資料應在本地執行
• User Transparency and Control：讓使用者了解哪些隱私資訊被蒐集？被用在哪？另外也要讓使用者能針對個別隱私資料分享開關控制
• Security：確保資料儲存、傳遞的安全

iOS 基於保護個人隱私的歷年功能調整

了解到個人隱私洩露的危害及蘋果的隱私原則後，回到技術手段上；我們可以來看看 iOS 這些年來針對保護個人隱私的功能調整有哪些。

網站與網站之間

前面有提到

第一種方法可以用 Third-Party Cookie 跨網站串起瀏覽者資料：

🈲，在 iOS >= 11 後的 Safari 都實裝了 Intelligent Tracking Prevention ( WebKit )

預設啟用，瀏覽器會主動辨識用於追蹤、廣告的第三方 Cookie 加以阻擋；並且在每年的 iOS 版本不斷地加強辨識程式防止遺漏。

透過 Third-Party Cookie 跨網站追蹤使用者這條路，在 Safari 上基本上已經行不通了。

第二種方法是用 IP Address + 裝置資訊算出的 Fingerprint 在不同網站中識別出同個瀏覽者：

🈲，iOS >= 15 Private Relay

尤其在 Third-Party Cookie 被禁之後，有越來越多服務採用這個方法，蘋果也知道…所幸在 iOS 15 連 IP 資訊都給你混淆了！

Private Relay 服務會將使用者的原始請求先隨機送到蘋果的 Ingress Proxy，再由蘋果隨機分派到合作 CDN 的 Egress Proxy，再由 Egress Proxy 去請求目標網站。

整個流程都經過加密只有自己 iPhone 的晶片解的開，也只有自己同時知道 IP 與請求的目標網站；蘋果的 Ingress Proxy 只知道你的 IP、CDN 的 Egress Proxy 只知道蘋果的 Ingress Proxy IP 跟請求的目標網站、網站只知道 CDN 的 Egress Proxy IP。

從應用角度來看，同一個地區的所有裝置都會使用同個共享的 CDN 的 Egress Proxy IP 來請求目標網站；也因此網站端無法再用 IP 當成 Fingerprint 資訊。

技術細節可參考「 WWDC 2021 — Get ready for iCloud Private Relay 」。

補充 Private Relay：

• Apple/CDN Provider 都沒有完整 Log 可追朔： 查了下這樣蘋果怎麼防止被用在惡意的地方，沒找到答案；可能就跟蘋果也不會幫 FBI 解鎖罪犯 iPhone 一樣意思吧；隱私是所有人的基本人權。
• 預設開啟，不需特別連接
• 不影響速度、效能
• IP 會保證在同個國家和時區 （使用者可選模糊城市）、無法指定 IP
• 只對部分流量有效 iCloud+ 用戶：所有 Safari 上的流量 + App 中的 Insecure HTTP Request 一般用戶：僅對 Safari 上網站安裝的第三方追蹤工具有效
• 官方有提供 CDN Egress IP List 供網站開發者辨認 (不要誤 Blocking Egress IP，會造成群體傷害)
• 網路管理者可 Ban 掉 DNS 對所有連接者停用 Private Relay
• iPhone 可針對特定網路連線停用 Private Relay
• 連接 VPN/ 掛 Proxy 時會停用 Private Relay
• 目前還在 Beta 版 (2021/10/24)，啟用後部分服務可能會連不上 (中國地區、中國版抖音)或是服務會頻繁被登出

Private Relay 實測圖

• 圖一 未啟用：原始 IP 位址
• 圖二 啟用 Private Relay — 保持一般位置：IP變成 CDN IP 但依然在 Taipei
• 圖三 啟用 Private Relay — 使用國家和時區（擴大模糊）：IP變成 CDN IP & 變在 Taichung，但依然還是同個時區和國家

測試專案

App 可以用 URLSessionTaskMetrics 分析 Private Relay 的連接紀錄。

扯遠了，因此用 IP 位址得到 Fingerprint 去辨識使用者的方法，也無法再使用了。

App 與 App 之間

第一種方式是早期可以直接存取 Device UUID：

🈲，iOS >= 7 禁止存取 Device UUID,

使用 IDentifierForAdvertisers/IDentifierForVendor 取代

• IDFV： 同個開發者帳號下的所有 App 能拿到同一個 UUID； 搭配 KeyChain 也是目前使用者 UUID 的辨識方法 。
• IDFA： 不同開發者、不同 App 之間能拿到相同的 UUID，但是 IDFA 使用者可以重設或禁用。

🈲，iOS >= 14.5 IDentifierForAdvertisers 需詢問後才能使用

iOS 14.5 後蘋果加強對 IDFA 的取用限制，App 需要先詢問使用者允不允許追蹤後才能取得 IDFA UUID；未詢問、未允許的情況下都拿不到值。

市調公司初步調查數據大約有 7成的使用者(最新數據有人說 9 成)都不允許追蹤取用 IDFA，所以大家才會說 IDFA 已死！

測試專案

App 與 App 之間互通有無的第二種方法是 URL Scheme：

iOS App 可以使用 canOpenURL 去探測使用者手機上有沒有裝某個 App。

🈲，iOS >= 9 需先在 App 內設定才能使用；不能任意探測。

iOS ≥ 15 新增限制，最多只能設定 50 組其他 App 的 Scheme。

Apps linked on or after iOS 15 are limited to a maximum of 50 entries in the LSApplicationQueriesSchemes key.

網站 與 App 之間

同前文所述

第一種方法也是透過 Cookie 來串接：

早期 iOS Safari 的 Cookie 跟 App WebView 的 Cookie 是可以互通的，可以藉此串起 網站與 App 之間的資料。

做法可以在 App 畫面上偷塞一個 1 pixel 的 WebView 元件在背景偷偷讀取 Safari Cookie 回來用。

🈲，iOS >= 11 禁止 Safari 和 App WebView 間共用 Cookie

如果有需要取得 Safari 的 Cookie (EX: 直接使用網站 Cookie 登入)，可以使用 SFSafariViewController 元件取得；但此元件強迫跳提示視窗且無法客製化，確保使用者不會在無意間被偷取 Cookie。

第二種方法是同網站與網站用IP Address + 裝置資訊算出的 Fingerprint 在不同網站中識別出同個瀏覽者：

同前述， iOS ≥ 15 已被 Private Relay 混淆。

最後一種也是唯一還能的方法 — Pasteboard ：

使用剪貼簿串接跨平台的資訊，因為蘋果不可能禁用剪貼簿跨 App 使用，但是它可以提示使用者。

⚠️ iOS >= 14 新增剪貼簿存取警告

⚠️ 2022/07/22 Update: iOS 16 Upcoming Changes

iOS ≥ 16 開始非使用者主動操作貼上動作，App 主動讀取剪貼簿的行為會跳出詢問視窗，使用者需要按允許，App 才能讀取到剪貼簿資訊。

UIPasteBoard’s privacy change in iOS 16

使用 Pasteboard 實現 Deferred Deep Link 延遲深度連結實作

這邊要多提一下關於 iOS 14 剪貼簿的隱私恐慌，詳細可參考我之前的文章「 iOS 14 剪貼簿竊資恐慌，隱私與便利的兩難 」

雖然不能排除讀取剪貼簿是想竊資，但更多時候是我們 App 需要提供更好的使用體驗：

在沒有實現 Deferred Deep Link 延遲深度連結之前，當我們引導使用者從網站上去安裝 App，安裝完成後打開 App 默認只會打開首頁；更好的使用體驗應該是打開 App 回復到網頁上停留的頁面的 App 對應頁。

要實現這個功能就需要 網站與 App 之間有機會串起資料，如文章前述的其他方法都已被封禁，目前僅能透過剪貼簿做為資訊儲存媒介（如上圖）。

包含 Firebase Dynamic Links、Branch.io 最新版(之前 Branch.io 用 IP Adrees Fingerprint 來實現)也都使用剪貼簿做 Deferred Deep Link。

實作可參考我之前的文章： iOS Deferred Deep Link 延遲深度連結實作(Swift)

一般情況下如果是為了要做到 Deferred Deep Link 僅會在第一次打開 App、重新返回 App 那一刻去讀取剪貼簿資訊；不會在使用中或奇怪的時間點讀取，這一點值得注意。

更好的做法是先用 UIPasteboard.general.detectPatterns 探測剪貼簿的資料是不是我們需要的，是在讀取。

測試專案

iOS ≥ 15 之後優化了剪貼簿提示，如果是使用者自己的貼上動作，就不會再跳提示了！

廣告成效解決方案

同前文所說的蘋果隱私原則，希望的是平衡而不是完全阻斷使用者與服務。

網站與網站的廣告成效統計：

Safari 上相對於阻擋 Intelligent Tracking Prevention 的功能就是 Private Click Measurement ( WebKit ) 用於在去除個人隱私的情況下統計廣告成效。

具體流程如上圖，使用者在 A 網站點擊廣告前往 B 網站時，會在瀏覽器上紀錄一個 Source ID (識別同個使用者用) 與 Destination 資訊 (目標網站)；當使用者在 B 網站上完成轉換也會紀錄一個 Trigger ID (代表什麼動作) 在瀏覽器上。

這兩個資訊會合併起來在隨機 24 ~ 48 小時後傳送到 A 和 B 網站得到廣告成效。

一切都是 on-device safari 自行處理、防範惡意點擊也是由 Safari 提供保護。

App 與 網站或 App 之間的廣告成效統計：

可以使用 SKAdNetwork (需向蘋果申請加入) 類似 Private Click Measurement 方式，不再展開贅述。

可以多提一下，蘋果並非閉門造車； SKAdNetwork 目前來到 2.0 版本，蘋果持續收集開發者廣告商的需求綜合個人隱私控管，持續優化 SDK 功能。

這邊真心許願 Deferred Deep Link 能用 SDK 串起，因為我們是為了提升使用者體驗，沒有要侵犯個人隱私的意思。

技術細節可參考「 WWDC 2021 — Meet privacy-preserving ad attribution 」。

Cross-Platform

iOS ≥ 13 所有支援第三方登入的 App 都需要多實作 Sign in with Apple，否則無法成功上架 App

• 姓名可自行編輯
• 可隱藏真實 Email (使用蘋果產的虛擬 Email 代替)
• 使用者可要求刪除帳號 2022/01/31 前 App 須完成實作 🆕

iOS >= 15 iCloud+ 用戶支援 Hide My Email

• 支援 Safari、App 所有信箱欄位
• 使用者可到設定中任意產生虛擬信箱

同 Sign in with Apple 使用蘋果產的虛擬 Email 代替真實信箱，在收到信後蘋果會轉發到你的真實信箱中，藉此保護你的信箱資訊。

類似 10 分鐘信箱，但又更強大；只要不停用，那組虛擬信箱地址就是你永久持有；也沒有新增上限，可以無限新增，不確定蘋果如何防止濫用。

設定 -> Apple ID -> 隱藏我的電子郵件

Others

App privacy details on the App Store：

App 必需在 App Store 上說明使用者哪些資料會被追蹤及如何應用 。

詳細說明可參考：「 App privacy details on the App Store 」。

個人隱私資料細微控制：

iOS ≥ 14 開始，位置及相片存取可以更細微的控制，可以只授權取用某幾張相片、只允許 App 使用中存取位置。

測試專案

iOS ≥ 15，增加 CLLocationButton 按鈕提升使用者體驗，可以在未詢問/未同意情況下透過使用者點擊取得當前位置，此按鈕無法客製化、只能透過使用者操作觸發。

個人隱私取用提示：

iOS ≥ 15，增加個人隱私功能的取用提示，如：剪貼簿、位置、相機、麥克風

App 隱私取用報告：

iOS ≥ 15，可以匯出近 7 天手機所有 App 的隱私相關功能取用、網路活動的紀錄報告。

1. 因紀錄報告檔案是 .ndjson 純文字檔，直接查看不易；可以先在 App Store 下載「 隱私洞見 」App 用來查看報告
2. 到設定 -> 隱私權 -> 最下方「紀錄 App 活動」-> 啟用紀錄 App 活動
3. 儲存 App 活動
4. 選擇「匯入到 隱私洞見 」
5. 匯入完成後即可檢視隱私報告

可以看到同 新聞 所說，Wechat 的確會再啟動 App 時在背景偷偷讀取相片資訊。

另外我也多抓到幾個中國 App 也會偷做事，直接在設定全部禁用它們的權限了。

要不是有這個功能讓他們見光死，還不知道我們的資料會被竊取多久！

Recap

Apple’s privacy principles

了解完歷年對於隱私功能的調整後，我們回頭來看蘋果的隱私原則：

• Data Minimization：蘋果用技術手段限制取用需要的資料
• On-Device Processing：隱私資料不上傳雲端，一切都在本地處理；如 Safari Private Click Measurement、蘋果的 機器學習 SDK CoreML 也都是在本地執行、iOS ≥ 15 的 Siri/相機原況文字功能、Apple Map、News、相片識別功能…等等
• User Transparency and Control：新增的各種隱私存取提示、紀錄報告及隱私細微控制功能
• Security：資料儲存傳遞的安全，不濫用 UserDefault、iOS 15 可以直接用 CryptoKit 來做點對點加解密、Private Realy 的傳輸安全

破碎資料

回到最一開始用技術手段拼湊出哈里的關聯圖，網站與網站或 App 之間被堵死，只剩剪貼還能用，但會有提示。

服務註冊跟第三方登入的個資，可以改用 Sign in with apple 和 hide my email 功能防堵；或是多使用 iOS 原生 App。

線下活動或許可以改 Apple Card 防止隱私外洩？

已沒有人有機會拼湊出哈里的活動輪廓。

Apple 以人為本

因此「以人為本」是我會給蘋果的理念的代名詞，要與商業市場唱反調需要很大的信念；與它相關的「以科技為本」是我會給 Google 的代名詞，因為 Google 總能造出很多 Geek 科技項目；最後「以商業為本」是我會給 Facebook 的代名詞，因為 FB 在很多層面上都只追求商業收益。

除了針對隱私功能的調整，這幾年的 iOS 也不斷加強防止手機沈迷的功能，推出了「螢幕使用時間報告」、「App 使用時間限制」、「專注模式」…等等功能；幫助大家解除手機成癮。

最後希望大家都能

• 重視個人隱私
• 不被資本控制
• 減少虛擬成癮
• 防止社會沈淪

在現實世界活出精彩人生！

Private Relay/IDFA/Pasteboard/Location 測試專案：

參考資料

• WWDC 2021 — Apple’s privacy pillars in focus
• Apple privacy white paper — A Day in the Life of Your Data
• WWDC 2021 — Get ready for iCloud Private Relay
• WWDC 2021 — Meet privacy-preserving ad attribution
• iOS 14 剪貼簿竊資恐慌，隱私與便利的兩難
• iOS Deferred Deep Link 延遲深度連結實作(Swift)
• iOS UUID 的那些事 (Swift/iOS ≥ 6)

有任何問題及指教歡迎 與我聯絡 。

---

本文首次發表於 Medium ➡️ 前往查看

由 ZMediumToMarkdown 與 Medium-to-jekyll-starter 提供自動轉換與同步技術。

Improve this page on Github.

Follow Me on Medium 1K+ Followers

3,577 Total Views
Last Statistics Date: 2025-05-19 | 3,054 Views on Medium.