iOS App是如何獲取你的個人數據的？

2012-02-17 09:49:32來源：36kr作者：

上周前夕，私密社交網絡Path因其私自上傳用戶資料成為人們爭論的焦點，隨后其創始人Dave Morin進行了公開道歉。但是你可能不知道，在Path這次被曝光之前，很多App侵犯用戶隱私的行為有過之而無不及，下面就讓我們來

上周前夕，私密社交網絡Path因其私自上傳用戶資料成為人們爭論的焦點，隨后其創始人Dave Morin進行了公開道歉。但是你可能不知道，在Path這次被曝光之前，很多App侵犯用戶隱私的行為有過之而無不及，下面就讓我們來揭開這里面的故事。

事實上，Tapbots的Paul Haddad經過獨立測試結果顯示，很多App上傳用戶數據的行為比Path更嚴重，而且它們做這個動作時沒有一點提示或者經過你的允許。當然，Path這個故事的出現讓它們立即升級了其App版本。

在測試過程中，Haddad發現Foursquare會上傳你所有的Email地址和手機號碼，沒有任何的警告信息或者明確的允許申請。這非常類似于Path及Intagram之前的做法，通過下面這個列表清單，你會發現私自上傳用戶的信息實在是平凡不過了。

沒有任何警告信息而發送數據的App

Foursquare是目前發現的惟一一個在沒有任何警告信息的前提下傳送用戶數據的App，直到2月14日發布更新版本后。這和之前Path的行為如出一轍。但是在這次更新之后，Foursquare現在上傳信息之前會有個警告信息。

Foursquare（郵件地址、電話號碼—沒有任何警告信息）

信息警告之后發送數據的App

這個列表的App會發送大量豐富的數據，其中包括Email地址、姓名、以及電話號碼。在所有的測試App中，Path貌似是發送數據最多的App。

Path（幾乎所有信息—有警告信息）
Instagram（郵件地址、電話號碼、姓名—有警告信息）
Facebook（郵件地址、電話號碼、姓名—有警告信息）
iOS版Twitter（郵件地址、電話號碼—有警告信息）
Voxer（郵件地址、姓名、電話號碼—有警告信息）

那些貌似沒有發送私人信息的App

這個列表的App貌似沒有發送用戶私人數據信息，盡管它們都鏈接到iOS平臺里的通訊錄。這意味著它們理論上可以抓取數據但是只能在本地使用這些數據，而這也是最正常最自然的使用通訊錄的方式。當然也存在一種可能，那就是某些與這些App進行的交互會訪問這些數據并將其發送到服務器，但是在這次測試中沒有發現任何類似證據。

Google+（無明顯跡象—鏈接到通訊錄）
Find My Friends（無明顯跡象—鏈接到通訊錄）
Skype（不好說—鏈接到通訊錄）
Yahoo Messenger（無明顯跡象—鏈接到通訊錄）
Quora（無明顯跡象—鏈接到通訊錄）
Textfree（無明顯跡象—鏈接到通訊錄）
AIM（無明顯跡象—鏈接到通訊錄）

很顯然，有了Path被媒體曝光指責這一經歷后，曾經那些未經用戶允許便上傳用戶數據的App都變得乖巧聽話，不敢惹惱用戶。這也許是一個很好的事件，但是我們仍然有許多問題值得追問。

為什么需要這些數據？

一個非常重要的理由：所有讓你與你的朋友們連接起來的應用都不得不訪問你的通訊錄，這沒有問題。但是有一個非常簡單的方法可以讓你的這些數據不會被上傳并保存到服務器上，這需要開發者們通過將這些數據匿名化、保存為一個校驗碼進而把那些純文本數據拋棄。這是一種比HTTPS更加保密的傳輸方式，如果你想對該種方式了解更多，可以訪問Matt Gemmell的這個簡單實用指南。

因此這里的關鍵點并非開發人員必需上傳這些明文數據，通過一定的技術手段是可以實現其需求的。答案也并非這些開發人員是否邪惡或者想通過你的數據獲得什么收益。相反，很多時候可能是因為他們并不了解存在這種更好的方法。開發人員和我們一樣，也有保護自己私人信息的需求，但是很多團隊資源不足因而導致對該問題未予以重視。

Haddad告訴我們：“我想出現這種情況基于兩個原因，首先，開發人員目前使用的方法是最為簡單的；其次，對相關領域的知識比較欠缺。”

