約束ではなくアーキテクチャでプライバシーを担保する

約束モデル

ほとんどの「プライバシーファースト」を謳うプロダクトは、ある約束を中心に組まれている。「あなたのデータを集めますが、丁寧に扱うと約束します」。約束が誠実であることもあれば、CEO交代を生き延びることもあれば、令状で吹き飛ぶこともある。約束は構造上、約束した会社と同じだけしか耐久しない。

アーキテクチャモデル

別のやり方：プロダクトの作り自体で、約束を物理的に不要にする。アカウントなし。テレメトリなし。クラウド同期なし。ネットワーク権限を切ってもアプリは動き続ける。プライバシー特性はポリシーページで主張されるのではなく、「それを破る可能性のあるコードが一行も存在しない」ことで強制される。

具体的には：

• 解析SDKなし。 Mixpanelもなし、Amplitudeもなし、自前イベントパイプラインもなし。ユーザ数すら私たちには分からず、それが意図だ。
• リモート設定なし。 私たちの脅威モデルでは、フィーチャーフラグはバックドアである。私たちが出すあらゆるバイナリは、1日目と300日目で同じ振る舞いをする。
• バックグラウンドアップロードなし。 ログはローカル、オプトイン、サポートメールにユーザが貼った時にだけ表に出る。
• サードパーティドメインなし。 Fluxアプリのネットワーク呼び出しはOS仲介のもの（App Storeのアップデート、システムプッシュ）に限られ、私たち自身のものは存在しない。

払うコスト

• 通常のA/Bテストはできない。小さな社内ユーザスタディとサポートメールで補う。
• ユーザのデータを覗いてバグを直すことはできない。ローカルで安定再現できることに頼る。
• 機能は最初から正しく動く必要がある。「あとでダッシュボードから調整」は存在しない。

得るもの

• 規制当局がtcpdumpで検証できるプライバシー主張。
• 私たちを信頼しなくていいユーザベース——彼らは検証できる。
• 5年後も動き続けるために課金関係に頼らないので、長持ちするプロダクト。

約束モデルは会社をスケールさせる。アーキテクチャモデルは信頼をスケールさせる。私たちは後者を選んだ。