共用方式為

使用者隱私權

  • 發行項

 

Mary Kirtland

Microsoft Corporation

2001 年 2 月 14 日

在最後一個資料行中，我討論了定義 Web 服務指引小組第一個範例專案我的最愛專案願景。 我對資料行之間的長時間延遲表示抱歉;我已在一個月中獲得較佳的一部分，但很酷。 希望未來幾個月的一般每週資料行現在會回到追蹤。

為了回顧，我的最愛服務目標是要讓應用程式將使用者最愛的連結儲存在安全、安全、中央位置的網站，讓使用者可以透過這些應用程式存取其最愛，無論使用者發生使用的電腦為何。 從技術觀點來看，這似乎相當直接實作。 基本上只是特製化資料存放區。

關於我們開始查看我的最愛服務時，有一篇關於使用者隱私權的新聞文章，特別是協力廠商可以透過網頁上的廣告收集的資訊。 這讓我們思考：整個 Web 服務模型是以使用協力廠商服務的網頁為基礎，最有可能沒有使用者的知識。 是否有隱私權問題需要擔心？

即使沒有良好的使用者隱私權定義，我們仍能夠提出一些建議的 Favorites Service 可能案例，讓似乎有問題。 根據對問題的初始研究，我們決定以階段實作我的最愛服務，將問題案例延遲到後續階段。 在此資料行中，我將討論我們在初始研究期間發現的內容、我們延遲的困難問題、保留在專案第一階段的隱私權問題，以及這些專案對設計和實作的影響。

隱私權定義

讓我們從查看使用者隱私權的意義開始。 我們將著重于使用者隱私權和 Web 的討論。 每當您使用 Web 時，您可能會在使用網頁瀏覽器 (之類的應用程式之間交換三種資訊，例如網頁瀏覽器) ，而應用程式所連線的網站 (，例如瀏覽器中顯示的頁面) ：

  • 您使用一些應用程式組合建立的資訊，例如您撰寫的電子郵件、您的休假相片、財務記錄等等。
  • 應用程式收集的名稱、位址、個人興趣等相關資訊，以便為您提供服務。
  • 您所使用的電腦和/或網路連線相關資訊，例如應用程式所收集的 IP 位址，以便為您提供服務。

使用者隱私權的問題在於如何收集、使用及散發此資訊。 如果您從線上書籍存放區購買書籍，當然您必須提供您的名稱、位址和信用卡號碼，才能讓書籍存放區完成訂單。 但是，如果書籍存放區在資料庫中傾印這項資訊，以及您所購買之特定書籍的記錄，該怎麼辦？ 一方面，它可以使用資訊來提供有用的服務，例如在發佈您最愛作者的新書籍時通知您。 另一方面，它可能會銷售個人資訊，因而造成垃圾垃圾郵件的溢流。 提供您使用之應用程式的公司會合理地使用這項資訊是什麼？

可惜的是，這個問題沒有一個適合全部的答案。 正確做法很難判斷，特別是因為公開認知和政府法規的變動 (，而且可能會因一個法律機關而有所不同，而不同) 。 現今網站的標準做法是張貼隱私權原則，通知使用者收集哪些資訊，以及其使用和散發方式。 不過，在收集資訊之前，使用者是否必須讀取隱私權原則，或使用者才能存取網站，沒有任何標準。

這種情況在 Web 服務中變得更不確定。 使用者可能甚至不知道正在使用任何 Web 服務。 如果 Web 服務收集可系結至特定使用者的資訊， (稱為個人識別資訊) ，服務提供者如何通知使用者收集哪些資訊，以及如何使用或散發？ 將個人資訊散發給 Web 服務的應用程式是否需要向使用者揭露此資訊？ 傳統上，企業並未揭露他們外包其商務程式的特定層面。 例如，公司可能不會揭露訂單履行或客戶支援外包，雖然訂單履行公司與客戶支援組織都能存取客戶的個人資訊。 但規則在線上可能不同。 只有時間會告訴...

公平資訊實務

