Mozilla betrays Firefox users and its nominal principles
Unusually, I'll lead with what I think that you should do and explain the background afterward. In Firefox, go to about:preferences#privacy (the Privacy & Security tab of Firefox Preferences), scroll down almost to the bottom to the 'Firefox Data Collection and Use' section, and untick 'Allow Firefox to install and run studies'. To be safe, you probably want to also untick 'Allow Firefox to automatically send technical and interaction data to Mozilla'.
(Apparently you're going to have to re-check this set of preferences every so often, because Mozilla may be quietly re-enabling one or both every so often, perhaps on version upgrades.)
You should also go into about:addons (your set of extensions) and if there is something called 'Looking Glass', delete it (if possible, and that qualifier is part of the problem).
SHIELD studies let you try out different features and ideas before they are released to all Firefox users. Using your feedback, we can make more informed decisions based on what you actually need.
It appears that this preference (and the broader preference for sending data to Mozilla) is default-enabled in new Firefox profiles and installs, although I can't be entirely sure since my environment is somewhat unusual.
This preference sounds relatively harmless, and probably it used to be. Then very recently Mozilla pushed out a nominal SHIELD experiment in the form of a new extension called 'Looking Glass 1.0.3', with the helpful extension description text of 'MY REALITY IS JUST DIFFERENT THAN YOURS'. Unsurprisingly, a lot of people who noticed this extension appearing were quite alarmed, because it certainly does look like malware from surface appearances, and to add to the fun there was no particular sign in Firefox of what it did. People on Reddit who noticed it resorted to reverse engineering the extension's code in an attempt to figure things out, eg.
What this extension actually is is some kind of promotion from the Mr Robot TV show:
[...] Firefox and Mr Robot have collaborated on a shared experience to further your immersion into the Mr Robot universe, also known as an Alternate Reality Game (ARG). [...]
From the outside, this collaboration certainly seems like it was actually 'Mr Robot gave Mozilla a bunch of money and Mozilla abused its browser experiments system to inflict a Mr Robot promotional extension on people'. To make it worse, this is not just any old extension; this is an extension that apparently silently alters text on web pages (some text, only for a while).
There are two serious problems here, which are nicely summarized by Steve Klabnik in a tweet:
How can we claim to be pro-privacy while surreptitiously installing software on people's computers?
More importantly, how did management not see this as a problem?
The first problem is that Mozilla betrayed both the trust of Firefox users and its theoretical principles by abusing a system created for experiments to improve Firefox in order to stealthily install an extension that was completely unrelated to this purpose and that was instead (to all appearances) made for commercial reasons. Even assuming that Mozilla asserts that users 'opted in' to SHIELD experiments in any meaningful sense (given that the preference appears to default to on), all of Mozilla's documentation for SHIELD experiments says one thing about their purpose, and it is not doing commercial promotions. Users were not presented with a preference saying 'allow Mozilla to opt you in to promotions from people who pay us for this', so they have not in any way consented to this use of the system.
In short, Mozilla did not push this extension because they had consent from Firefox users, they pushed it purely because they had been trusted with the technical capability to do so. That is why you should turn off this preference; Mozilla has demonstrated that they cannot be trusted with it. It does not mean what it claims to mean; in practice the SHIELD preference means 'you've agreed that Mozilla can push random extensions to you if they feel like it'. You should not agree to this. Mozilla has additional technical capabilities to push extensions to you, but if they do so they are now clearly and undeniably doing so against your expressed wishes.
The bigger problem is that as an organization, Mozilla still does not appear to understand that they've done something bad or why it was bad. Mozilla (the entity) approved and actively collaborated in this abuse of trust and still doesn't seem to think there was anything wrong with it, or perhaps it thinks that at most the problems are technical (such as the extension description should have been clear or had links or whatever). An organization that understand that it had betrayed the trust of Firefox users would have a very different reaction than what little Mozilla has done. An organization that got it would be apologizing publicly, auto-removing the extension, and so on. It would not be having its marketing people say in public:
Here is Mozilla’s response, courtesy of Chief Marketing Officer Jascha Kaykas-Wolff: “Firefox worked with the Mr. Robot team to create a custom experience that would surprise and delight fans of the show and our users. It’s especially important to call out that this collaboration does not compromise our principles or values regarding privacy. The experience does not collect or share any data. [...]
This is the words of an organization that does not understand what having the trust of Firefox users means. Since it does not understand this, Mozilla is not worthy of this trust and cannot be trusted with it, which is the second and larger reason why you should turn off this preference and leave it off, and why you should probably turn off the top level preference for having Firefox send data to Mozilla at all. Whether you leave 'phone home' options like auto-update and addon auto-updates enabled is up to you, but if you're conscientious about keeping on top of that sort of thing, well, I don't think we can trust Mozilla as much as we used to.
I'm extremely disappointed in Mozilla here. If Chrome had pulled this shit, I would be sad and annoyed but unsurprised, because Chrome has always ultimately been a tool of its corporate overlords. But Mozilla has always claimed to stand for something better than that, and sometimes it even has. I won't say that Mozilla doesn't now, exactly, but it is now clear that standing for something better is not a particularly deep value in the portions of Mozilla that call the shots and that there is a critical mass of people working at Mozilla who do not have any problem with this sort of thing.
PS: As a corollary to what I've said about Chrome here, if you suggest that the sensible reaction to this is switching from Firefox to Chrome, I will laugh a lot (but a bit sadly).
How we automate acmetool
Acmetool is my preferred client
for Let's Encrypt and the one we've
adopted for our switch to Let's Encrypt at work.
If you know acmetool, talking about automating it sounds like a
contradiction in terms, because the entire design of acmetool is
about automating everything already; you put it in cron (or more
exactly you let it put itself in cron as part of setup with '
quickstart'), and then you forget about it. Perhaps you have to
write a hook script or two or adjust file permissions because a
daemon runs as a different user, but that should be it.
However, there are a few questions that acmetool will ask you initially and there's one situation where it has to ask you a new question during certificate renewal, as was pointed out by a commentator on my earlier entry:
Recently Let's Encrypt switched over to a new version of their user agreement (v1.2). As a result, all certificate renewals for old accounts started failing (because they had only agreed to v1.1), and I had to ssh to all our servers, interactively run
acmetool, and re-confirm the signup process (agreement & email) myself.
Fortunately you can automate this too, and you should. Acmetool
supports a response file, which
contains answers to questions that
acmetool may try to ask you
during either installation or certificate renewal. We automate these
questions by preinstalling a
responses file in
which makes '
acmetool quickstart' work without having to ask us
anything. When Let's Encrypt updated their user agreement, we pushed
out a new version of the
responses file that auto-accepted it and
so returned certificate renewals to working without any manual
(The first renewal attempt after Let's Encrypt's update reported
errors, then we worked out what the problem was, updated the file,
pushed out a new version, and everything was happy. My personal
websites avoided the problem entirely because of the timing; I had
a chance to update my own
responses file before any of their
renewals came up, and when renewal time hit
acmetool was fine.)
responses settings we use are:
"acme-enter-email": "<redacted>@<redacted>" "acmetool-quickstart-choose-server": https://acme-v01.api.letsencrypt.org/directory "acmetool-quickstart-choose-method": webroot "acmetool-quickstart-webroot-path": "/var/www/.well-known/acme-challenge" "acmetool-quickstart-install-cronjob": true # add an additional line to accept any new user agreement "acmetool-quickstart-choose-server": https://acme-v01.api.letsencrypt.org/directory
As shown in the example
responses file, you
can set additional parameters like the normal key type, RSA key
size, and so on. We haven't bothered doing this so far, but we may
in the future.
You could vary the email address if you wanted to (for example for different classes of machines). We don't bother, because it's mostly unimportant; in practice, all it gets is the occasional email about one of our generic test machine hostnames that hasn't renewed its certificate because we haven't been using that hostname for anything that needed one.