プライバシーファースト設計：メモアプリにおける偏執的なこだわり Privacy-First Design: Obsessive Attention to Detail in a Memo App

1. なぜメモアプリにプライバシーが重要なのか

メモアプリに書かれるものは、その人の頭の中身そのものだ。

パスワードの仮メモ。誰にも言えない相談事の下書き。日記のような独白。仕事のアイデア。買い物リスト。診察前に整理した症状メモ。メモアプリは、ユーザーの最もプライベートな思考が通過する場所である。

だからこそ、ユーザーは「このアプリは自分を見ていない」という絶対的な信頼を必要とする。機能的に優れていても、プライバシーに対する不信感があれば、人は本音を書かなくなる。メモアプリとしての存在意義が根底から揺らぐ。

Captioにはその信頼があった。シンプルすぎるがゆえに、余計なことをしていないと直感的に感じられた。私たちはその信頼を、技術的な設計で裏付ける必要がある。

2. アプリスイッチャーでのプライバシーオーバーレイ

iOSのマルチタスク画面（アプリスイッチャー）は、各アプリのスナップショットを表示する。つまり、ユーザーがメモを書いている最中にホームに戻ると、その内容がアプリスイッチャー上に丸見えになる。

他人がiPhoneを手に取ってアプリスイッチャーを開けば、メモの内容が見えてしまう。パスワードを書いていたら？ 秘密の相談を下書きしていたら？

解決策として、アプリがバックグラウンドに移行する際にプライバシーオーバーレイを表示する。アプリアイコンとアプリ名だけが見える画面で、メモ内容を完全に隠す。

func sceneWillResignActive(_ scene: UIScene) {
    showPrivacyOverlay()
}

func sceneDidEnterBackground(_ scene: UIScene) {
    showPrivacyOverlay()  // Ensure overlay in background too
}

二重の保護を行っている点に注目してほしい。sceneWillResignActiveとsceneDidEnterBackgroundの両方でオーバーレイを表示する。resignActiveはコントロールセンターや通知センターの表示時にも呼ばれるため、あらゆるシナリオでメモ内容を保護できる。

オーバーレイは、アプリがアクティブに戻った時点（sceneDidBecomeActive）で即座に解除される。ユーザーにとっては完全に透過的な保護だ。

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)
}()

• ディスクキャッシュなし：通信内容が端末に残らない
• Cookieの受信・送信なし：セッション追跡の余地を排除
• URLキャッシュ無効化：キャッシュストレージ自体をnilに設定
• セッションの完全な分離：各セッションが独立し、前回の通信情報を一切引き継がない

仮に端末が物理的に侵害されたとしても、通信履歴はディスク上に存在しない。ephemeral URLSessionは、通信レイヤーでの「痕跡ゼロ」を実現する。

4. ログに機密情報を一切出さない

ログは開発者にとって最も基本的なデバッグツールだが、プライバシーの観点からは最も危険な情報漏洩経路のひとつでもある。

このアプリでは、DEBUGビルドであっても以下の情報をログに出力しない。

• メールアドレス
• メモの内容
• 認証コード
• 完全なURL

特に重要なのは、エラーログの設計だ。多くの開発者はerror.localizedDescriptionをそのままログに出力するが、localizedDescriptionにはファイルパス、ユーザーデータ、内部的なURLなど、機密情報が含まれることがある。

func logError(name: String, error: Error) {
    #if DEBUG
    // Only error type. Never localizedDescription.
    os_log("[%.2f ms] ERROR %@: %@", log: log, type: .debug,
            elapsed, name, String(describing: type(of: error)))
    #endif
}

エラーの型だけを記録する。URLErrorなのか、EncodingErrorなのか、CryptoKitErrorなのか——型情報だけでデバッグには十分であり、ユーザーデータは一切漏洩しない。

Releaseビルドではログ出力がゼロになる。#if DEBUGガードにより、本番環境で動作するコードにはログ出力のコードパス自体が存在しない。万が一ログがキャプチャされたとしても、機密データは含まれていない。多層防御の思想だ。

5. AES-GCM暗号化Outbox