公平資訊做法可讓客戶知道並控制其個人資訊。 這類資訊會受到保護，以防止不必要的使用、存取或散發，如此一來，客戶在使用公司的產品時便有信心且滿意。 我們的第一步是瞭解使用者隱私權對我的最愛服務的意義，就是閱讀 Microsoft 公平資訊實務。 Microsoft 的公司隱私權群組會定義公平資訊實務的五個元素：

  • 注意事項。 您的公司應該定義有關個人資訊收集、使用及散發的清楚原則。 此原則應包含主要和次要使用資料、在公司內跨營業單位散發資料、與聯盟和非聯盟企業共用資料，以及支援商務交易的廠商合約義務。 公司應建立原則變更的指導方針，以及變更對變更之前所收集的資料的影響。 您將想要與法律顧問合作，確定原則是您可以在網站和 Web 服務中強制執行的原則。 透過多個發佈管道讓客戶和使用者取得原則，包括線上和離線。
  • 同意。 您應該為使用者提供彈性且無障礙的機制，以管理其資料收集、使用和散發的喜好設定。 您必須將資訊分類為合理且有意義的群組，讓使用者能夠找出他們同意的內容，因此使用者不需要太長的時間才能設定喜好設定。 請務必考慮使用者喜好設定的預設值。 使用者是否需要明確啟用特定個人資訊用途， (稱為加入宣告) ，或明確停用使用 (稱為退出) ？
  • 存取。 使用者應該能夠檢視和/或編輯您儲存的任何個人資訊，以確保其保持最新狀態，以及管理使用量喜好設定。 您必須找出使用者可以編輯哪些資訊，以及只能檢視哪些資訊。 例如，使用者可能無法編輯唯一的使用者識別碼，但可以編輯密碼。 在理想情況下，管理個人資訊的工具可供線上和離線使用者使用。
  • 安全性。 您應該實作適當的安全性措施來保護使用者的個人資訊。 這包括驗證和授權機制，以保護對已儲存資料的存取。 它也可能包含在機器之間傳輸期間保護資料的機制。 安全性措施應與資訊的敏感度成正比。 例如，如果您要使用使用者的銀行帳戶或醫療記錄，比使用他最愛的作者清單更擔心安全性。
  • 強制執行。 如果您未遵循隱私權原則，則無法執行任何動作。 您的公司應該定義 (，並遵循) 程式來監視資訊系統，以符合您的隱私權原則。 定義所有客戶資訊服務的爭議解決程式，並維護與協力廠商認證組織的安全關係。 雖然強制執行主要是網站或 Web 服務本身外部，但您應該考慮應保留何種稽核資訊，以支援強制執行程式。 例如，您可能想要追蹤使用者是否已閱讀隱私權原則、使用者修改使用者喜好設定的時機和方式等等。

公平資訊做法和我的最愛

這一切在理論上都很合理，但仍無法完全清楚說明這套用至 Web 服務的方式，或您一般如何為 Web 服務實作所有這些元素。 因此，我花費了數小時來討論公司原則群組成員的問題。 我們從我的最愛服務可能根據初始視覺聲明啟用 (案例清單開始) ：

  1. 使用者會將一些增益集安裝至 Internet Explorer，以提供一組功能表選項，例如 Internet Explorer 我的最愛，不同之處在于我的最愛實際上儲存在 coldrooster.com。 (如果您閱讀最後一個資料行，您知道我們在諮詢服務公司周圍定義了商務案例。我們現在可以看到此虛構諮詢服務公司的名稱是冷 Rooster 諮詢服務，並遵守我們在 Microsoft Campus 上建置的 Rooster。因此，coldrooster.com.)
  2. Coldrooster.com 提供可讓使用者管理我的最愛的 Web 應用程式。
  3. 例如，msdn.microsoft.com 網站提供每個頁面上的按鈕，使用者可以按一下以將該頁面新增至儲存在 coldrooster.com 的使用者最愛。
  4. Msdn.microsoft.com 提供顯示使用者我的最愛的網頁，該網頁原本由使用者代表 msdn.microsoft.com 儲存。
  5. Msdn.microsoft.com 提供 Web 應用程式，可讓使用者管理原本由使用者代表 msdn.microsoft.com 儲存的我的最愛。
  6. 冷 Rooster 諮詢會定期取得所有預存的我的最愛、移除任何連結回特定使用者的資訊，並將其傾印到個別的資料庫進行分析。
  7. Msdn.microsoft.com 提供網頁，無論原本代表使用者儲存我的最愛的網站為何，都會顯示使用者儲存的所有我的最愛。
  8. Msdn.microsoft.com 提供 Web 應用程式，讓使用者管理其所有我的最愛。
  9. 冷 Rooster 諮詢提供個別的 Web 服務，msdn.microsoft.com 可以授權。 此服務可讓授權者擷取資訊，例如「我的最愛」或「儲存此頁面的人員也會儲存這些頁面」，但僅適用于 msdn.microsoft.com 網域。
  10. 冷 Rooster 諮詢提供案例 9 中所述的 Web 服務，不同之處在于傳回給 msdn.microsoft.com 的建議可以包含來自其他網域的我的最愛。

由於我們需要將使用者我的最愛連結至其個人識別，例如電子郵件地址或 Microsoft Passport 識別碼，才能讓所有使用者最愛可透過任何應用程式和任何電腦取得，因此使用者最愛資料絕對落在個人識別資訊類別內。 如果我們停滯于我的最愛服務這個定義，就必須透過原則、程式和程式碼的組合來實作公平資訊做法。

