DevuanマシンIDパッチ-問題を解決するか、煙を吹きますか？
SlashDotで報告 として、Devuanは最近、次の description を含むパッチを導入しました。
数日前、Devuan ASCII 2.1が発表され、1つの更新がほとんどのメディアアウトレットで見落とされてきました。起動ごとにmachine-idを再生成するdbusパッチです。
このパッチはすべての人のプライバシーにとって重要であり、Debianは言うまでもなく、より多くのディストリビューションが私たちの例に従うことを願っています。私たちは重要なプライバシーへの影響を扱っています：同意のないユーザー追跡は多くの国で違法であり、これまでのところmachine-idのドキュメントで言及されていません。
したがって、パッチが行うことは、OSの再インストールの間の期間ではなく、再起動の間の期間にマシントラッキングを制限することです。
これが解決しようとしている問題をどのように解決するのか、私にはよくわかりません。せいぜい、それはそれを軽減します。ただし、ネットワーク上でD-Busを実行するときにmachine-idを使用するという全体的な考えが一貫してマシンを自己識別している場合、プライバシーの問題はD-Bus自体にあるようで、この「jerry-rigging」パッチそれに対処する奇妙な方法のようです。
誰かがここで理論的根拠を説明できますか？
私が理解しているように、理論的根拠は
- machine-idは誰でも読み取り可能です（「world」の値によっては、コンピューター上のプロセスを意味し、デフォルトでは公開されません）。
- 一部の人々は、それが潜在的に悪意のあるプログラム（Chromiumを含む）によって読み取られていると報告しています。
- 重要なものには必要ないようです（少なくとも、安定した値を含める必要はありません）。
- 少なくともデブアンでは、起動のたびに生成しても何も壊れないように見え、マシンの識別可能な表面が減少するため、実行できる可能性があります。
ディスカッション ここからメーリングリストで開始 および ここではIRCで 。
すべての主張が正確であるか、少なくともすべてがすべてのディストリビューションに適用されるかはわかりません。しかし Adam Borowskiが言う 、
問題についてのどんな考えも評価されますが、インとアウトに関する具体的な洞察ははるかに有用だと思います（読んでください：そのことについての役に立たない無知の炎を避けてください：P）。
現実的であること...情報のない炎を避けることは私たちのルールに反するでしょう:)
Chromiumはマシン識別子 トークンストレージ用 を使用しますが、私が知る限り、それは外部に公開されません（少なくとも、- the machine-idドキュメント ）。マシンIDの変更がChromiumにどのような影響を与えるかはわかりません。 Debianアーカイブでは、すべてのソースコードを検索できます： "machine-id" および sd_id128 特に危険と思われるものは何も表示しません（つまり、将来のある時点ではあり得ないでしょう）。
Systemdベースのシステムでは、マシン識別子を変更すると1つの結果が生じます。journaldは、ログを格納するためにそれに依存しています（/var/log/journalを参照）。皮肉なことに、systemdベースのディストリビューションは、マシンIDを非常に簡単に変更するように設定できます。/var/lib/dbus/machine-idおよび/etc/machine-idが空であるか、起動時に見つからない場合、マシンIDが再生成されます。
D-Busは、実際にはコンピュータとローカルの通信にのみ使用されます（ただし、理論的にはリモート通信がサポートされています）。マシンIDはリモートで集中ログに役立ちますが、これは主にsystemdを実行しているシステム、または管理者がマシンIDをIDとして具体的に使用するセットアップでの問題です。後者の場合、管理者は選択を上書きすることもできます。配布が行います。
D-Busのドキュメント は、Devuanに実装されているさまざまなマシン識別子を明示的に許可しています。
このUUIDは、少なくともそのシステムが次にリブートするまで、単一システム上のすべてのプロセスで同じでなければなりません。可能であれば再起動後も同じである必要がありますが、これは常に実装できるとは限らず、保証されません。
（「このUUID」はマシンIDです。）
JdeBPには トピックに関するページ があり、詳細情報があります。