Home Assistant、未承諾でユーザーのパスワードをスキャンされていると暴露

まず、日時を固定しましょう。10月16日（UTC）に、ユーザーのVissがHome Assistantのドキュメントリポジトリでissue #49314を開設しました。タイトルは「私の秘密をスキャンする権限を与えていない」で、システム内にある、ローカルに設定されたパスワード関連のフィールドをネットワーク経由でデータベースに照会する機能を指摘しています。メンテナーのfrenckはその夜、最初は反論し、その後2回issueを閉じましたが、態度は「アンインストールしてください」というレベルで硬かったです。20時33分に、このissueがHacker Newsに投稿され、すぐにトップページに上がりました。10月17日の朝までには、150以上のサポート票と100以上のコメントがあり、まだ増加しています。21時11分、つまり最初のレビューから116分後、frenckはトップに表示される長文の謝罪を投稿し、以前の返信が軽薄だったことを認め、ドキュメントには書かれていなかった閉じるコマンドを提供しました。48時間の期間は10月16日から10月18日までで、この記事はその期間内に書かれています。前提条件を固定しましょう：Viss、frenck、そして後に登場する評論家たちの身元は、自己申告またはネットユーザーの指摘によるものです。身元を明かす際には限定を付けます。原文を引用する場合は直接引用できます。なぜならissueとHNは公開記録だからです。以下のタイムスタンプはすべてissue #49314とHNからのものです。

何が起こったの？

この機能自体は古くから存在するものです。frenckが謝罪コメントで明かしたように、このチェック機能はSupervisorに何年も前から存在しており、その仕組みはadd-onの設定内で「password」とマークされたフィールドをスキャンし、ローカルでSHA-1ハッシュを計算し、ハッシュ結果の最初の5文字だけをHave I Been Pwned（HIBP）というパスワード検索サービスに送信します。HIBPは同じプレフィックスを持つハッシュのリストを返し、最終的にはローカルで完全な比較が行われます。このメカニズムはK-anonymityと呼ばれ、パスワードの原文や完全なハッシュはローカルから出ません。1Password、Chrome、Firefoxも同じ仕組みを使用しており、HAの公式ドキュメントにもその内容が記載されています。さらに詳しく言うと、ローカルでSHA-1を計算した後、最初の5つの16進数文字、つまり約20ビットを取得し、このプレフィックスをHIBPのrange APIで検索します。HIBPはそのプレフィックスに対応するすべてのハッシュを返し、通常は数百件です。最終的にローカルで完全な比較が行われます。HIBPが受け取るのは単なるプレフィックスであり、どのパスワードかを逆転させることはできず、どのデバイスからのものかも逆転させることはできません。この機能は暗号学的には問題ありませんし、ドキュメントにもそのことを記載しています。問題はメカニズムにあるのではありません。

問題は、ユーザーの側の体感にあります。Vissは2026年10月1日のバージョンで初めて「私の秘密をスキャン中」という警告を見ました。彼の判断では、自分はこれまでその機能に同意したことがないということです。彼の要望は、この機能をopt-in方式に変更し、まず同意を得てからスキャンするようにすることです。なぜ古い機能が今になって問題になるのでしょうか？frenckは謝罪コメントでその理由を説明しています：最近のバージョンで、この警告が現れる原因となったバグが修正されました。古いユーザーにとっては、これが初めて見る警告です。

次に、その夜のアップグレードリンクです。すべてタイムスタンプ付きです。19時15分、frenckが最初の評価を投稿し、「Oh hi there 👋」という文で「これはプライバシー侵害ではない」と述べ、1Passwordを例に挙げて他のソフトウェアも同じことをしていると説明しました。また、CloudflareのK-anonymityブログとウィキペディアのリンクを添付しました。最後には「言うべきことは、この出力から何かを学ぶべきだ。なぜなら、あなたが使っているこれらの秘密はすでに漏洩データベースにあり、簡単に利用される可能性があるからだ」と書き加えました。19時48分、Vissが自己紹介をして反論し、自分がPhobos Groupを運営しており、常にセキュリティ講演を行っていること、HIBPの作者Troyを知っていること、2011年にTwitterで唯一のレッドチームメンバーとして1Passwordを使用したことを述べました（以上は自己紹介であり、独立して確認していません）。彼の核心的な主張は変わっていません：これはopt-in機能であるべきであり、「ただ起こっただけ」ではない；レッドチームメンバーとして、彼はこのチャネルを利用して世界中のHAに保存されているクレデターを入手する方法をたくさん挙げました。19時56分、frenckは「This issue is closed as won’t fix. Sorry.」という文を残し、問題は解決されました。

20時12分、古参ユーザー0x00stringが再開要求を送信し、「もし合理的な対応ができない場合は、はっきり言ってください。そうすればアンインストールして別の分支を始めます」と述べました。20時14分、frenckが2回目の閉鎖通知を送信し、相手が「脅迫や恐喝を行っている」と指摘し、「これだけでアンインストールやforkを行うのに十分だ……🤷 それなら好きにしてください。とにかくこれはオープンソースのソフトウェアです」と述べました。20時33分、この件がHNに掲載されました。21時11分、frenckのトップページに謝罪コメントが投稿され、ha security options --pwned=falseというコマンドで閉鎖を指示し、「実際にはこのチェックはすでにオフにできていました」と認めました。最終的にこの件は「Closed」となり、frenckがそれをリポジトリのトップに掲載しました。