在討論時，沒有任何法律會要求在代表使用者儲存資訊之前通知使用者。 因此，我們可以藉由在 coldrooster.com 上張貼隱私權原則來實作 通知 元素。 使用者如何知道他們需要讀取原則？ 我們提供兩個選項：使用者必須先註冊 coldrooster.com，才能透過我們的服務儲存我的最愛，或者用戶端應用程式必須通知其使用者使用冷 Rooster 諮詢我的最愛服務，以及我們的隱私權原則指標。

從 安全性 的觀點來看，使用者最愛不會落在與醫療記錄相同的類別中，但使用者仍想要對誰可以存取這些記錄進行一些控制。 例如，藉由查看我儲存在主機電腦上的我的最愛，您可以找出我支援的運動團隊、我想要閱讀的書籍類型、我想要聆聽的音樂種類，以及我擁有銀行帳戶的位置，而不是希望世界各地的每個人都能夠存取的資訊。 如果任何人都可以修改我的最愛，他們可以取代我選取的連結， (可能是為了惡意目的而選取的連結，例如攔截機密資訊) 或新增至我的最愛連結。 因此，我們絕對想要保護使用者我的最愛的存取。 而且我們可能會想要讓使用者指定哪些應用程式可以讀取或寫入哪些我的最愛。 例如，我可能會讓 MSDN 修改 msdn.microsoft.com 網域的我的最愛，但我不想讓 MSDN 甚至看到我的最愛運動團隊的連結。 為什麼 MSDN 應該關心那些？

若要讓使用者控制哪些應用程式可以讀取或寫入哪些我的最愛，我們必須實作公平資訊實務的 同意 和 存取 元素。 我們也可能想要實作稽核程式碼以支援 強制執行 專案。

突然，我們的簡單小 Web 服務聽起來並不簡單！ 我們應該為使用者提供何種程度的控制？ 我們應該讓他們確切指定哪些應用程式可以從每個網域讀取或寫入我的最愛？ 或者，我們應該將應用程式和網域分組到區域以簡化設定？ 而且上述哪一個案例預設應該啟用？

我們的隱私權專家對於案例 1 - 5 沒有任何疑慮。 典型的隱私權原則會涵蓋這些案例。 不過，在案例 2 中，我們必須考慮 coldrooster.com 是否應該能夠管理所有使用者的我的最愛，不論哪一個應用程式為使用者儲存我的最愛，還是只是冷 Rooster 諮詢應用程式新增的我的最愛。 我們可能會警告一邊，並指出冷 Rooster 諮詢的應用程式只能管理透過這些應用程式新增的使用者我的最愛，除非使用者明確指定應用程式可用來檢視或編輯使用者代表儲存的所有我的最愛。

即使案例 6 不是太多問題，只要隱私權原則指出我們可以使用預存的使用者我的最愛進一步分析。 同樣地，我們需要考慮資料是否需要依網域或原本提供資料的應用程式進行分割，再進行分析。 而且，由於許多人都很小心資料分析，因此我們可能會想要讓使用者退出宣告將我的最愛包含在用於分析的集區資料中。

其餘案例會從隱私權觀點逐漸變大。 這不表示不應該實作，只是撰寫精確但可理解的原則聲明會比較困難，而且使用者可能不熟悉案例，因此使用者預設應該停用， (使用者必須加入宣告) 。

案例 7 一開始聽起來很不小心，但實際上從 Web 服務的觀點來看，應用程式可以從我的最愛服務取得所有使用者的我的最愛複本。 一旦應用程式有一份資料複本，就可以使用它來執行任何想要的資料。 如果我們提供支援此案例的 Web 服務，我們可能會想要將 Web 服務的存取限制為符合一些最低準則的已知用戶端。

案例 8 更有問題。 一旦應用程式能夠修改使用者的我的最愛，就會防止應用程式將隨機頁面新增至使用者清單，或刪除指向競爭對手網站的我的最愛？ 換句話說，Web 服務如何區分應用程式代表使用者提出的有效服務要求，以及使用者未察覺的應用程式所發出的服務要求？ 使用 HTTP 和 XML 的可用安全性機制並不真正支援這種用戶端/伺服器/服務案例，我們需要實作一些自訂安全性解決方案。 即使使用自訂安全性機制，可能還需要額外的工作，讓使用者指定哪些應用程式可以編輯哪些我的最愛。

最後，案例 9 和 10 更進一步進入線上分析領域，比案例 6 更進一步。 技術問題實際上與先前提到的問題不同，但使用者情緒等級會更高。

根據案例的這項分析，我們決定返回並重新思考我的最愛服務初始傳遞願景。 第一階段的新願景著重于上述案例 3 - 5。 基本上，每個應用程式都有自己的私人市集供使用者我的最愛使用。 如果我移至 msdn.microsoft.com 並儲存此資料行的連結，我只能透過使用者介面檢視或編輯該連結 msdn.microsoft.com 提供。

