備忘錄正文經過哪裡，
不留在哪裡

1. 在終端內建立 — 用AES-GCM-256保護寫的備忘錄首先進入終端內的Outbox（未傳送佇列）。 Outbox和傳送歷史由Apple純正CryptoKit透過AES-GCM-256加密，256-bit對稱金鑰儲存在Apple Keychain中。 金鑰是不轉移到其他終端的設定，在應用程式加密、解密時讀取。 備份中包含的金鑰複製也不能在其他終端上使用。 在更換機型之前，請確認必要的備忘錄是否已送達儲存地址。 鑰匙管理的詳細內容和Apple的說明。 離線的話在這裡等待，線路恢復後自動重新傳送。
2. Obsidian Vault的追記 — 這裡是完全本地Obsidian啟用關聯時，Vault的追記是終端內的Vault資料夾直接寫入檔案（打不開的話URI回退）進行，不使用外掛和外部伺服器。 Vault追記的路徑中沒有網路。
3. AI標籤—在裝置上完成標題（20字以內）、標籤（1~3個）、種類（todo/idea/log）的自動授予，Apple Foundation Models的機上AI只在iPhone中進行。 為了標記，備忘錄正文不會傳送到外部伺服器。 Apple Intelligence不支援的機型會自動回退到終端內的輕量整形。
4. 郵件傳送——經 TLS 傳輸，不永久儲存僅在傳送時，正文透過 TLS（HTTPS）經過我們的 Relay API（Cloudflare Workers）和外部傳送基礎設施（Resend）。正文不會被永久儲存，也不會寫入日誌。客戶端使用 URLSessionConfiguration.ephemeral，不保留 Cookie 或快取。
5. 到自己的收件箱 — 標準SMTP配送（=不是E2EE）最終配送是標準SMTP。 正因為如此，在平時的郵件軟體上可以直接閱讀，但不是端到端加密（E2EE）。 關於這個設計判斷，請看下面的“誠實地寫下來”。

iOS在應用內，備忘錄正文的加密使用CryptoKit，鑰匙保管使用Keychain，正文的傳送使用URLSession。 GoogleSignIn和Firebase Authentication用於任意郵件自動輸入，Firebase App Check用於後端API的保護。 本公司的使用分析和AppsFlyer，根據應用版和分析的選擇，處理方式也不同。

在設定中提供「使用情況分析」選項的版本中，自有使用事件和來自裝置的訂閱狀態分析預設關閉，同意後才開始。在另行提供獲客測量選項之前，這些版本的 AppsFlyer SDK 會保持停止。沒有此選項的版本也會傳送自有使用事件和來自裝置的訂閱狀態分析。我們撤銷自 9 月 28 日起實施的、不儲存舊方式請求的伺服器端限制，不會追溯補齊先前未收集的事件。AppsFlyer 獲客與使用情況測量的條件請參閱隱私權政策。 有有效同意的對應版的本公司分析，處理安裝、會話的識別符號、使用事件、傳送結果等。 舊版的AppsFlyer傳送首次備忘錄成功、認證成功、收費畫面顯示、方案選擇、購買成功，將相同的安裝識別符號設定為Customer User ID。 從應用程式設定的活動專案中不直接包含郵箱地址、備忘錄正文、驗證碼，但本公司的傳送ID與收件人雜湊繫結，獲取資訊和使用記錄也會相關聯。 不是完全匿名的解析。 撤銷同意和版本的條件是政策1(E)，專案詳情請看隱私政策。