Path 以及 iOS 在保護資料安全上作錯了什麼?

Path 是目前在 iOS 和 Android 上火熱的社群網路,提供類似 Facebook 時間軸的體驗,但對於手機平台做了許多優化、頗受使用者的喜歡。
評論
評論

Path 是目前在 iOS 和 Android 上火熱的社群網路,提供類似 Facebook 時間軸的體驗,但對於手機平台做了許多優化、頗受使用者的喜歡。

我早在一年多 Path 剛推出時就曾經試用過一陣子,當時的感覺是相當的平淡無奇,而幾個月前的 Path 2.0 的改版卻是讓人讚嘆、許多的朋友都紛紛的加入了 Path,讓我們必須要相信:

好的 UI 設計可以改變一個產品對大眾的觀感以及評價。

可惜他們犯了個錯誤

上個禮拜中最大的新聞之一,便是 Path 被第三方的開發者發現他們會在背景中偷偷地上傳使用者的電話簿內容到他們的伺服器上。包含使用者本身、他的朋友以及任何在通訊錄中的電子郵件和電話等都會被上傳。

而且最重要的是,這件事情事先沒有讓使用者得知, 完全都是程式在背景中暗自進行的。這當然是很嚴重的隱私問題,先前 Facebook 便也曾經有類似的問題被媒體炮轟。

Path 官方雖然澄清說他們只是將好友資料用來作「好友推薦」使用,並且馬上推出新版、會在上傳資料前取得使用者的同意。更進一步,在輿論的壓力之下他們也公開表示會將目前伺服器上使用者上傳的內容都刪除掉。

至今,可以看得出來 Path 努力的在避免災情持續擴 大、做出了相當有誠意的讓步。

但這對於一個正在成長的創業家而言,仍舊是一個難以抹滅的傷害,也使得他們在 Wikipedia 的頁面中留下了一筆紀錄:

In February 2012, the company was widely criticized for concerns of accessing and storing member phone contacts without their knowledge or permission. In a blog post by the CEO the company apologized and said that it changed its practices.

iOS 本身的設計缺陷

在 iOS 系統提供的 framework 中有一個 AddressBook.framework(一般簡稱為 AB)可以用來存取系統的聯絡人資料,而這個框架早在 iOS 2.0 版本時就有提供了。換句話說,這問題從 App Store 開放的第一天便已經存在。

這種同樣性質的存取還包含了使用者的音樂資料庫,一樣不需要使用者提示便可以存取。但也別太擔心,包含簡訊、電子郵件等,甚至是裝過的 App 目前都沒有辦法透過公開的程式介面存取。

早從 Path 2.0 剛推出時有朋友反應,覺得為什麼 Path 的推薦好友功能如此精準時我就曾經猜測應該是有在背後存取聯絡人的資料。

但這個問題難道 iOS 不用負責嗎?目前在 iOS 中存取使用者的地理位置和要接收由程式提供的推播通知都需要使用者的主動同意,通訊錄這種高度隱私的內容就不需要使用者的同意?

我相信這絕對是 Apple 當初在設計 iOS 時所犯下的一大錯誤。

正確的作法

這件事情的確給許多 App 開發者們上了一課,我相信一定有其他的程式在背地裡用著類似的手法,但經過這次的警惕應該都會有所收斂。

這件事情讓我重新思考,正確的作法應該是什麼?怎樣才能夠讓開發者存取到使用者的通訊錄、卻又不會造成使用者有隱私被侵犯的疑慮。

iOS

從平台提供者的角度來看,從系統上直接限制開發者的存取是最有效的作法。

目前在 iOS 上的設定中都可以找到針對個別軟體的定位服務和推播通知的存取設定,以定位服務而言,你甚至可以看到在近一天之內哪些軟體曾經存取過你的定位服務。

我認為 iOS 對於聯絡人的存取應該採取更嚴格的方式,不只是要在第一次存取時獲得使用者的授權,而是要在每次存取時都需要經過使用者同意,當軟體關閉之後下次要重新存取便需要使用者的再度同意才行。

當然這樣的修改一定會改變 API 介面、使得現在的軟體沒辦法相容,因此這樣的改版必定會先經過 Beta 測試版的釋出,甚至是要到下一個主要改版 iOS 6 中才會實現。

App Store

App Store 在開發者之間最著名的(或許說是惡名昭彰比較適當)的就是嚴格的審核機制了。

針對這次的事件,實際上在 App Store Review Guidelines 便已經有相關的規範:

Apps cannot transmit data about a user without obtaining the user’s prior permission and providing the user with access to information about how and where the data will be used.

這次可以說是 App Store 執法上的失誤,我相信 Apple 審核團隊內部在接下來的幾個月當中對於類似的存取一定會更加謹慎(或許也代表審核要更久了…)。

應用程式開發者

回歸到原點,應用程式開發者應該要怎麼作呢?從兩個面向來看,分為在存取資料之前、以及如何運用這些資料。

在存取資料之前,開發者需要善盡告知的義務,明確徵求使用者同意存取通訊錄,並且讓使用者知道資料的使用方式、是否會上傳到伺服器等等。

Instapaper 的作者 Marco 提出了如下圖這樣的作法:

至於在存取之後,我們真的有必要將完整的資料全部上傳到伺服器上?

若是以「好友推薦」這像功能而言,實際上可以只上傳使用者聯絡人清單中電子郵件地址的 Hash 即可,透過上傳電子郵件地址的 Hash、一樣可以做到推薦好友的功能。

且在資料傳送到伺服器後,若沒有必要的話則應該要當場刪除、留在資料庫的話即便不做額外的處理,也要擔心是否會被駭客入侵利用。

結論

我相信這絕對是誠信的問題。當初 iOS 平台給了大家方便,讓開發者能夠直接存取通訊錄,卻沒有仔細在 App Store 審核中做好守門人的機制,才造成至今這麼大的風波,對於 Apple 或是開發者而言都是很大的損失。

身為同樣在 App Store 上努力的開發者,我相信 App Store 或是其他的任何平台都是一個 System,維護一個受使用者信賴、進而讓開發者獲得更多收入的平台是每個人的責任。