4 ms·
First I thought reading /etc/machine-id would be expected if Chrome uses D-bus or pulseaudio libraries which depend on D-bus, and /etc/machine-id is part of D-b
by xfs 7y ago
First I thought reading /etc/machine-id would be expected if Chrome uses D-bus or pulseaudio libraries which depend on D-bus, and /etc/machine-id is part of D-bus. But no, they really use it for tracking purposes.
And in a sick twist they have this comment for it:
std::string BrowserDMTokenStorageLinux::InitClientId() {
// The client ID is derived from /etc/machine-id
// (https://www.freedesktop.org/software/systemd/man/machine-id.html). As per
// guidelines, this ID must not be transmitted outside of the machine, which
// is why we hash it first and then encode it in base64 before transmitting
// it.
- chias 7y agoIn fairness, the guidelines they reference suggest you do exactly what the comment says they're doing (assuming they're keying the hash). The guidelines seem explicitly written with the idea that unique identifiers _derived from_ this value are not similarly quarantined, provided that you cannot take the derived value and "reverse" it back to the original identifier. Quoting from https://www.freedesktop.org/software/systemd/man/machine-id.html https://www.freedesktop.org/software/systemd/man/machine-id....: This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one.
- pbhjpbhj 7y agoWhat else is going to break if one randomises that ID (per boot or per hour, say)?
- mc3 7y agoWhat about running Chrome inside a container?
- Tijdreiziger 7y agoWhat about not running Chrome?
- JdeBP 7y agoNow go and read http://jdebp.uk./Softwares/nosh/guide/commands/machine-id.xml http://jdebp.uk./Softwares/nosh/guide/commands/machine-id.xm... and RFCs 3041 and 4941.
- superlupo 7y ago> Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. Reading https://cs.chromium.org/chromium/src/chrome/browser/policy/browser_dm_token_storage_linux.cc?rcl=3b903e13b8529796af8d6861cbedbaec93c5b645&l=88 https://cs.chromium.org/chromium/src/chrome/browser/policy/b..., I do not not see it being hashed with a key, just unkeyed sha1.
- codedokode 7y agoI think it doesn't make much sense to protect it because in popular Linux distributions an unprivileged user can access such identifiers as MAC addresses of network interfaces, HDD serial numbers etc. > If a stable unique identifier that is tied to the machine is needed for some application, Ideally there should be no stable identifiers accessible to untrusted applications.
- mc3 7y ago> which is why we hash it first and then encode it in base64 before transmitting it. This made me chuckle. "As per the rules, we'll put on a boxing glove before we punch your lights out". You wont get privacy, but at least there is some security!
- RonanTheGrey 7y ago> As per the rules, we'll put on a boxing glove before we punch your lights out This also made me chuckle
- jabedude 7y agoThat really is a cynical comment. It almost bothers me more than this header.
- deleted 7y ago[deleted]
- mortehu 7y ago"Tracking purposes" is such a weasel word, when we're really talking about device management in an enterprise setting, and this code only gets activated if the root/administrator user has installed a token file on your computer.