From dng-bounces@lists.dyne.org Tue Mar 27 14: 3:36 2018
Date: Tue, 27 Mar 2018 17:43:15 -0400
From: Taiidan@gmx.com
To: dng@lists.dyne.org
Subject: [DNG] Mozilla is at it again - Firefox nightly sends all your hostname lookups to cloudflare

https://www.theregister.co.uk/2018/03/20/mozilla_firefox_test_of_privacy_mechanism_prompts_privacy_worries/

Time for a fork, a la Devuan.

Cloudflare is a project of an intelligence agency - they are able to monitor most of the Internet as it goes via their "protection" servers, and they have created the idea in the heads of the average sysadmin that you NEED such a service or else you simply can't exist on the Internet, which is absolutely false.

Mozilla sucks these days - they pay zero attention to the issue of browser fingerprinting, and keep sending users data to other parties via bogus "opt out" "research" studies.

"Oh but you can opt-out"
Assuming you even know about it, in the first place - and what? You need to opt-out of probably thousands of bad things in your life, which makes such a policy absolute bullshit.

"If it was opt-in no one would do it and therefo-"
Yeah, no shit - because no one really wants their data collected, especially when they receive absolutely zero benefit from it.





Date: Wed, 28 Mar 2018 02:42:53 +0200
From dng-bounces@lists.dyne.org Tue Mar 27 17: 3:22 2018
From: Adam Borowski <kilobyte@angband.pl>
To: dng@lists.dyne.org
Subject: Re: [DNG] Mozilla is at it again - Firefox nightly sends all your hostname lookups to cloudflare

The only saving grace is that they do this tracking on a test group. On the other hand, Chromium saves both the URL and refer[r]er of every downloaded file using an user-namespace xattr, a little-known feature implemented by most filesystems (not tmpfs, if you use /tmp for testing :p). Even in its "incognito mode" that's not supposed to log anything.

Note that no tool displays the presence of user-namespace xattrs during normal use, and to specifically query them, you need a tool that's not installed by default (either getfattr from package "attr" or xattr from package by that name).

Usually, when you hear about xattrs, it's because of file capabilities or selinux labels, that's why most file manipulation programs either copy xattrs by default or can be told to do so. If you don't know what I'm talking about, run: "getcap -r /bin /sbin /usr" (it's a safer version of the setuid bit that grants only limited capabilities, so if someone suborns eg. /bin/ping, the attacker obtains only use of raw sockets instead of full root escalation). For this reason, most sysadmins are told to give -X to rsync.

Some tools copy xattrs, some don't:

Obviously though, lack of such support doesn't help if you save the file directly to its final destination, which you usually do.

Support in filesystem varies:

Usually you can mount -o nouser_xattr, which is wrongly documented as being reiserfs specific (which shows how widespread knowledge of this is...); alas this doesn't include btrfs which doesn't support nouser_xattr. I guess someone should implement it...

The only other tool that logs the URL and (on recursive downloads) refer[r]er this way is wget, which got patched by Sean Burford (a Google employee) at the same time when this misfeature landed in Chrom{e,ium}.

More interesting is the timing between this addition and the DNC hack, where the files are known to have been saved to an USB pen drive. This would explain the weird inclusion of refer[r]er, which has no obvious legitimate use but would often leak who downloaded the file (if a session was identified as an argument to the URL rather than a cookie).

Most of us don't run around hacking a ruling party for a sinister Russian agency -- but you do carry a phone, which get routinely seized, searched, or possibly even remotely accessed. Thus, if you have any files whose origin you'd prefer to stay private...

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.




Date: Wed, 28 Mar 2018 16:23:20 -0500
From dng-bounces@lists.dyne.org Wed Mar 28 14: 3:41 2018
From: John Morris <jmorris@beau.org>
To: dng@lists.dyne.org
Subject: Re: [DNG] Mozilla is at it again - Firefox nightly sends all your hostname lookups to cloudflare
Organization: Beauregard Parish Library
X-Mailer: Evolution 3.12.9-1+b1

On Wed, 2018-03-28 at 02:42 +0200, Adam Borowski wrote:

> More interesting is the timing between this addition and the DNC hack,
> where the files are known to have been saved to an USB pen drive.
> This would explain the weird inclusion of refer[r]er, which has no
> obvious legitimate use but would often leak who downloaded the file
> (if a session was identified as an argument to the URL rather than a
> cookie).

Looks older:
https://bugs.chromium.org/p/chromium/issues/detail?id=45903

So if Seth Rich used Chrome, it might have incriminated him. If someone got the physical flash drive he was using. Or he uploaded a .tar file that preserved the extended attributes? But the 4chan spergs who went over the DNC Leaks would have noticed something that big.

And it gets better:
https://www.freedesktop.org/wiki/CommonExtendedAttributes/

I swear, these people are a menace. According to the same madmen who gave us the modern desktops this isn't a security problem, a privacy violation or even a bug. It is a feature.

According to that bug, this started on Mac and was added to the Linux version. No note saying it was added to Windows. If anyone still runs that legacy security nightmare, it would be good to know if it has or doesn't have this anti-feature.





RM notes: Some would say that the potential for applications to store in many cases security-sensitive information into extended file attributes, e.g., Chromium storing the origin and referrer URLs into extended file attributes for all downloaded files, violates the principle of least surprise, in that users do not expect this metadata, are generaly not even aware of the tools required to view or edit them, and are not consulted before they are created.

So, personally, I would want to find a way to affirmatively disable this ability in my filesystems. It appears this can be done for ext{2,3,4} using the tune2fs utility, e.g.:

tune2fs -O ^user_xattr /dev/sda1

For some filesystems, you can instead use a "nouser_xattr" mount(8) option, if you wish.

Additional coverage at:

http://www.linux-mag.com/id/8741/ (makes the important point that user extended file attributes, discussed here, are just one of four varieties) https://www.lesbonscomptes.com/pages/extattrs.html
https://manpages.debian.org/testing/mount/mount.8.en.html
https://www.lesbonscomptes.com/pages/extattrs.html

Web pages that explain how to not have extended file attribute support are rare; those that take for granted that of course you would want this hidden place for applications to store personally identifying information you don't expect to exist are legion.