此方法可消除數個困難問題。 事實上，它會消除整個使用者隱私權問題，因為它與使用者最愛有關！ 由於使用我的最愛服務的每個應用程式實際上都有個別的使用者最愛存放區，因此不需要我的最愛服務所瞭解的全域使用者識別配置。 每個應用程式都可以使用它想要的任何識別碼類型。 我的最愛服務無法解譯這些識別碼，或使不同應用程式所儲存的資訊相互關聯。 由於資料只能由單一應用程式存取 (，或更精確地說，我的最愛服務單一授權) ，因此我們不需要擔心為使用者提供加入宣告或退出各種案例的方式。 我們已有效地將使用者隱私權問題委派回呼叫端應用程式。

這不表示我們不在意解決上述案例分析中所引發的技術挑戰。 我們確實想要在未來的我的最愛服務階段中解決這些問題。 我們只想要花一些時間思考一下，並提出建議給開發人員社群的解決方案。

那麼，如果您需要立即解決問題，該怎麼辦？ 我看不到針對使用者和應用程式實作授權機制的任何方式。 使用者必須使用您的服務註冊帳戶。 這表示您有一個網站，他們可以在其中讀取您的隱私權原則、註冊帳戶，以及管理其喜好設定。 開發應用程式的公司也需要註冊授權，才能使用您的 Web 服務。 您的授權合約應該指定授權者如何通知其使用者如何使用您的 Web 服務。 您必須瞭解您是否可以信任授權，只適當地使用 Web 服務。 若是如此，您可以離開網站收集使用者認證，並將它們傳遞至您的 Web 服務。 如果沒有，您必須提供授權者可用來提供安全機制的一些程式碼，以擷取使用者認證並將其傳遞至 Web 服務。 不論是哪一種方式，都會牽涉到相當多的工作。

其餘隱私權問題

雖然在階段 1 中，我們不需要擔心使用者最愛的使用者隱私權，但仍有一些隱私權問題需要考慮。 我們決定授權存取我的最愛服務。 這表示我們必須維護授權的一些連絡資訊。 該資訊屬於個人識別資訊的類別。 因此，我們有維護帳戶資訊的任何應用程式所面對的標準隱私權問題。

我們已使用原則和程式碼的組合來解決這些問題。 下圖提供系統架構的高階檢視：

圖 1. 第一階段中的我的最愛服務架構

我們的服務是使用分層架構來實作，並部署在兩個實體層、Web 服務器陣列和資料叢集上。 授權帳戶資訊會儲存在資料叢集上的資料庫中。 我們的 Web 服務和網站，授權者會透過該網站管理其帳戶資訊部署在 Web 服務器陣列上。 授權資訊有數層保護：

  • 資料叢集無法從冷 Rooster 諮詢以外的電腦存取。
  • 我的最愛服務不需要存取授權連絡人資訊，因此會使用登入元件來驗證授權。 登入元件只會擷取所需的資訊。
  • 另一方面，授權管理網站需要存取授權連絡人資訊。 如何讓授權者編輯資料？ 網站會透過授權元件執行所有資料存取。 授權元件的存取控制可防止授權管理網站以外的任何專案呼叫元件。
  • 授權資料庫的存取控制可防止登入元件和授權元件以外的任何專案存取資料庫。
  • 每當修改連絡人資訊時，確認電子郵件都會傳送至連絡人資訊中指定的位址。

淨效果：除非授權者的識別碼和密碼遭到入侵，否則未經授權的使用者存取或修改授權連絡人資訊可能非常困難。 即使在這種情況中，如果有人嘗試變更連絡人資訊，則會通知目前的連絡人。

此外，我們會在網站上張貼隱私權原則。 我們也可以提供隱私權原則和其他檔給新的授權，例如有關如何撰寫使用我的最愛服務之應用程式的檔。

結論

使用者隱私權是 Web 服務開發人員及其使用應用程式的尖峰問題。 我們對我的最愛服務問題分析導致我們重新思考服務的完整目標。 即使範圍降低，也會新增大量的需求，以確保使用者資訊受到保護，以防止不當使用。 最重要的需求是限制授權應用程式的存取權。 下周，我們將更詳細地探討授權：我們考慮的商務模型、我們選取的模型，以及模型對設計和實作的影響。

如果您的 Web 服務需要維護個人識別資訊，除了實作服務的核心功能之外，您還需要執行許多工作。 您需要解決公平資訊做法的五個元素：通知、同意、存取、安全性和強制執行。 您必須判斷何時必須直接與使用者解決這些問題，以及何時可以使用 Web 服務將隱私權問題延後至應用程式。 我強烈建議您在這些問題的相關討論中涉及您的法律顧問，以確保不論使用者位於何處，您都是關於使用者隱私權法律的最新狀態。 下列資源提供有關使用者隱私權的其他資訊：