F-DroidがGoogleの開発者認証を「保護を装った脅威」と呼んで批判した記事を読んだ。率直に言うと、最初は「まあセキュリティ強化ならしゃーないか」くらいの温度感だった。でも読み込むうちに、これ個人開発者にとってかなりえぐい話だと気づいた。
ポイントを整理すると、認証を通していないAPKをインストールしようとすると、最初の検証から24時間待機しなければならない。F-Droidで公開されているアプリは全部この制約を受ける。自分でビルドしてサイドローディングしている人も同様だ。
認証がマルウェアを防ぐかどうかという話
今回いちばん刺さったのはF-Droidの指摘で、開発者認証はアプリにマルウェアが仕込まれているかどうかを検証するものではないという点だ。GoogleアカウントとAPKの情報が一致するかを見るだけ。だから悪意のある開発者が新しいアカウントを取ってマルウェアを再配布しようとする際、「その活動を多少遅らせられるかもしれないというだけ」だとF-Droidは書いている。
これ、技術的に考えると本当にそうで、署名鍵を新しく作るコストはほぼゼロに近い。攻撃者が本当に回避しようと思えば普通に回避できる。セキュリティ上の実益がほぼないのに、F-Droidや個人開発者への摩擦だけがえぐく増える構図になっている。
利用規約の「マルウェア」定義が怖すぎる
もう一個ヤバいと思ったのが、Android Developer Consoleの利用規約の話だ。「マルウェアその他の有害なアプリケーションを配布した場合、Googleはアクセスを終了する」という文言があるんだけど、マルウェアの定義がどこにも書いていない。F-Droidは「Googleがマルウェアと判断したらマルウェア」になると指摘している。
広告ブロッカーがすでにGoogle Playから排除されているのは知っていたけど、一部はマルウェアと分類された例すらあると書かれていた。これはかなり怖い。たとえばネットワークのトラフィックをフィルタリングする系のツールや、権限管理を強化するユーティリティあたりも、Googleの判断次第で同じ扱いになりうる。
自分は今、個人開発でAndroid向けのちょっとしたツールを作っている。Wi-Fiのパケットをモニタリングする簡易ツールで、自分の検証環境でだけ使う想定のものだ。Google Playに出す気はなくて、APKを直接配ってた。こういうグレーゾーンなユーティリティがどう扱われるか、正直読めない。
Keep Android Openには開発者数十万人と世界70以上の団体がすでに署名しているらしい。自分も署名しておいた。効果があるかは分からないけど、声を上げないと何も変わらない。
今の自分のコードとワークフローをどう変えるか
現実的な対応として、今手元でやろうとしていることを書く。
- 配布用APKのビルドスクリプトにGit commitハッシュとビルド日時を埋め込んで、どのソースからビルドしたか追跡できるようにする
- GitHub Actionsでreproducible buildを通す構成にしておく (F-Droidがやっているようなビルドプロセスの透明化)
- 配布するAPKの署名鍵の管理を今のうちにきちんとやっておく
# build.gradle.kts に差し込む例
android {
defaultConfig {
buildConfigField("String", "GIT_HASH", "\"${gitHash()}\"")
buildConfigField("String", "BUILD_DATE", "\"${buildDate()}\"")
}
}reproducible buildは手間がかかるけど、F-Droidがやっているようにビルドプロセスを公開して検証可能な状態にしておくのが、認証に頼らない信頼の示し方だと思う。Googleが認証を通していないアプリを締め出していくなら、自分たちでトレーサビリティを担保する方向に動くしかない。
正直、Androidのオープン性は自分がAndroidを選び続けている理由のひとつだった。18年間続いてきたその文化がこういう形で削られていくのを見ると、iOSと変わらなくなるじゃんという気持ちがある。次のリリースまでに署名フローを整理して、せめて自分のツールは透明性を保てる状態にしておく。