このアプリでは、送信ボタンを押した瞬間にUIがクリアされるが、メモ自体はOutboxに保存され、バックグラウンドで送信される。では、Outboxに保存されている未送信メモはどう保護されるか？

• AES-GCM暗号化：すべての未送信メッセージはAES-GCM（Galois/Counter Mode）で暗号化される
• 256ビット鍵：暗号化鍵は256ビットで生成され、Keychainに保存される
• 端末バインド：鍵はKeychainに保存されるため、その端末でしか復号できない
• Apple CryptoKit：暗号化処理はApple純正のCryptoKitを使用。外部暗号ライブラリへの依存はゼロ

仮に端末に物理的にアクセスされたとしても、Keychainのセキュリティが破られない限り、Outbox内のメモは暗号化されたまま読み取ることができない。

Outboxアーキテクチャの全体設計については、Outboxアーキテクチャ：取りこぼしゼロ設計で詳述している。

6. 外部ライブラリ依存ゼロの意味（セキュリティ面）

外部ライブラリの追加は、機能的には便利だが、セキュリティの観点からはすべてが攻撃対象面（Attack Surface）になる。

サプライチェーン攻撃は現実の脅威だ。信頼されたライブラリがアップデートで悪意あるコードを含む事例は、npm、PyPI、CocoaPodsなどのエコシステムで実際に発生している。

このアプリでは、Apple純正フレームワークのみを使用している。

• CryptoKit：暗号化処理
• Network.framework：ネットワーク接続状態の監視
• BackgroundTasks：バックグラウンド送信のスケジューリング
• os.log：ログ出力

サードパーティのコードがユーザーデータに一切触れないという事実は、セキュリティ監査を大幅に簡素化する。監査対象はApple純正フレームワークと自分たちのコードだけだ。依存関係グラフの複雑性がゼロであることは、それ自体がセキュリティ上の強みになる。

7. 設計哲学：「気配を消す」

最良のプライバシー保護は、ユーザーが意識しないものだ。

プライバシー設定画面はない。トグルスイッチもない。「プライバシーモードを有効にしますか？」というダイアログも表示されない。すべてのプライバシー保護機能は、最初から有効であり、無効にする手段は存在しない。

ユーザーはプライバシーについて考える必要がない。アプリスイッチャーにメモが表示されないこと、通信の痕跡が残らないこと、Outboxが暗号化されていること——これらすべてが、サイレントに、バックグラウンドで動作する。

これがCaptio式の体験の延長線上にある設計思想だ。Captioがもたらしたのは「考えずに信頼できる」という感覚だった。プライバシーについても同じアプローチを取る。ユーザーが信頼を意識的に判断する必要がないほど、徹底的に設計する。

1. Why Privacy Matters for a Memo App

What people write in a memo app is the raw contents of their mind.

A temporary password note. A draft of a consultation they can't share with anyone. A diary-like monologue. Work ideas. Shopping lists. Symptoms organized before a doctor's visit. A memo app is the place where a user's most private thoughts pass through.

Because of this, users need absolute trust that the app isn't watching them. No matter how functionally excellent an app is, if there's any distrust around privacy, people stop writing honestly. The very purpose of the memo app crumbles at its foundation.

Captio had that trust. It was so simple that you intuitively felt it wasn't doing anything extra. We need to earn that same trust — but backed by concrete technical design.

2. Privacy Overlay in the App Switcher

The iOS multitask screen (app switcher) displays a snapshot of each app. This means if a user goes to the home screen while writing a memo, that content is fully visible in the app switcher.

If someone else picks up the iPhone and opens the app switcher, they can see the memo content. What if it contained a password? What if it was a draft of a secret consultation?

The solution: display a privacy overlay when the app transitions to the background. A screen showing only the app icon and title, completely hiding the memo content.

func sceneWillResignActive(_ scene: UIScene) {
    showPrivacyOverlay()
}

func sceneDidEnterBackground(_ scene: UIScene) {
    showPrivacyOverlay()  // Ensure overlay in background too
}

