On Sat, Mar 09, 2019 at 11:01:43AM -0500, Hendrik Boom wrote:
> On Sat, Mar 09, 2019 at 02:34:28AM -0600, golinux@??? 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?
⠈⠳⣄⠀⠀⠀⠀