Wandering Thoughts archives

You shouldn't allow Firefox to recommend things to you any more

The sad Firefox news of the time interval is Mozilla: Ad on Firefox’s new tab page was just another experiment, and also on Reddit. The important quote from the article is:

Some Firefox users yesterday started seeing an ad in the desktop version of the browser. It offers users a $20 Amazon gift card in return for booking your next hotel stay via Booking.com. We reached out to Mozilla, which confirmed the ad was a Firefox experiment and that no user data was being shared with its partners.

Mozilla of course claims that this was not an "ad"; to quote their spokesperson from the article:

“This snippet was an experiment to provide more value to Firefox users through offers provided by a partner,” a Mozilla spokesperson told VentureBeat. “It was not a paid placement or advertisement. [...]

This is horseshit, as the article notes. Regardless of whether Mozilla was getting paid for it, it was totally an ad, and that means that it is on the slippery slope towards all of the things that come with ads in general, including and especially ad-driven surveillance and data gathering. Mozilla even admitted that there was some degree of data gathering involved:

“About 25 percent of the U.S. audience who were using the latest edition of Firefox within the past five days were eligible to see it.”

In order to know who is in 'the US audience', Mozilla is collecting data on you and using it for ad targeting.

So, sadly, we've reached the point where you should go into your Firefox Preferences and disable every single thing that Mozilla would like to 'recommend' to you on your home page (or elsewhere). At the moment that is in the Home tab of Preferences, and is only 'Recommended by Pocket' and 'Snippets'; however, you should probably check back in every new version of Firefox to see if Mozilla has added anything new. This goes along with turning off Mozilla's ability to run Firefox studies and collect data from you and probably not running Firefox Nightly.

This may or may not prevent Mozilla from gathering data on you, but at least you've made your views clear to Mozilla and they can't honestly claim that they're acting innocently (as with SHIELD studies). They'll do so anyway, because that's how Mozilla is now, but we do what we can do. In fact, this specific issue is a manifestation of what I wrote in the aftermath of last year's explosion, where Mozilla promised to stop abusing the SHIELD system but that was mostly empty because they had other mechanisms available that would abuse people's trust in them. They have now demonstrated this by their use of the 'Snippets' system to push ads on people, and they're probably going to use every other technical mechanism that they have sooner or later.

The obvious end point is that Mozilla will resort to pushing this sort of thing as part of Firefox version updates, which means that you will have to inspect every new version carefully (at least all of the preferences) and perhaps stop upgrading or switch to custom builds of Firefox that have things stripped out, perhaps GNU IceCat.

(Possibly Debian will strip these things out of their version of Firefox should this come to pass. I wouldn't count on Ubuntu to do so. People on Windows or OS X are unfortunately on their own.)

PS: Chrome and Chromium are still probably worse from a privacy perspective, and they are certainly worse for addons safety, which you should definitely be worried about if you use addons at all.

How I get a copy of the Ubuntu kernel source code (as of Ubuntu 18.04)

For unfortunate reasons beyond the scope of this entry, I've recently needed to once again take a look at the Ubuntu kernel source code, as they're patched and modified and so on from the upstream versions. There are some things where I'll just look at the official kernel source, but for certain sorts of issues, nothing short of the real kernel we're using (or something close to it) will do. Every time I do this I have to re-discover or re-work out how to get a copy of this source code, so this time around I'm going to write it down. The necessary disclaimer is that Ubuntu may change all of this in the future.

There are two approaches you can take here, depending on what you want. I'll start with the more obvious one, using apt-get. In theory, what you should be able to do is to just 'apt-get source' on the kernel that you're running, in other words generally:

apt-get source linux-image-$(uname -r)

If you try this, you will get a 'linux-signed' source package, which does not actually contain any kernel source. It turns out that what you really want is the source package for the linux-image-unsigned package. This is the 'linux' source package, so you can do either of the following commands:

apt-get source linux-image-unsigned-$(uname -r)
apt-get source linux

In either case, you end up with the most recent kernel source package, which is not necessarily the source code to the kernel that you're actually running. Unfortunately there's no guarantee that Ubuntu still has the linux source package for your specific kernel available as a source package; they appear to purge old ones from mirrors, just as they purge the old binary packages.

The other approach is the one recommended by Ubuntu and which a successful 'apt-get source' will nag you about, which is to clone it from Ubuntu's kernel git tree. At the moment (here at the start of 2019), you can find information on this in Ubuntu's KernelGitGuide wiki page or their page on kernel source (note that this page is incorrect about apt-get). The Ubuntu 18.04 LTS git tree is here, although per Ubuntu's wiki page, you should clone it with the git: protocol URLs. As you can see, there are a variety of tags and branches in the repo, and I think they're all reasonably obvious (and there's some explanation of them in the Ubuntu wiki pages).

In the 'apt-get source' version, the Ubuntu package changelog is in debian/changelog; this is what you want to consult if you're looking for relevant bug fixes and so on. In the git version, the changelog is debian.master/changelog and the 'debian' directory has other things. In the git version, Ubuntu generally commits individual Ubuntu changes as individual git commits, which means that you can use 'git log' to scan for Ubuntu changes to particular files or directories of interest. Because the git version has tags for specific releases, it's also the easiest way to see the Ubuntu kernel tree as of a specific linux-image version (or to see the differences between two of them, perhaps in a sub-tree).

For instance, suppose you want to see all changes since Ubuntu's 4.15.0-30 in some areas of the tree. You could do:

git log Ubuntu-4.15.0-30.32.. -- fs/sysfs fs/namei.c fs/inode.c fs/dcache.c

A specific commit can then be shown with 'git show <id>' as usual, which will show you the diff as well as its commit message.

Ubuntu's kernels have the ZFS on Linux kernel module code in top-level 'spl' and 'zfs' directories. The user level tools are in a separate set of packages with their own source package, 'zfs-linux'. Apt-getting this source package will produce a claim that it is really maintained in Debian GIT, but I'm not sure that's actually true for the Ubuntu version. While this source package still includes the kernel module source code, I believe only the user level stuff is used. I'm not sure how Ubuntu manages changes to all of this, but they appear to keep everything in sync somehow.

(In Ubuntu 20.04, there will likely only be a single 'zfs' directory, since ZFS on Linux has merged the 'spl' package into the 'zfs' one in its development version.)

In theory Ubuntu has instructions on building packages from the git version here, and they were even updated within the past year. In practice I have no idea, since I haven't ever built a new Ubuntu kernel package, but I would probably be inclined to start from 'apt-get source linux', because that's at least in a format that I sort of understand. Of course, if I had to build a modified version of a specific, no longer current linux-image version, I might have to use the git version because that's the only way I can get the exact source code.

(Perhaps this means we should be routinely saving the kernel source packages for important kernels that we use. Sadly it's now too late to do this for the kernel that our Linux fileservers use; we froze their kernel version some time ago and the 'linux' source package for it is long gone now.)