Notice the double protection. The overlay is applied in both sceneWillResignActive and sceneDidEnterBackground. Since resignActive is also called when Control Center or Notification Center appears, this ensures memo content is protected in every scenario.

The overlay is immediately removed when the app becomes active again (sceneDidBecomeActive). For users, it's completely transparent protection.

3. Ephemeral URLSession: Leave No Communication Trace

The standard URLSession stores cache, cookies, and credentials to disk. For typical apps this is convenient functionality, but for a memo app it's unnecessary and potentially risky.

Communication cache persisting on the device means traces of which URLs were accessed and when exist on disk. Cookies being stored means session information remains on the device.

This app uses URLSessionConfiguration.ephemeral.

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

• No disk cache: Communication content doesn't persist on the device
• No cookies sent or received: Eliminates any possibility of session tracking
• URL cache disabled: The cache storage itself is set to nil
• Complete session isolation: Each session is independent, carrying over zero information from previous communications

Even if the device is physically compromised, no communication history exists on disk. Ephemeral URLSession achieves "zero trace" at the communication layer.

4. Never Log Sensitive Information

Logs are a developer's most fundamental debugging tool, but from a privacy perspective, they're also one of the most dangerous information leakage vectors.

In this app, even in DEBUG builds, the following information is never logged:

• Email addresses
• Memo content
• Authentication codes
• Full URLs

Particularly critical is the design of error logging. Many developers output error.localizedDescription directly to logs, but localizedDescription can contain sensitive information such as file paths, user data, and internal URLs.

func logError(name: String, error: Error) {
    #if DEBUG
    // Only error type. Never localizedDescription.
    os_log("[%.2f ms] ERROR %@: %@", log: log, type: .debug,
            elapsed, name, String(describing: type(of: error)))
    #endif
}

Only the error type is recorded. Whether it's a URLError, EncodingError, or CryptoKitError — type information alone is sufficient for debugging, and zero user data is leaked.

Release builds have zero log output. The #if DEBUG guard means the code path for logging doesn't even exist in production binaries. Even if logs were somehow captured, they would contain no sensitive data. This is the defense-in-depth philosophy.

5. AES-GCM Encrypted Outbox

In this app, the UI clears the moment the send button is pressed, but the memo itself is saved to the Outbox and sent in the background. So how are unsent memos in the Outbox protected?

• AES-GCM encryption: All unsent messages are encrypted with AES-GCM (Galois/Counter Mode)
• 256-bit key: The encryption key is generated at 256 bits and stored in the Keychain
• Device-bound: Since the key is stored in the Keychain, decryption is only possible on that specific device
• Apple CryptoKit: Encryption is handled by Apple's native CryptoKit. Zero dependency on external crypto libraries

Even with physical access to the device, Outbox memos remain encrypted and unreadable as long as Keychain security is maintained.

For the complete Outbox architecture design, see Outbox Architecture: Zero Message Loss Design.

6. Zero External Library Dependencies (Security Perspective)

Adding external libraries is functionally convenient, but from a security perspective, every single one becomes an attack surface.

Supply chain attacks are a real threat. Cases where trusted libraries include malicious code in updates have actually occurred across ecosystems including npm, PyPI, and CocoaPods.

This app uses only Apple's native frameworks:

• CryptoKit: Encryption operations
• Network.framework: Network connectivity monitoring
• BackgroundTasks: Background send scheduling
• os.log: Logging output

The fact that no third-party code touches user data dramatically simplifies security auditing. The audit scope is limited to Apple's native frameworks and our own code. Having zero dependency graph complexity is itself a security strength.

7. Design Philosophy: "Disappear Without a Trace"

The best privacy protection is the kind users never think about.

There is no privacy settings screen. No toggle switches. No "Would you like to enable privacy mode?" dialog. All privacy features are enabled by default, and there is no way to disable them.

Users don't need to think about privacy. The fact that memos don't appear in the app switcher, that no communication traces remain, that the Outbox is encrypted — all of this operates silently, in the background.

This is a design philosophy that extends from the Captio-style experience. What Captio delivered was the feeling of "trust without thinking." We take the same approach with privacy. The design is so thorough that users never need to consciously evaluate whether they can trust the app.