- Googleの公式発表ではなく、進行中の IssueTracker機能リクエスト で、ADBの中核メンテナーが悪用防止のためローカル接続を制限し、
wlan0にのみバインドする案に言及 wlan0のみ許可すると、ループバックアドレス127.0.0.1を使う オンデバイスADB はもちろん、VPN・EthernetベースのADBや各種開発環境まで動作しなくなる可能性- 議論は、Wireless ADB認証を完全に回避した CVE-2026-0073 をきっかけに始まり、元の要望はADBDの待受インターフェースを選択して全ネットワークに露出しないようにすること
- 一般的な悪意あるアプリは、ADBDを直接起動したり、Wireless ADBのペアリングやTCP/IP承認を単独で完了したりできないため、ユーザーの 手動操作 なしにADB権限を得るのは難しい
- ループバック接続を恒久的に遮断するとShizukuやlibadb-androidベースのツールに影響するため、デフォルトの遮断を再起動後も解除できる ユーザー選択設定 が必要
公式発表ではない初期段階の議論
- 今回の件はGoogleの確定した方針や公式発表ではなく、進行中の IssueTracker機能リクエスト とADBの中核メンテナーのコメントに基づくもの
- 担当者は、アプリがADBDのローカルソケットを使って権限昇格した事例を挙げ、ADBDをWi-Fiインターフェースである
wlan0にのみバインド する案に言及 - 公開議論では、単なる抗議や侮辱、同一ユースケースの繰り返しを避けるべき
- 固有のユースケースがあるなら、ワークフローや関連リンク、技術的な妥協案を含めて具体的に意見を残せる
- 同じ事例がすでに登録されているなら、コメントを繰り返すより +1 と通知機能の利用が推奨される
- 低品質なコメントが殺到すると、Issueがロックされたり、有用なフィードバックや公開アップデートが減ったりする可能性がある
ADBの3つの接続方式
- ADB は、Androidデバイスをテスト・管理する開発者や上級ユーザーに高い権限のコマンドアクセスを提供するプロトコル
- 主な接続方式は3つに分かれる
- USB: 別のコンピューターからUSBケーブルでデバイスに直接接続する本来の方式
- ADB TCP/IP: 通常は
5555ポートを使い、トラフィックは平文で送られ、YES/NO承認ダイアログで認証する。既存のADB接続がないと有効化できない - Wireless Debugging: Android 11で導入され、コードまたはQRコードでコンピューターをペアリングした後、認証・暗号化された接続を構成する。有効化に既存のADB接続は不要
オンデバイスADBが生んだエコシステム
- 一般的なADBはAndroidデバイス上のADBDと別の開発用コンピューター上のADBクライアントを接続するが、コンピューターなしでAndroidデバイスから直接作業する開発者もいる
- オンデバイスADB(On-Device ADB) は公式用語ではなく、Termux のようなターミナルエミュレーターでADBクライアントを実行し、同じデバイスのADBDに接続する方式を指す
- ADB TCP/IP または Wireless Debugging を使う
- クライアントとサーバーが同じデバイス上にあるため、ループバックアドレス
127.0.0.1を通る
- この方式は、libadb-android、Shizuku など、開発者・上級ユーザー向けオープンソースプロジェクトの基盤になっている
- ShizuCallRecorder は、障害による日常的な困難を減らすために作られたShizukuベースのアプリ
- あるユーザーは亡くなった家族の音声メールを保存するためにこのアプリを使用した
- Androidの通話録音はユーザー要望が多く、Android 11で公式機能化が進められたものの中止され、現在はクローズドなものやプライバシー侵害の可能性がある回避アプリも存在する
- 一部のOEMは、法的に必要でない地域でも通話録音の案内音声を強制している
インターフェース選択要求と wlan0 制限
- 新機能リクエストの本来の目的は、ADBDが待ち受ける ネットワークインターフェースを開発者が選択 できるようにすること
- 背景には、Wireless ADBの認証手順を完全に回避できた CVE-2026-0073 がある
- 現在のADBDは、スマートフォンが接続されたすべてのネットワークからアクセス可能であり、インターフェース選択機能自体は露出範囲を減らせる
- しかし
wlan0のみ許可すると、次の構成が壊れる可能性がある- ループバックを使うオンデバイスADB
- VPN経由のADB
- Ethernet経由のADB
- その他の特殊な開発環境
- Android開発者自身も、コンピューターにアクセスできないときに オンデバイスADBを使用 した事例がある
悪意あるアプリが越えなければならない制約
- オンデバイスADBが権限昇格に使われる可能性はあるが、一般的な悪意あるアプリは 自力で接続を成立させられない
-
一般的なAndroidユーザー
- ADBが無効ならADBDは起動していない
- 悪意あるアプリには、ADB経由で手動付与が必要な
WRITE_SECURE_SETTINGS権限もないため、ADB攻撃を試みるのは難しい
-
Android 11以降でWireless ADBを使う開発者
- ユーザーがUSBデバッグとWireless ADBを自分で有効にして初めて、ADBDがネットワークインターフェースで待ち受ける
- アプリが接続するには、ユーザーが設定画面で 使い捨てペアリングコード を取得して渡す必要があり、アプリ単独では接続できない
-
ADB TCP/IPを使う開発者
- ユーザーがUSBデバッグを有効にし、USB ADBでTCP/IPを有効化した後にケーブルを外す必要がある
- アプリが接続を開始すると画面に承認ダイアログが表示され、ユーザーが No を選べば拒否される
- 正常な認証状態では、アプリがユーザーに気づかれず接続して攻撃することはできない
脆弱性リスクと遮断範囲
- 正常な状況では、悪意あるアプリはADBDを直接起動できないため、開発者がデバイス上でADBを使用中のときにのみ接続の可能性が生じる
- CVE-2026-0073のように認証を回避する脆弱性があれば、Wireless ADBやTCP/IP環境で悪用されうる
- それでもユーザーが先に USBデバッグを手動で有効化 している必要がある
- TCP/IP方式では、ユーザーがADB TCP/IPも自分で有効にしなければならない
- ループバック接続をデフォルトでブロックする措置と、ユーザーが解除できないよう恒久的に遮断する措置は区別すべき
- デバイス管理者指定やアクセシビリティ権限も、ユーザー操作によって悪意あるアプリに付与されうるが、その可能性だけで機能自体を廃止はしない
ユーザーの選択権を残す妥協案
- ループバック遮断は、ユーザーが明示的に解除できる 永続設定 であるべき
- 再起動後も維持されなければ、Shizukuのようなツールを実用的に使えない
- 可能ならサードパーティーアプリが設定状態を読めないようにし、銀行アプリやゲームの検出を避けるために繰り返し設定する必要がないようにすべき
- アプリに
WRITE_SECURE_SETTINGSを手動付与すれば、一部制約を回避できる
- ユーザーがセキュリティ機能を無効にしてオンデバイスデバッグを許可する一方、将来の脆弱性にさらされるリスクも受け入れる形が妥当
- オンデバイスADBを恒久的に遮断すると、次のようなニッチなオープンソースエコシステムに影響が及ぶ
2件のコメント
うわ…
Hacker Newsのコメント
セキュリティ改善にはおおむね賛成だが、これは実益がほとんどないように見える。この攻撃が成立するには、ユーザーが開発者向け設定とリモートADBの両方を有効にしている必要があるため、99.9%の人にとって現実的な攻撃経路ではなく、残りの0.1%はたいてい自分が何をしているか分かっている。
特定のインターフェースやIPにアクセスを制限する変更は良いが、開発者がlocalhostに制限できるようにすればよい。ShizukuやCantaなどを巻き添え被害に見せかけて封じようとしている印象が強い。
disable sandboxまで入力してもモバイルでは動かない。Firefoxでは署名されていない拡張機能をそもそもインストールできずDeveloper Editionが必要で、サイトはパスキーを強要し、S3バケット1つにも何十層ものアクセス制御・サービスID・IAM・OAuthが付く。ヘッドレス端末で動かないOAuth、TOTPではなく専用アプリを要求する銀行、VPNブロック、児童保護を名目にした実名監視、中国に情報が渡るとしてオープンウェイトモデルを禁止しようとする動きも続いている。
セキュリティは利便性・ユーザビリティ・プライバシー・改造可能性・オープン性より常に優先される絶対的価値になっており、ITセキュリティ業界はこれを恥じるべきだ。
今回の変更はユーザーのセキュリティではなく、企業の利害保護のために見える。
初期にはアプリストアなしでSafariだけを使えと言っていたし、がん治療中でさえデザインが美しくない医療機器が体に触れることを嫌がったという、Steve Jobs特有の偏執性が根源だったのだと思う。「完璧な」端末に「不潔な」ものが触れないようにしようとする態度を、死後にセキュリティという言葉で正当化したのだ。
当時はマルウェアだらけのWindows 98のような状況を避けるべきだと言われたが、現代のOSはすでに当時のWindowsの脆弱なセキュリティ水準をはるかに超えている。
Shizukuベースのroot不要プライバシーツールを封じる目的は、所有者ではなく政府のセキュリティのためだ。EU Digital Identity Walletのような信頼実行環境アプリケーションや、今後児童保護を名目に要求される機能は、ユーザーが端末を改変したり未承認ソフトウェアをインストールしたりできないという前提に大きく依存している。Intel SGXがどうなっているかは皆知っている。
ADB制限は当然の次の段階だ。この提案がそのまま通らなくても、Googleは普通のパーソナルコンピューティング作業でさえ、端末内部やUSB・無線の開発者インターフェースに依存せざるを得ないようにしてきた。
いつかは身元を差し出して年会費を払うか、Androidを意味のある形で使ううえで深刻な制限を受ける可能性が高い。Googleは管理された流通経路の外でAndroidアプリを開発してほしくないのであり、正当で合法的なサイドローディングを禁じる変更から後退しなかった時点で、すでに負けたも同然だ。
通話録音の警告もGoogleの責任だ。メーカー各社が、より優れていた独自ダイヤラーの代わりにGoogleダイヤラーを採用したことで、法的義務のない地域にも一律に適用された。特に、安定したサードパーティアプリによる録音をハードウェアレベルでサポートしないMediaTek SoCではなおさら厄介だ。
結局、「自分の」端末を所有できていないことの証拠であり、数年後には承認済みの監視経路を通じてGeminiが通話を聞き、要約してくれるのかもしれない。
正当な用途のための代替手段もあわせて提供されるのか気になる。機能を削除しながら代替を用意しなければ、開発者はより脆弱だったり、時にはルールに反したりする回避策へ追いやられる。
今回の反応は、誤解に基づく大きな過剰反応に見える。リモートADBで開発中のAndroidプロジェクトの新しいビルドをインストールし、ログを取得しており、現在はTailscale VPN経由で接続している。
しかし現状の方式では、接続するすべての公衆Wi-Fiで認証前の脆弱性まで露出する可能性がある。Tailscaleインターフェースだけに制限できるなら、むしろ改善だ。
提案の核心は、リモートADB設定時にすべてのインターフェースではなく、バインドするインターフェースを指定することだ。localhostが拒否されるという内容はなく、
wlan0だけにバインドしようという短い提案はVPNより信頼性が低く、明らかに間違っており、実際の実装方針でもないだろう。スレッドへの連投によってGoogle開発者がissueをロックし、フィードバックを無視したとしても、今と何も変わらない。批判そのものが気に障るなら価値あるフィードバックもロックできるのだから、自由に賛成の意思を表明すればよい。
Googleがアプリ開発者のフィードバックを時々受け取ることはあるが、こうした抜け道に依存するオープンソース開発者よりも、社内チームの判断を重視するのは当然だ。
ADBデーモンが、アプリからループバックアドレスへADBセッションを開いて通話録音を可能にするよう設計されたものではないのは明らかだ。https://xkcd.com/1172/をまた思い出す。
開発者が変更を嫌うことが間違っているという意味ではない。Googleもダイヤラーに通話録音を追加したので、その機能自体は支持しているが、だからといってADBチームがセキュリティ強化をすべきでないわけでもない。
Google がサイドローディング制限を最初に発表したとき、「それでも ADB がある」と言われ、それに反対した人たちは激しく批判された。
今や ADB を有効化する回避策まで待たなければならず、Android はずいぶん前から iOS よりオープンとは言えなくなっていた。この流れは続くだろう。
Google の考え方という非技術的な問題なので、技術的な解決策では解けない。
自分のソフトウェアをインストールできても、端末を「改変」したものとして扱われる。アテステーションに失敗すれば信頼されず、通信・銀行・ストリーミング・ゲームなど、デジタル社会のほぼあらゆる領域から排除される二級市民になる。
これが Android の未来であり、一部企業が奇跡的に GrapheneOS のアテステーションキーを信頼し始めたため、GrapheneOS が最後の希望になっている。その希望まで消えるなら、むしろ iPhone を買ったほうがよい。
当然起きることだった。次はサイドローディングの 24 時間制限が無期限になっても、人々は驚きそうだ。
市場全体を握る必要はなく、Google をためらわせたり、法的に実行しにくくしたりできる程度で十分だ。Chrome に対する Firefox の理想的な役割に近い。
Android がここまでロックダウンされるのは深刻な警告サインだ。Android を良いものにしていた要素を、ひとつずつゆっくり取り除いている。
近いうちにウェブサイトにも同じことが起きるのではないかと心配している。Apple 端末でサイトを開けるようにするには Apple に、Android 端末では Google に毎月料金を払わなければならない、という形になりかねない。
https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
まだ料金はないが、Google がかなりの数のウェブサイトについて、どの端末からのアクセスを許可するかを決められるようになる。
古いウェブのコンテンツは、AI 企業が大規模にスクレイピングした後、新しいウェブを通じて大衆向けに再生産する可能性も高い。
スマートフォン向け Linux が必要だ。銀行業務はブラウザでできるならアプリは不要だが、無線通信デバイスと Sonos・Spotify のような主要アプリは動かなければならない。
銀行・公共料金のような必須サービスには、正常に動作するウェブ環境を義務づける法律が必要だ。そうでなければ、現在の二強体制はさらに固定化される。
私自身も、ウェブサービスを提供する事業者を選んでもっと積極的に支持すべきだ。
postmarketOS の Wiki で互換端末を確認し、すでに持っている端末がサポートされているかを見て、可能ならサポート改善に貢献すればよい。そうでなければ、サポート状況の良い中古端末を eBay で探せる。
Librem 5 と PinePhone はサポートが良いほうだが、OnePlus 6T のような古い Android 端末のほうがコストパフォーマンスは良い場合がある。購入前に主要機能が動作するか確認する必要がある。
人気の Android アプリは Waydroid で実行できる。
代替手段の SMS 認証も安全ではないため消えつつあり、セキュリティ上は正しい方向だが、利用できるほかの手段が不足している。