隱私第一設計：備忘錄應用程式中的偏執的執著

1。 為什麼隱私對備忘錄軟體很重要

工作想法、個人草稿、日常記錄。 在備忘錄軟體中，會收集給別人看之前的資訊。 和快速書寫一樣，能夠理解儲存在哪裡，被送到哪裡也很重要。

在這篇文章中，將分別說明終端內的加密、通訊快取、畫面顯示、診斷日誌和使用分析。 一種保護並不能保證其他途徑的保護。

2。 在應用程式切換器中自動隱藏備忘錄的功能無效

iOS將應用程式移動到後臺後的畫面作為快照使用。 Apple會引導畫面中，如果畫面有機密資訊的話，在移動到背景時要清除。

在確認的5.8.17的源中，sceneWillResignActive和sceneDidEnterBackground進行草稿儲存，不呼叫隱私疊加的顯示處理。 雖然保留了以前的顯示用函式，但不是作為有效保護執行的路徑。

顯示中的備忘錄可能會留在應用程式切換器的影象中。 即使對Outbox進行加密，畫面影象也不會被隱藏。 更正這篇報道舊版中的“經常隱藏備忘錄內容”的說明。

3. ephemeral URLSession：抑制通訊快取的磁碟儲存

標準的URLSession將快取、Cookie、認證資訊儲存在磁碟上。 在一般的應用程式中，這是一個很方便的功能，但在備忘錄應用程式中是不需要的，可能會成為風險。

通訊快取留在終端上，意味著磁碟上存在何時訪問哪個URL的痕跡。 Cookie被儲存意味著會話資訊會留在終端上。

在這個軟體中，使用URLSessionConfiguration.ephemeral。

private let session: URLSession = {
    let config = URLSessionConfiguration.ephemeral
    config.httpCookieAcceptPolicy = .never
    config.httpShouldSetCookies = false
    config.urlCache = nil
    return URLSession(configuration: config)
}()

• 無磁碟快取：不將此URLSession的快取儲存到磁碟
• Cookie的使用無效：這個URLSession不接受Cookie，也不設定要求
• URL快取失效：將快取儲存本身設定為nil
• 不使用永久儲存的構成：URLSession的會話資訊不儲存到磁碟

這是關於URLSession的快取等的保護，不是應用程式單獨儲存、傳送的使用事件或消除伺服器端的傳送記錄的功能。 透過使用解析的識別符號進行關聯，也與這個設定分開進行。

4。 效能測量日誌的輸出範圍

PerformanceLogger的日誌輸出被#if DEBUG包圍。 在沒有定義DEBUG的構建中，不包含這個記錄器的日誌輸出處理。

這個記錄器的logError，記錄的不是錯誤的詳細文，而是型別。 例如，使用URLError這種型別，不直接輸出可能包含檔案路徑和使用者輸入的localizedDescription。

另一方面，不是自動將傳遞給logEvent的事件名和附加字串全部無害化的機制。 呼叫方需要不傳遞郵箱地址、備忘錄正文、認證資訊。

這個說明不擴充套件到應用程式、外部SDK、OS整體的“零日誌”的保證。 本公司的使用事件傳送和AppsFlyer作為不同的機制生效。 獲取範圍在本報道的使用分析FAQ和隱私政策中說明。

5。 AES-GCM加密Outbox的保護範圍

等待傳送的備忘錄，在終端內的Outbox佇列中進行管理。 儲存時使用Apple的CryptoKit用AES-GCM進行加密。 新的密碼金鑰用256位元生成。

鑰匙存放在Keychain中，使用kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly。 在這個設定中，從重啟後的首次解鎖到下次重啟都可以訪問，備份恢復到其他終端時不會轉移鑰匙。 應用程式為了加密、解密讀取金鑰。

這是儲存資料的保護，並不是隱藏顯示中的畫面，也不是保證免受任何終端侵犯的安全。 在更換機型之前，請確認必要的備忘錄是否已送達儲存地址。

使用郵件傳送時，正文由本公司的Relay API和配送基礎處理，作為郵件留在收件箱中。 終端內的加密並不意味著郵件配送的端到端加密（E2EE）。 詳細內容在隱私政策和資料的通道中說明。

等待傳送的佇列，請參考Outbox架構的解說。

6。 備忘錄正文的保護和外部SDK的作用

iOS在應用內，備忘錄正文的加密使用CryptoKit，鑰匙保管使用Keychain，正文的傳送使用URLSession。 Network.framework負責監視連線狀態，BackgroundTasks負責後臺傳送的排程。

另一方面，應用程式也使用外部SDK。 GoogleSignIn和Firebase Authentication用於Google賬戶的任意郵件自動輸入，Firebase App Check在啟動時初始化保護後端API。 AppsFlyer用於獲取、使用分析，設定與本公司分析共同的安裝識別符號。

即使設計不將備忘錄正文納入事件專案，也會保留識別符號和傳送記錄的關聯。 包括SDK在內的使用分析範圍，需要與本文的加密分開確認。 專案和用途在隱私政策中進行了說明。

7。 明確保護範圍

終端內的加密、通訊快取的處理、利用分析，分別具有不同的作用。 即使有Outbox的加密和ephemeral URLSession，使用事件的收集也不會消失。

重視能夠快速留下備忘錄和能夠理解獲取的資訊。 說明使用分析的傳送目的地、識別符號、關聯的範圍，根據應用程式的變化進行重新審查。