ローカル保存はプライバシー確認の一部分

出生プロフィールをパソコンに保存していても、その情報がモデル提供元へのリクエストに含まれることがあります。セッション自体はローカルフォルダーに残ったまま、そのスクリーンショットが公開フォーラムに投稿されることもあります。鑑定アプリのプライバシーを確認するときは、作業の各段階で情報をたどりましょう。

確認したMystilinkのデスクトップ版リポジトリでは、出生プロフィールを、プロジェクトルートの.mystilink/profiles/ディレクトリ内にローカルのJSONファイルとして保存すると説明しています。また、プロフィールへの参照から保存済みデータを読み取り、ユーザーのコンテキストに渡すスナップショットを作る仕組みも記載されています。前者は保存場所、後者は選んだ情報が会話に入る方法であり、別々の段階を説明しています。

この記事は、確認の手順を提案するものです。公開されたプライバシーポリシー、保存期間の保証、公開済みのすべてのビルドの動作を定めるものではありません。実際の個人情報を送るか判断するときは、アプリの現在の開示内容と、提供元の利用条件を確認してください。

個人データを入れる前に経路を書く

最初の確認には架空のプロフィールを使います。どこに入力し、アプリがどこへ保存し、メッセージで参照すると何が起きるかを書き出します。「今回のリクエストでは、どの項目がモデルに届くのか」という簡単な問いに、具体的に答えられる必要があります。

出生プロフィールには、今の作業に必要な量を超える情報が含まれていることがあります。入力フォームの仕組みを話し合うだけなら、出生データ自体が不要かもしれません。計算の練習では日付と場所の一部の項目が必要でも、氏名や人間関係のメモは使わない場合があります。入力を減らすことは、読み手が選べる最も手軽なプライバシー対策であることがよくあります。

ローカルのパスだけでは、暗号化、OS上のアクセス、バックアップ、同期ソフトについては分かりません。フォルダーがクラウドバックアップの対象なら、そのバックアップを別に確認します。パソコンやアカウントを複数人で共有しているなら、そこへのアクセスも確認しましょう。フォルダー名だけから保護の内容を推測しないようにします。

リクエストの接続経路を確認する

確認したプラットフォームのデスクトップ連携文書は、アカウント認証を使うNewtonゲートウェイ経由の接続と、提供元へ直接接続するBYOKのリクエストを区別しています。ゲートウェイではアカウントのJWTを使います。その文書によると、BYOKでは、ユーザーが用意した提供元のキーをクライアントが使い、提供元へ直接接続します。

経路によって関わる当事者が異なるので、プロフィールを送る前に、選んでいる経路を特定します。提供元名やモデル名だけでは、どの接続が有効か分からない場合があります。現在の接続設定と関連文書を確認しましょう。設定を示すためであっても、アクセストークンや提供元のキーをフォーラムに貼り付けてはいけません。

確認を意味のあるものにするには、モデルへのリクエスト内容と、アカウント認証を分けて扱います。トークンはリクエストを認可するためのもので、鑑定そのものの一部にするべきではありません。開発者として通信の証拠を取得する場合は、保存や共有の前に認証情報を伏せます。コンテンツの執筆者に通常必要なのは経路の説明であり、秘密情報を含む生の通信記録ではありません。

診断情報を別の経路として確認する

確認したprivacyLevel.tsには、strict、balanced、diagnosticの各レベルが定義されています。strictでは、環境変数による上書きでリモートへの診断情報の報告を無効にします。diagnosticでは、同じ上書きの仕組みで報告を有効にします。balancedでは、保存された診断情報の設定が明示的に有効になっているかどうかに従います。

これは、そのファイル内での診断情報の判断に限った説明です。strictモードがモデルへのリクエストや、考えられるすべてのネットワーク接続を無効にするという意味ではありません。利用者が意図してリモートモデルにメッセージを送ることは、依然としてありえます。設定名がより広い約束にならないように、各制御が対象とする活動を具体的に説明します。

同じファイルでは、診断情報への同意を求める案内をすでに表示したかも確認しています。その状態を確認する処理だけでは、公開された画面の文言全体、表示の時点、同意の取り扱いまでは分かりません。ビルドを評価するなら、実際に画面に何が表示されるか、環境変数の設定がそれを上書きするかを記録します。

アプリの画面の外も調べる

プライバシーの確認は、メッセージを送ったところで終わりがちです。保存された会話履歴、サポート向けの添付ファイル、エクスポートしたノートまで続けましょう。一見問題のない抜粋でも、周囲の文章に、本人の特定につながる日付、家族関係、地名が含まれているかもしれません。投稿前に、共有するもの全体を確認します。

公開の不具合報告では、人物と出生の詳細を、問題を再現できる架空のプロフィールに置き換えます。ある項目を変更すると問題が消えるなら、元の値を明かさずに、その関係を報告します。非公開のサポート窓口も情報の受け渡しであることに変わりはありません。受け取る側の調査に必要なものだけを含めます。

削除についても、何を削除するのかを特定する必要があります。アプリの一覧からプロフィールを取り除くこと、ローカルファイルを消すこと、セッションを消すこと、リモートサービスへ削除を依頼することは、別々の操作です。関係する保存先ごとに、現在の製品で文書化された動作を確認します。一度の削除ですべてのコピーが消えるとは考えないでください。

短い確認記録を残す

ビルド、接続経路、診断情報の設定、使った架空のテストを記録します。未回答の問いと、それに答える当事者も加えます。たとえば、アプリの保守担当者は、どのコンテキスト項目が組み立てられるかを説明できます。一方、受け取ったリクエストの扱いは、選んだ提供元の公開条件で確認します。

提供元を変えるとき、診断情報を有効にするとき、プロジェクトフォルダーを同期サービスへ移すときは、この記録を見直します。実用的なプライバシー確認は、実際の操作に即して行います。何を入力し、何を省き、どこをさらに確認するかを判断できるだけの情報を、読み手に提供します。