Home AssistantのPwned-Passwordチェック：GitHubのIssue、オプトアウトコマンド、そしてプライバシー論争
Home AssistantのSupervisorは、パスワードとしてマークされたアプリオプションを、Have I Been Pwned（HIBP）の侵害データベースと照合してきました。これは、ローカルで計算されたSHA-1ハッシュの最初の5文字のみを送信するk-匿名性スキームを使用して、長年にわたって静かに行われてきました。2026年10月、「I never authorized an integration that scans my secrets」というタイトルのGitHub Issueが、この長年の動作を、同意、オプトインのデフォルト、メンテナーのトーンに関する公開の争いに変え、最終的にメンテナーの謝罪と、チェックがすでに無効化できるという開示で終わりました。
Home Assistantが実際にHave I Been Pwnedに送信するもの
Home AssistantのSupervisorは、パスワード値をローカルでハッシュ化し、SHA-1ハッシュの最初の5文字のみをHave I Been Pwnedに送信します。返されたハッシュリストとの照合はユーザー自身のインスタンスで行われるため、完全なパスワードと完全なハッシュがシステムから出ることはありません。
メンテナーのFranck Nijhof（GitHubハンドル frenck）は、Issueへのフォローアップでこのメカニズムを説明しました：
プライバシーはこの機能の設計要件でした。だからこそ、あなたの秘密がシステムから出ることはありません。Supervisorはそれらをローカルでハッシュ化し、SHA-1ハッシュの最初の5文字のみをHave I Been Pwnedに送信します。HIBPはそのプレフィックスで始まるすべてのハッシュを返し、照合はあなた自身のインスタンスで行われます。
彼は読者を実装 https://github.com/home-assistant/supervisor/blob/main/supervisor/utils/pwned.py に案内しました。
これは、Cloudflareが漏洩したパスワードの検証のために文書化し、Wikipediaでk-匿名性として説明されているのと同じk-匿名性アプローチです。両方のリンクが元のGitHubスレッドで引用されていました。
pwned-passwordチェックを無効にする方法
チェックはコマンドラインから無効化できます：
ha security options --pwned=false
このコマンドは、Issueが提出された時点では文書化されていませんでした。Nijhofはそのギャップを認めました：「あなたは正しいです。私たちのドキュメントはこれを説明すべきでした。無効化する方法も含めて。そのページを更新します。」
影響を受ける人と受けていない人
スキャン動作はSupervisorにあり、Home Assistant Coreにはありません。Hacker Newsのコメンター（gcommer）は、自己ホスト型コンテナでHome Assistant Coreを実行しているユーザーは影響を受けないと指摘しました。関連するSupervisorサービスは、Home Assistant OSとHome Assistant Supervisedインストールの一部にすぎないためです。
GitHub Issue：報告された内容と理由
Issueは、home-assistant/home-assistant.io ドキュメントリポジトリに、GitHubユーザー Viss によって、Home Assistantバージョン2026.10.1に対して提出されました。報告者は次のように書きました：
これはかなり深刻なプライバシー侵害です。私は、シークレットをスキャンして送信するための統合やプラグインを決して承認していません。たとえハッシュ化されていても、されていなくてもです。このメカニズムは、home assistantのgithubリポジトリにアクセスできる悪意のある脅威アクターによって、さまざまな方法で悪用される可能性があります。
提案された解決策は、「これをオプトイン機能にしてください。存在を知らされていないシステムでシークレットをスキャンするように人々をオプトインさせないでください」というものでした。
報告者の背景は論争に関連しています。Viss は、Phobos Groupを運営し、国際的にセキュリティプレゼンテーションを行い、「HIBPに非常に精通しており」、HIBPの創設者Troy Huntに会ったことがあり、2011年にTwitterで1Passwordの展開を唯一のレッドチームスタッフとして支援したと述べました。彼は付け加えました：「レッドチーマーとして、これを悪用して地球上のすべてのHAインストールから資格情報を奪う方法を、腕の長さほどのリストであげることができます。」
メンテナーの最初の応答とエスカレーション
Nijhofの最初の返信は、その枠組みを完全に拒否しました：
これはプライバシー侵害ではありません。他にもこれをやっているアプリは確かにあります（最も顕著なのは1Passwordパスワードマネージャーです）。あなたのパスワードが送信されることは決してなく、公開されることもありません。
彼はまた書きました：「むしろ、出力から学んでください。あなたが使用しているシークレットはパスワードデータベースにリストされており、簡単に『ハッキング』可能だからです。」
別の長年のユーザー 0x00string が、Issueの再オープンとチェックを無効化する文書化された方法を求めたとき、やり取りはエスカレーションしました：「これに合理的に対処する気がないなら、アンインストールしてフォークできるように知らせてください。」
Nijhofは応答しました：
申し訳ありませんが、これらは私たちが対応できる声明ではありません。そのような脅迫や威嚇はどこにも行き着きません。機能リクエストをしたいのであれば、それ用の場所があります。
彼は報告を「won't fix」としてクローズし、ドキュメントリポジトリに対して提出されたこと、そして「これを調整または対処するために調整できるドキュメントの量はありません」と述べました。
スレッドはその後、「加熱しすぎ」としてロックされ、2026年10月16日にコラボレーターに限定されました。
フォローアップの謝罪と訂正
Nijhofは後に同じIssueにフォローアップを投稿し、以前の返信のトーンについて謝罪し、オプトアウトに関する記録を訂正しました：
このリポジトリはドキュメント用なので、これはクローズのままにしますが、フォローアップしたいと思います。私の以前の返信は、これに値するよりも軽率でした。お詫び申し上げます。
彼はまた、タイムラインを明確にしました：チェックは「新しいものではなく、Supervisorの一部として何年も前からあります。パスワードとしてマークされたアプリオプションをチェックします。最近のリリースで、それを表面化する警告が修正されました。だから今それを見ているのです。」
機能を支持するプライバシー論：k-匿名性
チェックの背後にある設計意図は、パスワードが公開された侵害コーパスにすでに存在する場合にユーザーに警告することです。5文字のハッシュプレフィックスのみが送信されるため、サービスはユーザーがどの特定のパスワードを保持しているかを判断できません。返される候補セットは、曖昧さを保つのに十分な大きさです。これは、パスワード侵害チェックにおけるk-匿名性の標準的な議論であり、メンテナーがこの動作を1Passwordのものと比較した理由です。
反対するプライバシー論：同意と最小驚愕の原則
批評家は暗号化に異議を唱えませんでした。彼らはデフォルトに異議を唱えました。最も多く投票されたHacker Newsのコメント（eranation から）は、意見の相違を一連の質問として組み立てました：
パスワードマネージャーは、オプトインなしで何も送信せずに、再利用されたパスワードについて警告すべきですか？はい。パスワードマネージャーは、良い意図と数学的に「安全」であることが証明されているかどうかに関係なく、オプトインなしで私のデータの1バイトでもサービスに送信すべきですか？私はノーと言います。スマートホームマネージャーやトースターなど、他の製品が、オプトインなしで、ハッシュ化されているかどうかに関係なく、私のデータを第三者に送信すべきですか？たとえそれが「donothing.com」というページへの「1」というバイトだけでも？私は絶対にノーと言います。
そのコメントはまた、フォークの脅威に対するNijhofの反論を擁護しました：「私たちは皆、熱くなった瞬間に後で後悔する返信を書くことがあります」と結論付けながら、「いかなる種類のホームコールも最小驚愕の原則に違反しています。」
別のコメンター thunderfork は反対の見解を取りました：「つまり、これらはすでにh-aに与えられ、ハッシュ化され、ハッシュの最初の5文字だけが送信されるシークレットですか？ええ、私はメンテナーに同意します。これは実際の問題に対する怒りの劇場のように思えますね？」
Arcuru は同じ技術的な質問を直接提起しました：「この機能はオプトインであるべきですが、これがセキュリティ上の懸念である理由を誰か説明できますか？パスワードのsha256の最初の5桁を共有することが実際のセキュリティリスクになるとは理解できません。」
議論で提起された法的問題
Hacker Newsのコメンター Rygian は、この統合がヨーロッパでコンプライアンス問題を引き起こす可能性があると主張しました：「この統合がGDPRのためにEUで完全に違法であるとしても驚かないでしょう。HIBPが法的正当性なしにPIIを摂取することで問題になる可能性があります。」同じコメンターは最初の返信を批判しました：「最初の返信が『これはプライバシー侵害ではありません』というのは、プライバシー問題に関する無能さを示しています。それは決して有効な答えではありません。」スレッドでは法的な決定は下されませんでした。
Hacker Newsでのコミュニティの反応
このストーリーはHacker Newsで177ポイントと131コメントに達しました。反応は3つの線に分かれました：k-匿名性の技術的健全性、プライバシー重視のプロジェクトにおけるオプトアウトデフォルトの適切性、そしてメンテナーの応答のトーンです。
何人かのコメンターは、機能自体ではなくトーンとプロセスに焦点を当てました。interf4ce は、メンテナーがクローズした理由（コードリポジトリではなくドキュメントリポジトリに提出された）は「理解できる」が、「もう少し親切で、OPを正しいリポジトリに直接案内するのにそれほど労力はかからなかっただろう」と述べました。Cameri は「開発者は自己中心的に見えます...彼自身がそのトーンで引き起こしたのに、それを加熱しすぎと呼んでいます」と書きました。onionisafruit は、Home Assistant Greenを購入しようとしていたと述べ、「haveibeenpwnedにハッシュを送信することではなく、githubでのこの応答について」の一時停止であると書きました。
他の人々はメンテナーの直接性を擁護しました。altairprime は「決断力のあるソフトウェアクリエイターは、権利を主張する意見の相違の群れにはるかに受け入れられにくいが、その同じ決断力が最高のソフトウェアを作る」と書き、スレッドを「コメディファルス」と表現しました。TZubiri はフォークコメントの脅威という特徴づけに反論しました：「ユーザーがソフトウェアの使用をやめることができることを開発者に知らせることは、不適切でも『脅威』でもないと思います。」
abletonlive は謝罪が反応的だったと示唆しました：「この場合、frenckはHNのフロントページに載っていることに気づき、熱を望まなかったために間違いなく後退しました。」
あるコメンター speerer は観察しました：「AIの応答が人間が書いたものよりも改善されていた珍しい機会です。」
あるコメンターはまた、Nijhofを無関係な以前の論争（NixOS nixpkgs リポジトリのプルリクエスト126326）にリンクし、2021年のHacker Newsの議論へのポインタを提供しました。
Home Assistantが次に何をするかと言ったこと
Issueは、ドキュメントリポジトリに対して提出されたため、クローズのままです。メンテナーのフォローアップからの具体的なコミットメントは次のとおりです：pwned-passwords機能のドキュメントページが更新され、メカニズムと無効化方法が説明されます。また、動作をオプトインに変更したいユーザーは、docsリポジトリではなく、Home Assistantの通常の機能リクエストチャネルを通じて機能リクエストを提出するよう指示されました。
Home Assistant OSおよびSupervisedユーザーへの機能的な要点は、チェックがすでにオプションであることです。ha security options --pwned=false で今日無効化できます。