批判的な側面：仕組みは問題ないが、治理には問題がある

第一条主要なポイントは権限付与です。機能はデフォルトで有効であり、トリガーされるのはすべてadd-on設定の中で「password」とマークされているフィールドです。ユーザー自身がどの設定がこのカテゴリーに含まれるかを正確に把握しているわけではありません。データフローはハッシュプレフィックスのみを送信しますが、送信先は結局第三者サービスです。また、警告文は今回のバージョンアップデート前には全く明らかになっていませんでした。デフォルトでopt-out、警告なし、第三者データフローという3つの要素が組み合わさることで、Vissが実際に不満を抱いている点が生じます。彼が示した理論的な攻撃ポイントもこのレベルにあります：彼のissueの言葉によれば、HAリポジトリの悪意ある行為者はこのメカニズムを利用して悪さをする可能性があります。これはissueの著者が指摘した理論的な攻撃ポイントであり、既に確認された脆弱性ではありませんので、この記事ではそれを重大な問題とは扱いません。

第二条の主な理由は、矛盾した閉じる理由です。issueをドキュメント倉庫に置くのは、スイッチがドキュメントに記載されていないからであり、ドキュメント倉庫に持っていくのが当然のことです。HNのコメント者mcmcmcは、この点を突き止めました：この機能を閉じるためのオプションは本来存在しているだけで、ドキュメント化されていないだけです。だから、ドキュメント倉庫こそがissueを開く適切な場所なのです。しかし、メンテナーが「これはドキュメント倉庫であり、ドキュメントを変更しても機能の問題は解決しない」という姿勢でこの機能を閉じるのは、論理的に成り立ちません。

第三条主线は、応答の方法が議題を変えてしまったことです。Vissの主張は治理の誤りであるというものですが、frenckの最初の評価では1Passwordを例に挙げて、「他の人も同じことをしている」という話題に持っていきました。HNの高評価コメント者jackpepsiの皮肉は非常に代表的です。「今回の無断スキャンが侮辱的だと感じるかもしれませんが、私たちは数学で、私たちがあなたを侮辱していないことを証明できます。」技術的に間違っていなくても、プログラム上で許可されていないというのは別のことです。最初の評価では前者だけに答えています。

言動監査：116分間の四つの顔

その夜の発言を順番に並べれば、それはすぐ使える言動監査資料になります。19時15分、「これはプライバシーの侵害ではない」と、リンクを添えて自白します。19時56分、「修正できない、ごめんなさい」と、問題を終了させます。20時14分、「脅迫は無駄だ」「フォークをアンインストールしてもらう、とにかくオープンソースだ」と、二度目に問題を終了させます。21時11分、「私の以前の返答は、この件に対してふさわしいものよりも軽蔑的だった、謝罪する」と、スイッチや開示メカニズム、発生原因の説明、ソースコードのリンクを提供します（このコメントはページで切れており、ソースコードの具体的なパスは本稿では完全には確認していないため、記載しません）。4つの異なる発言者の間には116分しか隔たりがなく、その間に起こったことは1つだけ：HNが38分間発酵しました。

謝罪の評価は、記録に値するものです。なぜなら、提供される追加情報が多いからです：メカニズムの詳細、発生原因、閉鎖命令など、これらは前の2回の回答では得られなかった情報です。つまり、ユーザーが最初の段階で明確に知りたかったことに対して、メンテナーは実際に答えることができましたが、先に閉鎖を選択しただけです。

旧帳も翻訳されました。HNのコメント者であるjanice1999とsomeguydaveは、frenckが数年前にNixOSのnixpkgs PR #126326の論争で同じ「変更するかどうかは自由に決めてください」という態度を取っていたと指摘しています。これを彼の一貫したコミュニケーションスタイルだと考えています。赤線で示されているように、これはネットユーザーの指摘であり、本記事ではその意見を記録します。また、別のコメント者であるhypferは、旧帳を翻訳することは悪意があると考えるため、それも記録しています。

また、GDPRの問題もあります。コメンテーターのRygianは、この統合がEUでGDPRに違反する可能性があると推測しています。その理由は「合法的な根拠なくPIIを収集する」という点です。一方、deadbunny、Matticus_Rex、nicceは、送信されるのはハッシュプレフィックスだけであり、PIIには該当しないと反論しています。賛否両論がありますので、この記事では結論を出しません。

コメント欄はどう言うのですか？

HNの100件以上のコメントの中で、上記で挙げたいくつかの意見以外にも、記録に値する声がいくつかあります。

建設的な対比：あるネットユーザーがHAの創始者balloobの登場を指摘し、この機能は既に5年間存在しており、関連するドキュメントのリンクも添付されていると述べています。また、プライバシー学者であるcsoghoianは、その機能を実装するよりもPasskeyのサポートを追加する方が良いと提案しています。彼によると、ユーザーは長い間その機能を求めており、パッチも提案していたが、却下されていたとのことです。どちらの身分も独立して確認されていないため、ネットユーザーの述べる通りに扱います。

