なぜ日記をサーバーに置かないと決めたのか

日記アプリを作るとき、最初に決めなければならなかったのは機能ではなく、データをどこに置くかでした。サーバーに置けば開発はずっと楽になります。機種変更しても自動でついてきて、Web でも開けて、バックアップを気にする必要もありません。いまのアプリの多くはそう作られています。

でも、日記は少し違います。今日誰に会って何を話したか、誰に腹が立ち、何が怖かったかを書く場所です。その文章が他人のサーバーに平文でたまっていると思うだけで、書けなくなる話があります。だから逆に決めました。基本は端末の中、外に出るのはユーザーが自分で書き出すときだけ。

そのかわりに、あきらめたこと

この決定には代償があります。いいことだけを書けばそれは説明ではなく広告なので、まず失ったものから書きます。

これを受け入れられるかは人によって違います。複数の端末で続けて書くことがより大事な方にとって、いまの mylog はいい選択ではありません。それは隠すことではなく、先にお伝えすべきことです。

そのかわり、データを閉じ込めません

端末の中だけに置くアプリがよくやってしまう失敗があります。自分しか読めない形式で保存して、アプリを消した瞬間に記録を人質にすることです。

mylog のバックアップは標準の JSONです。メモ帳で開けばそのまま読めます。写真まで含めた完全バックアップは zip なので、解凍すると写真がファイルのまま出てきます。アプリが気に入らなくて離れるときも、記録は持っていけます。離れられるからこそ、残ることも選択になります。

バックアップにパスワードを設定すると、端末の中で AES-256-GCM で暗号化します。鍵はパスワードから scrypt で作り、パスワード自体はどこにも送信しません。だからこのファイルは、クラウドに置いても運営者には開けません。開けないように塞いでいるのではなく、開ける鍵をそもそも持っていないのです。

Web ビューアも同じルールに従います

バックアップファイルを PC で大きく見たいときに使うバックアップビューアは、ファイルをサーバーにアップロードしません。ブラウザの中で開き、ブラウザの中で復号し、ブラウザの中で描きます。ログインも不要です。いちばん私的なファイルを開くためにアカウントを作れというのは、話があべこべですから。

アカウントが必要なのはひとつだけ。暗号化したバックアップをクラウドの保管庫に置きたいときです。その保管庫にはパスワード付きのバックアップだけがアップロードされ、先に書いた理由で運営者はその中身を見られません。アプリ自体はアカウントなしで動きます。

統計はオン・オフできるように、そしてそもそも少なく

どの機能が実際に使われているかわからなければ、何を直すべきかもわかりません。だから匿名の利用統計は受け取っています。ただし、ふたつのことを守ります。

ひとつ目、設定からいつでもオフにでき、オフにしてもすべての機能をそのまま使えます。オフにすると、まだ送っていない記録と一時的な番号が端末から消えます。

ふたつ目、オンのままでも受け取るのはどの画面を開いたか程度です。日記・メモ・やることの内容やタイトルはもちろん、記録の数、正確な時刻、精密な位置(GPS)、端末固有の識別子、広告識別子も受け取りません。アプリは Firebase Analytics(Google)、ホームページは Google Analytics 4を使っています — どちらも Cookie・識別子を使い、Google に送信されます。何をどこまで送るかは、プライバシーポリシーの第3項・第4項にそのまま書いてあります。

お問い合わせも同じ基準です。返信するためにメールアドレスと内容は受け取りますが、IP は保存せず、1年たつと自動で削除します。これはポリシーに書いただけの文ではなく、実際に毎日動いている削除の処理があります。

これから

複数の端末で続けて書きたいという声をいちばん多くいただきます。それはサーバー費用がかかる機能なので、有料プラン(Pro)として準備しています。ただ、そのときもデフォルトは変わりません。オンにしなければ何もアップロードされず、アップロードされても開けない形でなければならない、ということです。

時期や価格はまだ決まっていません。決まっていないことを先に約束するかわりに、決まったらそのときにお知らせします。