On Sat, Mar 09, 2019 at 11:01:43AM -0500, Hendrik Boom wrote: > On Sat, Mar 09, 2019 at 02:34:28AM -0600, goli...@dyne.org wrote: > > Oh, my . . . how fast and how hard Debian has fallen . . I am all for > > shining light into dark, dank places. What a terrific idea to track > > down all the offending packages that are "leaking" information and then > > publish an ongoing list of them and how they "phone home". > > Good idea. Just like the evil bit. https://www.ietf.org/rfc/rfc3514.txt
The evil bit is impossible only if you don't have means of controlling the software. A distribution, and the user, can check and/or alter every bit of code that's running. The vast majority of phone home functionality in question has no malicious _intent_, even if consequences may be dire. For example: * clementine, a music player -- sends info about every song you play, even local, to 20+ servers to get lyrics, "last.fm scrobbler" (whatever that is), etc. The intent is to have a feature some users may want, enabled by default. Consequences: copyright mafia getting you for piracy, marketing mafia knowing your music preferences, possibly government mafia if instead of music you listen to dissident podcasts. * systemd-networkd falls back to 8.8.8.8 if there's no configured DNS resolver (usually due to tempfail). Intent: even with misconfiguration, "the Internet" works. Consequences: every single your network requests gets sent to world's second most nosy company, which has extensive infrastructure for cross-matching this kind of data. Extra fun if you're working in a secret government group of a country not liked by the US -- or a competitor to Google, or, ... There's very few cases where I suspect ill intent: * chromium saves the URL and referer of every file you download hidden as an user namespace xattr (so methods known to the vast majority of sysadmins and even filesystem engineers won't find that) * chromium sends /etc/machine-id as "Cloud something Enrollment Token" The latter is golden, and can fool a casual reviewer: // 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. So how exactly a 160-bit hash of a 128-bit random value (ie, having no structured data inside beside being unique) would help? At this point, we face either stupidity or malice, but I wouldn't insult Googlers by accusing them of incompetence. And that means... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄⠀⠀⠀⠀ _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
