來源:量子位
人在聊微信,相冊被 " 偷窺 "。
而且還是反復(fù)讀取,每次長達 1 分鐘的那種。

△圖源:微博
這兩天,一位數(shù)碼博主在網(wǎng)上曝出的這件 " 隱私問題 " 成為了焦點。
畢竟很多人每天都離不開微信,可以是說與大多數(shù)人利益相關(guān)了。
而時隔數(shù)小時,微信官方對此作出了回應(yīng):
iOS 系統(tǒng)為 App 開發(fā)者提供相冊更新通知標(biāo)準(zhǔn)能力,相冊發(fā)生內(nèi)容更新時會通知到 App,提醒 App 可以提前做準(zhǔn)備。
App 的該準(zhǔn)備行為會被記錄成讀取系統(tǒng)相冊。
并且微信還補充解釋道,這樣的操作是為了方便用戶在微信聊天中按 "+" 時可以快速發(fā)圖。
但經(jīng)此事發(fā)酵之后,微信表示會在最新版本中取消這樣的操作,優(yōu)化快速發(fā)圖功能。
相冊是如何被 " 偷窺 " 的?
事情的經(jīng)過是這樣的。
這位數(shù)碼博主的一位群友,在群里分享了他的經(jīng)歷:
開啟了 iOS 15 的隱私新特性 " 記錄 App 活動 ",對所有 App 的隱私讀取行為進行 7 天的監(jiān)控。
并使用 App Privacy Insights 對記錄進行讀取。

△圖源:微博
真的是 " 不看不知道,一看嚇一跳了 "。
在如此一通監(jiān)測下,這位群友發(fā)現(xiàn)微信一直在" 偷窺 " 手機相冊:
在用戶未主動激活 App 的情況下,在后臺數(shù)次讀取用戶相冊。
每次讀取時間長達 40 秒 至 1 分鐘不等。
而在后續(xù)的發(fā)現(xiàn)中,有如此行徑的還不止微信這一家。
就連 QQ、淘寶等多款國產(chǎn) App 均存在后臺頻繁讀取用戶相冊的行為。

△圖源:微博
而后博主總結(jié)了這些 App 的運行狀態(tài)和權(quán)限設(shè)置:
用戶前臺未主動運行
iOS 默認開啟后臺應(yīng)用數(shù)據(jù)刷新,未手動改變過狀態(tài)
上次使用微信后,直接上劃返回主屏幕,沒有徹底殺死后臺
如此情況之下,博主對這些 App 進行了強烈的抨擊,主要表達了 2 點:
照片是用戶隱私,每次調(diào)取用戶隱私時用戶并不知情(從讀取時間來看,用戶在睡覺的時候它也在讀)。如果僅僅是為了掃描是否添加了新圖片,也沒有必要如此過度請求。
占用系統(tǒng)內(nèi)存、嚴(yán)重消耗電池續(xù)航。手機的 RAM/ 電量續(xù)航都浪費在這種毫無意義的操作上了,嚴(yán)重降低用戶體驗。
如此話題瞬間在網(wǎng)絡(luò)上引起了關(guān)注。
一位知乎網(wǎng)友(以下經(jīng)授權(quán))便特意查看了下蘋果開發(fā)者文檔。

他認為監(jiān)聽相冊變動應(yīng)該用的是 PHPhotoLibraryChangeObserver 協(xié)議。
這個監(jiān)聽器觸發(fā)的邏輯是相冊發(fā)生變動,并且無視變動來源。
那么可能的一種解釋就是,用戶確實在非微信環(huán)境修改了照片,可以是在相冊里直接操作,也可能是別的 APP 修改導(dǎo)致的。
樣例代碼如下:
func photoLibraryDidChange ( _ changeInstance: PHChange ) {
guard let collectionView = self.collectionView else { return }
// Change notifications may be made on a background queue.
// Re-dispatch to the main queue to update the UI.
DispatchQueue.main.sync {
// Check for changes to the displayed album itself
// ( its existence and metadata, not its member assets ) .
if let albumChanges = changeInstance.changeDetails ( for: assetCollection )
// Fetch the new album and update the UI accordingly.
assetCollection = albumChanges.objectAfterChanges! as! PHAssetCollec
navigationController?.navigationItem.title = assetCollection.localiz
}
// Check for changes to the list of assets ( insertions, deletions, moves
if let changes = changeInstance.changeDetails ( for: fetchResult ) {
// Keep the new fetch result for future use.
fetchResult = changes.fetchResultAfterChanges
if changes.hasIncrementalChanges {
// If there are incremental diffs, animate them in the collectio
collectionView.performBatchUpdates ( {
// For indexes to make sense, updates must be in this order:
// delete, insert, reload, move
if let removed = changes.removedIndexes where removed.count
collectionView.deleteItems ( at: removed.map { IndexPath ( i
}
if let inserted = changes.insertedIndexes where inserted.cou
collectionView.insertItems ( at: inserted.map { IndexPath (
}
if let changed = changes.changedIndexes where changed.count
collectionView.reloadItems ( at: changed.map { IndexPath ( i
}
changes.enumerateMoves { fromIndex, toIndex in
collectionView.moveItem ( at: IndexPath ( item: fromIndex, s
to: IndexPath ( item: toIndex, sec
}
} )
} else {
// Reload the collection view if incremental diffs are not avail
collectionView.reloadData ( )
}
}
}
}
可見,在 hasIncrementalChanges 為 true 的情況下,相片的增刪改都會 dispatch。
但是在 hasIncrementalChanges 為 false 的情況下,開發(fā)者也可以自行選擇處理邏輯。
至于啥情況下會導(dǎo)致 hasIncrementalChanges 為 false,開發(fā)者文檔也給出了解釋:
If this value is false, the fetch result is too different from its original state for incremental change information to be meaningful.
也就是相冊改變太過巨大導(dǎo)致。
如何解決?
雖說微信官方表示,在新版本中將取消這樣的功能。
但在此之前,又該如何破解呢?
博主以微信為例,很貼心的給出了如下的tips:
進入 設(shè)置 > 下拉找到「微信」 > 相冊 > 將「所有照片」改為「選中的照片」或「不允許」
在同設(shè)置頁面, 關(guān)閉「后臺 App 自動刷新」開關(guān)
在同設(shè)置頁面,檢查其他權(quán)限,例如:如果不通過電腦備份聊天記錄,應(yīng)關(guān)閉本地聯(lián)網(wǎng)權(quán)限;如果不經(jīng)常分享定位,應(yīng)關(guān)閉定位權(quán)限;如果不在微信上使用小程序解鎖共享單車,應(yīng)關(guān)閉藍牙權(quán)限。
對于其他國產(chǎn) App 也建議進行同樣操作。保證你的 App 擁有最小權(quán)限。能不給精確定位就不給。后臺 App 自動刷新的功能如果沒有特殊需求建議關(guān)閉,這項功能不影響 App 推送。
……
最后,雖然此次事件波及的是 iOS 用戶,作為安卓用戶的你,是否也有類似的經(jīng)歷呢?