我們就該問題采訪了Impending的Phill Ryu，他同樣持這樣的觀點。他說：“可能某些時候大家有一種以后使用的意圖，但是坦率的說，我覺得大家都有一種僥幸心理，認為這樣的災難不會發生在自己身上，并且目前的方式可以更好的為我們的產品修復漏洞或者添加新的功能。”然而，我們能這樣饒恕開發人員處理人們個人信息的方式嗎？這又引出另一個問題，為何之前這些App收集個人數據這樣的行為沒有被公開。這種公開的缺乏有兩個原因，其一是開發者們天真的認為這種處理個人數據的方法是可信的，其二他們認為用戶也是這樣認為的。

對于一個開發者來說，任何可以讓其應用工作出色的數據都應該得到好好利用。他們內心不會有惡意去使用這些數據的想法，但是沒有想到用戶對這個問題是如此的敏感。這就是為什么做出這樣的決定（傳送用戶個人數據）我們卻沒有想到將其公開或者給用戶一個提示信息。從用戶的角度來看，這顯然是濫用其信譽的一個巨大失誤。但是作為開發者，他們往往不會想到這點。這就給我們帶來另一個真正的疑問，確保用戶個人數據得到保護這個工作到底是誰的工作？是那些個人開發者還是蘋果公司？

促使應用開發者公開數據是蘋果的工作職責嗎？

隱藏于該問題的一個事實是在通訊錄這個架構的建立過程中，沒有任何第三方對開發者的這種數據傳送方式提出過要求。他們的責任僅僅是告訴大家：“我們準備抓取你的數據來實現這樣的功能”。

坦誠一點說，這樣的動作需要雙方共同確認。作為為其App Store制定政策的蘋果公司，應該明確在其條款里說明，所有的App該如何處理用戶的個人信息，并且在未經用戶允許的前提下絕對不能進行這種操作。然而遺憾的是，我們并沒有看到這樣的條款明細。因此，蘋果需要改變其目前的政策，即使會對開發者提出更加嚴厲的要求。但是對于App開發者來說，也需要注意到自己所承擔的責任。

Haddad告訴我們：“我覺得蘋果必需更改其API，所有對用戶數據的使用都必需得到用戶允許，這是蘋果公司的責任。而明確公開那些被上傳的數據信息，則是開發者必需履行的責任”。

然而要解決這個問題并沒有我們想象的那么簡單。開發者Justin Williams在下面將提到，僅僅增加一個提示框遠不能解決問題：
另外增加一個用戶確認框并不能解決目前用戶面臨的問題。這僅僅是表面的，其核心部分乃是iOS平臺如何處理數據請求這個更加基礎性的問題。從根本上說，在下載并第一次運行某個App之前，我對該App需要如何處理數據請求一無所知。而且，當我使用某個App時，我并不希望在界面看到另一個對話框。
他建議蘋果的App Store在處理某些數據請求時更加透明，允許用戶知道什么樣的信息將會被該應用使用到。這有點類似于Google的Andriod Market和微軟的Windows Marketplace這兩個平臺的工作機制。

答案并不簡單

這里不會有什么“魔法按鈕”出現。確實，蘋果也許將不得不在其系統層面對通訊錄數據請求做出某些改變（就在今天，蘋果已經更改其政策：未來App要讀取聯系人信息將需要明確獲得用戶授權），但是這有一個危險，它可能會導致“負載過度”，導致用戶的抱怨并將我們置于類似目前的焦點中。應用開發者們需要更加的注意隱私問題，并且在處理用戶信息時更加敏感些。因此，在用戶如何看待其個人信息價值與開發者如何處理信息這兩者之間需要一個平衡，需要一座溝通的橋梁。

下面就讓我們看看Haddad的一些測試結果。以下所有這些測試都是經由HTTPS傳輸，相對來說是非常安全的，但是在服務器上，這樣的數據一樣是很容易讀出來的。這就意外著，那些擁有訪問服務器的企業可以非常容易的使用這些數據。

測試用的的幾個聯系人：

Facebook

[{"name":"John Doe","phones":["1 (234) 567-8910","(555) 555-5555"],”emails”:["joe.doe@joe.com","joe.doe@work.com"],”record_id”:0},{“name”:”Jane Smith”,”phones”:["(888) 888-8888","(222) 222-2222"],”emails”:["jane@smith.com","jane@work.com"],”record_id”:1}]
你可以看到，以上這些信息都可以在服務器上看到。你還可以在這里看到傳送到Facebook服務器的所有原始信息。

Foursquare

正如我們前面所說的，Foursquare更新了其App版本，現在請求通訊錄信息時會有一個用戶提示框。