Volkswagen、client assertion要件によりHome Assistantをブロック
(github.com/robinostlund)- Issue #967 は依然としてオープン状態で、関連項目として #971 と最新リリース
v5.4.7が表示されているが、提示された議論だけでは最終的に解決したかどうかは確認できない - 最初の報告では、Home Assistant の homeassistant-volkswagencarnet 認証の有効期限が切れた後、メールアドレスとパスワードによる再ログインができなくなり、Android アプリとブラウザでのログインは引き続き動作するという内容だった
- 再現手順はメールアドレスとパスワードの入力で、エラーメッセージは
Anmeldung bei Volkswagen Connect nicht möglich. Bitte überprüfe deine Zugangsdaten und stelle sicher, dass der Dienst verfügbar ist.と表示される - ある参加者は、これはバグではなく Volkswagen が APIを恒久的に無効化 した結果だと見ており、その後別の参加者は公式の有料 API と無料の非公式 API があり、後者はもはや動作しないと整理した
- 一部のユーザーは Web ログインは可能だが API とアプリが動作しない、またはアプリの応答が非常に遅いと報告し、別のユーザーは Android アプリへのログインは可能だが Home Assistant 再起動後に同じ問題が発生したと報告した
- CarConnectivity-plugin-mqtt が動作するという報告があったが、同じ API を使っているため既存設定はトークンの期限切れまでしか維持されず、新規ユーザーは動作しない可能性があるという反論が出た
- 別のユーザーは、CarConnectivity-plugin-mqtt を初めて使っても新しい認証トークンでデータを取得できたと報告しており、この代替手段の持続可能性は議論の中では確定していない
- Skoda EV Facebook フォーラムで関連する変更が共有されており、公式発表を見ていないという参加者は、この変更が VAGブランド全体 に影響する可能性があると見ている
- 代替手段として Smartcar と Tibber が挙げられ、Smartcar では車両データの流れと GDPR の適用有無が議論され、あるユーザーは Smartcar で「ひとまず動作」させられたとして wbyoung/smartcar#110のコメント を共有した
- Tibber は Home Assistant の標準 Tibber 統合で動作するという報告があったが、Tibber がエンタープライズ API アクセス費用を支払う構造であれば、料金を払わない新規ユーザーの流入を長く許容しないかもしれないという懸念が示された
- ある参加者は、Skoda の告知は金銭を要求するというより API 利用者が Volkswagen に登録しなければならないという意味だと解釈し、プロジェクト登録の有無を尋ねたが、メンテナーは Volkswagen 車両をもう保有していないため自らは進めていないと答えた
- メンテナーは、登録によってユーザーごとのキーが必要になる可能性があると見ており、調査とプロジェクト保守を手伝える人が必要だと要請しているため、解決の方向性はコミュニティ支援に依存したままとなっている
厳選された技術トピックを続けて受け取りたいですか？
Telegramチャンネルをフォローしてください。 @GeekNewsJP
1件のコメント
Hacker Newsのコメント
EU Data Act はまさにこういう状況を防ぐために作られたのではないかと思う。特に第4条と第5条が該当しそうだ: https://digital-strategy.ec.europa.eu/en/policies/data-act
ユーザーが接続製品や関連サービスのデータに直接アクセスできない場合、データ保有者は遅滞なく、ユーザーが容易に、安全に、無料で、構造化され、広く使われ、機械可読な形式で、必要かつ技術的に可能なときは継続的・リアルタイムでアクセスできるようにしなければならないとされている
車両データに関するEUの別個のガイダンスもある: https://digital-strategy.ec.europa.eu/en/library/guidance-ve...
ただし、GDPR第79条のように Volkswagen を直接相手取ってアクセス権を請求できる仕組みではなさそうだ: https://gdpr-info.eu/art-79-gdpr/
執行方法について書かれたものがあまりないので規則を直接見たが、第39条ではまず居住加盟国が指定した管轄当局に苦情を申し立てる必要があるようだ: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:...
その当局が何の措置も取らない場合、国内法に従って有効な司法救済、または専門性を備えた独立機関による審査を受ける権利が生じる
ただ、その場合の訴訟対象は企業ではなくその 管轄当局 になるようで、第39条3項がその点を明確にしている
私の解釈が間違っていてほしい
Muñoz vs. Superior Fruiticola 判決のように「その義務は民事手続で執行可能でなければならない」という理屈が適用される可能性はあるが確信はなく、GDPRが明示するルートよりはるかに弱い: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...
個人が Data Act をどう執行できるのか、もっと良い資料があれば知りたい
他のメーカーもかなり多くが同じことをしている
私は充電状態を取得するためにリバースエンジニアリングされた Polestar ライブラリ を使っているが、彼らが同じように塞がないと信じることはできないので、同じことを行う CANバススニファー を作っているところだ
これが本当に大きな収益源になるとも思えないし、製品に最も深く関わっている人たちを怒らせるのに、なぜそうするのかよく分からない
暗号化まで入るのは時間の問題に見える
私の考えでは、主に企業のリスク回避の問題だ
どこかの部署が些細なリスク一覧を並べたリスク評価書を書き、たとえばサードパーティ製アプリのバックエンドが侵害される可能性や、地方紙に「趣味開発者が Home Assistant に接続しようとして車をハックした」といった見出しが出る可能性を書く
その一覧が回覧され、どの中間管理職も責任を負いたがらず、公式に承認された前向きなユースケースもないため、厳しい対策が一つずつ企画されて実装される
IKEA はそこそこ良い例と言える
Bosch と Siemens の家電部門は、Home Connect プラットフォームを開くことを EU のデータ透明性・移植性規制への準拠の一部と見ているようだ
車載向け RISC-V で何が行われているかや、EU Cyber Resilience Act の要件を見れば分かる
BYD は私の車両接続リポジトリ全体に DMCA 要請 を送ってきた: https://github.com/github/dmca/blob/master/2026/05/2026-05-2...
プレミアム価格で買った車を自動車会社がロックし、オープンソース相手に十字軍のような戦いを仕掛けてくるのは本当に残念だ
公共の場所の鍵を玄関マットの下に置いて「ここに鍵あり」と書いておきながら、すでに公開されている場所にその鍵で入るなと文句を言うようなものだ
Codeberg を見てみたが、そこにはなかった
一方で、認証トークンを取得する公式な方法や、車を Home Assistant に接続する方法がないのであれば、それはサービスの欠陥と見るべきだ
r/opensource_legalaid
返答してデータアクセスを要求しよう
企業っぽい表現を人間の言葉に訳したコメントが本当に良い: https://github.com/robinostlund/homeassistant-volkswagencarn...
なぜ自分で自分の足を撃つのだろうか？ これが本当に意味のある収益源なのか？ 本当にセキュリティを高めるのか？
大多数のユーザーは気にせず、MySkodaで働くどこかの中間管理職は「大きなセキュリティリスクを防ぎ、価値ある~~家畜~~ユーザーデータをあるべき場所に戻しました」と報告できる
インフラ、サーバー、帯域幅には金がかかる
良くも悪くも、ほとんどの機器にはローカルインターフェースがない
この1〜2年でMatter対応機器は少し出てきたが、すべてのデータや機能がMatterで提供されるわけではなく、古い機器がMatter対応にアップデートされる可能性も低い
そのうえHAはローカル実行・ローカル中心のアプリなので、OEM側の追加開発なしにはクラウドベースのAPI/データ配信システムとうまく噛み合わない
最後に、内部システムで計算したところ、24時間のHAトラフィックが全体の約**20%**を占めていた一方で、ユーザー比率は1%未満だった
各インスタンスが数分おき、あるいはそれ以上の頻度でAPIを直接呼び出すからだ
役員がこの数字を聞けば、おそらく遮断しろと言うだろう
正しいかどうかとは別に、人はそう反応するものだ
年100ユーロ払う必要があったが、その当時は他のアプリや自動化から同じデータにアクセスできた
今ではすでに利用料を払っているのに、同じデータにアクセスするにはWeConnectとそのパートナーを必ず使わなければならない
平均的なユーザーはプライバシー保護にほとんど関心がなく、私たちは無感覚になるよう飼い慣らされてきた
これは実際に収益源であり、セキュリティを高めるものではない
ほとんどビジネスの法則のように、役員は会社の利益率よりも自分の権力を優先する
コーディングの外注がコスト削減につながらず、商業的にも惨事だったのに人気があった理由の一つがこれだ
その関係では、私たちと働く場合よりも役員たちのほうがはるかに運転席に座っていた
Home Assistantの消費者セグメントは「重要ではない」と言う人もいるが、実際には重要だ
それでも本質は、データへの統制という目に見える利益と、消費者の好感を失うという見えにくい損失の間の問題だ
会社は、どんな代償を払ってでも利益だけを最大化する存在ではない
株主と役員は単一の身体ではなく、互いに異なり、ときには大きく食い違う利害を持っている
Client AssertionはOAuthの機能だが、ここで議論されているのはまったくそれではない
混乱しやすいが、HNのタイトルにあるだけで元のページには出てこない
この場合、AndroidではPlay Protectがそれを担い、iOSでは向こうが使っている何らかの仕組みが担当している
Googleもこの件に一枚噛んでいるように見える: https://github.com/robinostlund/homeassistant-volkswagencarn...
最近、自分のガレージドアオープナーAPIであるMyQに直接アクセスしようとして、同じ壁にぶつかった
Googleがこうした振る舞いを可能にしていることがEU競争法にまったく違反しないのだとしたら驚きだ
最近のソフトウェアサプライチェーンの惨状を見ると、何かを接続しておくのはロシアンルーレットのように感じられる
何年もHome Assistantを使っている者として言っている
特に今は自分のEVはVolkswagenではないが、HAに接続するのはかなり危険な自爆行為のように思える
3か月前なら確かに便利だったのだろうが
スマートホームを長くやってきたが、これは私が Home Assistantを離れた理由 の一つでもある。
とても優れていて機能的なプロジェクトだが、企業がAPIを開放し続けること、あるいはもっとよくあるのは、リバースエンジニアリングされたAPIを可能にする抜け道を塞がないことに全面的に依存している。
残念ながら、この数年の流れはHAに不利だった。
Tesla、Ring、MyQ、EcobeeなどはAPIを閉じてきており、たいていは「セキュリティ上の懸念」を理由にしていた。
ある程度もっともな面はあるが、私の考えでは、たいていはサブスクリプション収益を失うかもしれないという恐れが動機だ。
Teslaは公式OAuthアプリに多額の料金を課している。
ただ、以前のハックは彼らが修正せず放置していた漏洩OAuthアプリに依存していたので、公平に見ればそういう面もある。
EcobeeはHomeKitと一部機能をSecurity+サブスクリプションの裏に隠したが、彼らのセキュリティ基盤の貧弱さを考えると冗談のような話だ。
MyQは明らかに年45ドルのサブスクリプションを守るためにそうしたのであり、RATGDOのほうがずっと優れているため、結局は自分たちが損をした形だ。
Ringはなぜかまだ動いているが、APIを切られるかもしれないという不安のせいで、HomeKit Secure Video対応は非常に不安定だ。
私のように主にHomeKit連携のためにHAを使っていた人間にとって、HAへの依存は 時限爆弾 だ。
新しい家に引っ越した際、回避策なしでHomeKitにネイティブ対応するものを探すことに注力したが、そのおかげで今ではスマートホームははるかにうまく動いている。
私も同じやり方でホームオートメーションを始めたし、HomeKit中心もかなり悪くはない。
次は、100%ローカル制御の機器を使ったHAがHomeKitへブリッジする構成を考えている。
HomeKit専用機器はWi‑Fiの安定性がひどいことが多く、最近のMatter/Threadの動きにももっと注意を払う必要がありそうだ。
Zigbee/Z-Waveに不満を言う人もいるが、平均的にはWi‑FiベースのHomeKitよりはるかに良かった。
正直、挙げられているものの中では、HAが 時限爆弾から最も遠い と思う。
次の車がSködaやVolkswagenになることは間違いなくない。
リモート証明 は、ルート証明書を誰が提供するかに関係なく、GoogleであれAppleであれGrapheneOSであれ、違法にする法律が必要だ。
現時点でこの技術の唯一の用途は、人々が自分の所有する機器でやりたいことをできなくし、相互運用性を暗号学的に不可能にすることだ。
反競争的なので、単純に違法であるべきだ。
しかし リモート証明 がさらに広がれば、どんなサービスも暗号学的に利用しにくくなり、平均的な消費者にとっては事実上無価値な機器になりかねない。
VWの幹部たちは、昔のように法律をねじ曲げられると思って気にしていない犯罪者にすぎない。
つまり、クラウドなしでも動作しなければならない。
あるいは、製品へのAPIアクセスを明示的に提供している製品や企業を選ぶべきだ。
自分が所有する装置を、望まない人が物理的にアクセスして認証情報を抜き出せる環境に配備する場合に使える。
人々が会社支給の装置でのみ機密性の高い会社情報にアクセスできるようにし、アクセス可能なデータを他所へ好き勝手にコピーできないようにするためにも必要だ。
携帯電話をカード決済端末として使う際に、画面にはある金額を表示しながら実際には別の金額を承認するといったことを防ぐためにも必要だ。
自分が所有するあらゆるものが生成するデータをオープンな形式で提供すべきだという点にはかなり強く賛成するが、証明に正当な用途がないと言うのは事実に反する。