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
theory, what you should be able to do is to just '
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
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
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
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
debian.master/changelog and the '
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 '
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 '
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
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 '
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.)