〜のようにSlashDotレポート、Devuanは最近パッチをリリースし、内容は次のとおりです。説明する:
Devuan ASCII 2.1は数日前にリリースされましたが、ほとんどのメディアで無視されたアップデートが1つありました。すぐに起動するたびにシステムIDを再生成するdbusパッチでした。
このパッチはすべての人のプライバシーに関するものなので、Debian はもちろん、より多くのディストリビューションが私たちの例に従うことを願っています。私たちは、重要なプライバシーの問題に取り組んでいます。同意のないユーザートラッキングは多くの国で違法であり、これまではMachine ID文書にも言及されていません。
したがって、パッチは、オペレーティングシステムの再インストール間の期間ではなく、再起動間の期間にシステムトレースを制限します。
私はこれが解決しようとしている問題をどのように解決するのかよくわかりません。せいぜい安心です。ただし、ネットワークでD-Busを使用するときにコンピュータIDを使用するという考えが常にコンピュータを自己識別することである場合、プライバシーの問題はD-Bus自体にあるようです。奇妙な解決策のようです。
誰かがここで原則を説明できますか？
ベストアンサー1
私が知る限り、その理由は次のとおりです。
- machine-idは誰でも読むことができます（「world」のいくつかの値の場合、これはシステム内のすべてのプロセスを意味し、デフォルトでは公開されません）。
- 一部の人々は、Chromiumを含む潜在的に悪意のあるプログラムでこのコンテンツを読んでいると報告しています。
- 重要なことは何も必要ないようです（または少なくとも安定した値を含める必要はありません）。
- 少なくともDebuanでは起動するたびにスポーンしても問題はないようで、マシンの認識可能な表面も減るので、そうする方が良いでしょう。
議論するここでメーリングリストから始めましょうとIRCから。
すべてのステートメントが正しいかどうか、または少なくともすべてのディストリビューションに適用されるかどうかはわかりません。アダム・ボロスキー(Adam Borowski)、
この問題に対するどんな考えでも感謝していますが、内容に関する具体的な洞察がより役に立つと思います。 （読む：この問題について役に立たない無知の炎を避けるようにしてください：P）
現実的に考えてみましょう...無知の炎を避けることは私たちの規則に反することです:)
Chromium は機械識別子を使用します。トークンを保管するため、私が知っている限り、外部には公開されません（少なくとも私が提案したように保護することはありません）。machine-id出荷書類ビーチ）。コンピュータIDの変更がChromiumにどのように影響するかわかりません。 Debian アーカイブでは、すべてのソースコードを検索できます。"machine-id"そしてsd_id128特に危険に見える他のものは表示しないでください。だからといって、将来の特定の時点でそのようなことが起こらないという意味ではありません。
systemdベースのシステムでシステム識別子を変更すると、journaldログの保存に依存するという1つの結果が発生します（参考資料を参照/var/log/journal）。皮肉なことに、systemdベースのディストリビューションはシステム識別子を非常に簡単に変更できます。起動時/var/lib/dbus/machine-idと/etc/machine-id空白または欠落している場合は、システム識別子が再生成されます。
D-Busは実際にはローカルコンピュータ通信用に設計されています（リモート通信は理論的にはサポートされていますが）。マシン識別子はリモート集中型ロギングに役立ちますが、これは主にsystemdを実行しているシステムまたは管理者がマシンIDを識別子として排他的に使用する設定で問題になります。後者の場合、管理者は展開を上書きします。
Dバス文書Devuanに実装されているさまざまな機械識別子の使用を明示的に許可します。
このUUIDは、少なくとも次にシステムを再起動するまで、単一システム内のすべてのプロセスで同じでなければなりません。可能であれば、再起動後も同じでなければなりませんが、必ずしも可能ではなく、保証できません。
（「This UUID」はコンピュータIDです。）
JdeBPはこのトピックに関するページより多くの情報があります。