Post

iOS 14 剪貼簿竊資恐慌,隱私與便利的兩難

為何那麼多 iOS APP 會讀取你的剪貼簿?

iOS 14 剪貼簿竊資恐慌,隱私與便利的兩難

ℹ️ℹ️ℹ️ Click here to view the English version of this article, translated by OpenAI.


iOS 14 剪貼簿竊資恐慌,隱私與便利的兩難

為何那麼多 iOS APP 會讀取你的剪貼簿?

Photo by [Clint Patterson](https://unsplash.com/@cbpsc1?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText){:target="_blank"}

Photo by Clint Patterson

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

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

[UIPasteBoard’s privacy change in iOS 16](https://sarunw.com/posts/uipasteboard-privacy-change-ios16/){:target="_blank"}

UIPasteBoard’s privacy change in iOS 16

議題

剪貼簿被 APP 讀取時的頂部提示訊息

剪貼簿被 APP 讀取時的頂部提示訊息

iOS 14 開始會提示使用者 APP 讀取了您的剪貼簿,尤其中國大陸的 APP 本來就惡名昭彰,再加上媒體不斷的放大報導,造成不小的隱私恐慌;但其實不只中國 APP, 美國 、台灣、日本…世界各地很多大大小小的 APP 全都現形,那到底是為了什麼那麼多 APP 都需要讀取剪貼簿呢?

Google Search

Google Search

安全

剪貼簿可能包含個人隱私甚至密碼,如使用 1Password、LastPass…等密碼管理器複製密碼;APP 有能力讀取到就有能力回傳回伺服器記錄,一切看開發者的良心,真要查的話可透過使用 中間人嗅探 ,監聽 APP 回傳回伺服器的資料,是否包含剪貼簿資訊。

淵源

剪貼簿 API ,從 iOS 3 2009 年開始就有,只是從 iOS 14 開始會多跳提示告知使用者而已,中間已過十餘年,如果是惡意的 APP 也收集夠足夠的資料了。

為何

為何那麼多 APP 不論國內外都會在 打開時 讀取剪貼簿呢?

這邊要先定義一下,我說的情況是 「APP 打開時」 ,而不是 APP 使用中讀取剪貼簿;APP 使用中讀取的情況比較偏是 APP 內的功能應用,像是 Goolge Map 自動貼上剛複製的地址、但也不排除有的 APP 會不斷偷取剪貼簿資訊。

「一把菜刀可以切菜也可以殺人,取決於用的人拿來做什麼」

APP 打開時會讀取剪貼簿主要原因是要做「 iOS Deferred Deep Link加強使用者體驗 ,如上流程所示;當一個產品同時提供網頁及APP時,我們更希望使用者能安裝 APP(因黏著度更高),所以當使用者瀏覽網頁版網站時會導引下載 APP,但我們希望下載完開啟 APP 會自動打開網頁離開時的頁面。

EX: 當我在 safari 逛 PxHome 手機網頁版 -> 看到喜歡的產品想要購買 -> PxHome 希望流量導 APP -> 下載 APP -> 打開 APP -> 展現剛網頁看到的商品

如果不這樣做,使用者只能 1. 回到網頁上再點一次 2. 在 APP 內重新搜尋一次產品;不管 1 還是 2 都會增加使用者購買上的困難及猶豫時間,可能就不買了!

另一方面以營運來說,知道從哪個來源成功安裝的統計,對行銷、廣告預算投放都有很大的幫助。

為何一定要用剪貼簿,有無其他替代方式?

這是場 貓鼠遊戲 ,因為 iOS 蘋果本身不希望開發者有辦法反向追蹤使用者來源,iOS 9 之前的做法是將資訊存入網頁 Cookie,APP 安裝完後再讀取 Cookie 出來用,iOS 10 之後這條路被蘋果封住無法使用;退無可退大家才使用最終技 — 「用剪貼簿傳資訊」來達成,iOS 14 再次遞出新招,提示使用者讓開發者尷尬。

另一條路是使用 Branch.io 的方式,記錄使用者輪廓(IP、手機資訊),然後用搓合的方式讀取資訊,原理上可行,但需要投入大量人力(牽涉到後端、資料庫、APP)去研究實作,且可能會誤判或碰撞。

*對面的 Android Google 原本就支援此功能,不用像 iOS 這樣繞來繞去。

受影響的 APP

可能很多 APP 開發者都不知道自己也出現剪貼簿隱私問題,因為 Google 的 Firebase Dynamic Links 服務也是使用同樣的原理實現:

1
2
3
4
5
// Reason for this string to ensure that only FDL links, copied to clipboard by AppPreview Page
// JavaScript code, are recognized and used in copy-unique-match process. If user copied FDL to
// clipboard by himself, that link must not be used in copy-unique-match process.
// This constant must be kept in sync with constant in the server version at
// durabledeeplink/click/ios/click_page.js

所以任何有使用到 Google Firebase Dynamic Links 服務的 APP 都可能中槍剪貼簿隱私問題!

個人觀點

資安問題是有的,但就是「 信任」 ,信任開發者是拿來做正確的事;如果開發者要做惡,有更多的地方可以做惡,例如:偷取信用卡資訊、偷記錄真實密碼…等等,都要比這個有效的多。

提示的用途就是讓使用者能注意到剪貼簿讀取的時間點,如果不合理就要小心!

讀者提問

Q:「TikTok 回應存取剪貼簿是為了偵測濫發垃圾訊息的行為」這種說法是正確的嗎?

A:我個人認為只是找個理由搪塞輿論,抖音的意思應該是「為了防止使用者四處複製貼上廣告訊息」;但實際可以在訊息輸入完成時或是送出訊息時再做阻擋過濾,沒必要時時監聽使用者剪貼簿的資訊!難道剪貼簿有廣告或「敏感」訊息也要管?我又沒貼上發表出去。

開發者能做的事

若手邊沒有備用機可升級 iOS 14 測試,可先從 Apple 下載 XCode 12 用模擬器測看看。

一切都還太新,如果你是串 Firebase 可以先參考 Firebase-iOS-SDK/Issue #5893 更新到最新的 SDK。

如果是自己實作 DeepLink 可以參考 Firebase-iOS-SDK #PR 5905 的修改:

Swift:

1
2
3
4
5
6
7
if #available(iOS 10.0, *) {
  if (UIPasteboard.general.hasURLs) {
      //UIPasteboard.general.string
  }
} else {
  //UIPasteboard.general.string
}

Objective-C:

1
2
3
4
5
6
7
8
9
if (@available(iOS 10.0, *)) {
    if ([[UIPasteboard generalPasteboard] hasURLs]) {
      //[UIPasteboard generalPasteboard].string;
    }
  } else {
    //[UIPasteboard generalPasteboard].string;
  }
  return pasteboardContents;
}

先檢查剪貼簿內容是否為網址(配合網頁 JavaScript 複製的內容是網址帶參數)是才讀取,就不會每次開啟 APP 都跳剪貼簿被讀取。

目前只能如此,提示跳還是會跳,就只是讓他更聚焦一點

另外蘋果也增加了新的 API: DetectPattern ,幫助開發者能更精確判斷剪貼簿資訊是我們要的,然後再讀取,再跳提示,使用者能更安心、開發者也能繼續使用此功能。

DetectPattern 也還在 Beta、且僅能使用 Objective-C 實作。

或是…

  • 改用 Branch.io
  • 自行實作 Branch.io 的原理
  • APP 先跳客製化 Alert 告知使用者,再讀取剪貼簿(讓使用者安心)
  • 加入新隱私權條款
  • iOS 14 最新的 App Clips?,網頁 -> 導 App Clips 輕量使用 -> 深入操作導 APP

延伸閱讀

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


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

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

Improve this page on Github.

Buy me a beer

15,345 Total Views
Last Statistics Date: 2025-03-25 | 15,275 Views on Medium.
This post is licensed under CC BY 4.0 by the author.