要約

  • Matchaは、データの扱いを生むコードやSDKの近くにプライバシー表示の作成を置き、提案を読み解く責任は開発者に残す。
  • 12人の開発者を対象にした研究では多くの表示がより正確になった一方、ストアのフォームより時間がかかり、プラットフォーム全体の正確性を証明するものではない。

プライバシー情報はアプリのダウンロード欄に表示されるが、その準備は開発環境とは別のフォームで行われがちだ。この距離が誤りを生む。フォームはアプリが何を収集、共有、利用するかを分類させる。根拠は自社コードだけでなく、外部ライブラリ、設定、サーバー側の処理にも分散している。開発チームがアプリの意図を理解していても、組み込んだ依存先の挙動まで把握しているとは限らない。

AppleとGoogleの仕組みは異なる。AppleのApp Privacyはアプリ単位の回答で、外部パートナーの取り扱いも含め、実態が変われば更新する必要がある。Google PlayのData safetyはパッケージ単位のグローバルな申告で、配布中の各版と関係するSDKの実態を対象にする。Googleは、正確な申告に必要な情報を持つのは開発者だけであり、ストア審査は正確性を検証するためのものではないと説明する。両者の分類も作業手順も同一ではない。(Apple／Google Play)

コードを書く場所に根拠を置く

Lorrie Cranorはプライバシー工学、公共政策、使いやすいセキュリティにまたがって研究してきた。Carnegie MellonのCUPS研究室によると、初期のプライバシー・ニュートリションラベルの設計チームはPatrick Gage Kelleyが率い、Cranorも参加していた。目的は慣れない規約を理解・比較しやすくすることだった。Cranor一人の発明ではなく、研究チームの仕事である。(CUPS／CMUプロフィール)

2024年にCranor、Tianshi Li、Yuvraj Agarwal、Jason Hongが発表した論文は、Google Playの申告を支援するAndroid StudioプラグインMatchaを紹介する。API呼び出しやキーワードから自社コードのデータアクセス・送信の手掛かりを探し、開発者が注釈を付ける。外部SDKについては編集可能なXMLで実態を整理し、最後にPlay Consoleへ取り込めるCSVを出力する。根拠をコードを点検する環境に置き、人が提案を確かめ、直し、退けられるようにした点が設計の核だ。(Matcha論文／公開版／プロジェクトページ)

精度と時間の交換条件

自分たちのアプリについてラベルを作った12人のうち、11人はPlay ConsoleのフォームよりMatchaで正確な表示を作れた。対象は6つのGoogle Playアプリだった。一方、平均作業時間はMatchaが30分、コンソールが9.8分。研究の範囲では、根拠をたどる作業に約3倍の時間がかかった。

これはワークフローの有望な証拠であって、全アプリの表示が正確になるという保証ではない。著者らは、先にコンソールを使ったことで二度目の作業が容易になった可能性、誤りの基準となる完全な正解がなかったこと、大企業の開発組織には結果を一般化しにくいことを挙げている。コード解析は端末の外に出たデータのサーバー保存や二次利用をすべて把握できない。開発者の知識と確認は欠かせない。

ストアの表示は、開発者なら何を知っているはずだとルールが想定しているかを映す鏡でもある。MatchaはコードとSDKの証拠を申告につなぎ、その期待を実務に近づける。表示そのものを監査に変えるわけではない。公開前に不明点や不一致を見つけ、直せる場所をつくることに意義がある。