信頼コストは常に目立つ問題です。コメントを寄せたonionisafruitとfg137は、HA Greenのハードウェアを購入しようとしているが、そのことで躊躇していると述べています。彼らが躊躇する理由は、「haveibeenpwnedにハッシュを送ることではなく、GitHubでの対応を受けたこと」だと強調しています。オープンソースプロジェクトのコミュニケーション姿勢が、ハードウェアの注文の躊躇に直接影響しているのです。これがコミュニティの信頼コストの最も具体的な形です。

反対意見にも配慮する必要があります。コメントをしたragallは、開発者の返答が非常に合理的で控えめだと評価していますが、一方でユーザーの態度は無礼だと指摘しています。altairprimeは、自意識過剰な反対意見の中で、断固としたソフトウェア制作者の価値が低下していると同情しています。これらの意見は主线の主張とは異なりますが、それでもこれらはこの議論の真実の一部ですので、本稿では省略しません。

一般のユーザーができる3つのこと

まず、HAを使用していて、スキャンされるのを避けたい場合は、そのオプションを無効にしてください。コマンドはha security options --pwned=falseです。これはメンテナー自身が投稿した謝罪の投稿から来ており、信頼性については議論がありません。また、このオプションは以前はドキュメントにはなかったので、検索できないということは、存在しないという意味ではありません。

第二に、この機会に自分のパスワード設定を確認することが重要です。この警告は怖いかもしれませんが、実際には有用なことをしてくれます。つまり、すべてのadd-on設定の中で「password」とマークされている項目をHIBPで一通りチェックすることです。Frenckの最初の評価では、態度はさておき、内容は正しいです。漏洩したパスワードは交換するべきです。弱いパスワードを交換する方が、交換すべきかどうかを議論するよりも有益です。

第三に、メンテナーの対応態度を選択の指標と考えることです。この事件では、機能自体が安全であり、ドキュメントもあるにもかかわらず、ユーザーを動揺させたのは、issueが2回にわたって強制的に閉じられた過程でした。家庭データを扱うオープンソースプロジェクトを評価する際には、そのissueの閉じ方や表現を見てみるべきです。そこに隠されたガバナンス文化は、READMEよりも正直です。

結論

分寸をわきまえた声明：本記事では、どちらの当事者も有罪とはしていません。Viss、balloob、csoghoianの身元は、本人が自ら名乗ったものか、ネットユーザーが指摘したものです。本文には制限が設けられています。frenckはMemberとして応答しており、これを公式の応答と呼ぶことができます。理論的な攻撃については、issueの著者の意見を引用していますが、既存の欠陥については記述していません。GDPRに関する違法性の議論は、コメント欄での推測に過ぎず、賛否両論で記載されています。謝罪文の中のソースコードのパスは、ページの切り抜きにより完全には確認できていないため、明確に記述していません。NixOSに関する過去の問題は、ネットユーザーの指摘に基づいて記録されています。確認された事実は、issue #49314の全過程のタイムスタンプ、4つの重要なフレーズ、閉鎖命令、K-anonymityメカニズムと公式文書の内容、HNのデータ配布（10月17日の午前のスナップショットで150以上の支持票がある）、これらはすべてGitHub issueとHNから直接得られたものです。注目すべき点は2つあります。1つ目は、HAが閉鎖スイッチとメカニズムの説明をドキュメントに追加しているかどうかです。そうすれば、次のユーザーはissueを調べることなく、自分がこの問題に関与している権利があることを知ることができます。2つ目は、機能がVissが求めるようにopt-in形式になっているか、または少なくとも警告文に閉鎖の手順を示しているかどうかです。いずれかが実現されれば、v2がリリースされます。

参照情報

• GitHub issue #49314（home-assistant/home-assistant.io）：出典はここです。本文のタイムスタンプと出典情報は以下の通りです：2026-10-16に開始、最終状態はClosedです。frenckはトップページに置かれています。
• HN story 50124251：2026-10-16 20:33 UTCに投稿され、10-17の午前中のスナップショット155▲/104💬が記録されています。本文では「150以上の支持票があり、数は増え続けている」と述べられています。コメントを投稿したmcmcmc/jackpepsi/Rygian/deadbunny/Matticus_Rex/nicce/onionisafruit/fg137/balloob/csoghoian/ragall/altairprime/janice1999/someguydave/hypferは、それぞれ投稿者自身の情報です。
• HA公式ドキュメント more-info/pwned-passwordsページ：K-anonymityメカニズムの公式説明があり、全文を確認できます。
• Cloudflareブログvalidating-leaked-passwords-with-k-anonymity：frenckが最初に評価を行い、同じメカニズムが業界で一般的であることを証明しています。
• frenckのトップページへの謝罪コメント：issue内で、2026-10-16 21:11 UTCに閉鎖命令とメカニズムの出典が明らかにされています。コメントはページで切り捨てられており、ソースコードのリンク経路は完全には確認されていません。