1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
# firefox-profiles
This repository attempts to provide tooling to aid the configuration of Firefox,
and offers multiple profiles which sacrifice convenience and sometimes security
in favor of data frugality.
## Required tooling
- [Nix](https://nixos.org/nix/), which offers a very convenient way of working with
deeply nested attribute sets, including composing and generating them.
- Nix is used here to build the Firefox configuration, to bundle it with nixpkgs-provided Firefox,
and to provide a wrapper to quickly test configuration changes with temporary profiles.
A deployment path without the installation of Nix on the managed devices is plausible,
only the administrator will need to have it installed.
## Usage
```bash
# this launches a configured instance
$(nix-build --no-out-link -A launcher)/bin/firefox
```
## Configuration approach
Firefox exposes two different types of settings:
- [*Preferences*](https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences): Key value pairs, e.g. `browser.cache.disk.enable` or `browser.search.defaultenginename`
- These are inspectable by visiting `about:config`
- I don't expect a lot of interface stability here
- [Enterprise policies](https://github.com/mozilla/policy-templates/)
- [Via `org.mozilla.firefox.plist` for macOS](https://support.mozilla.org/en-US/kb/customizing-firefox-macos-using-configuration-prof)
- [Via AD and "Local Group Policy" for Windows](https://support.mozilla.org/en-US/kb/customizing-firefox-using-group-policy-windows)
- [Using `policies.json` as the only cross-platform method](https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson)
- Despite the warning, they seem intended to be a more stable interface
- They offer limited access to the key value pairs mentioned above, exposing
a subset of them as [Preferences](https://github.com/mozilla/policy-templates/#preferences)
As far as I can tell, the primary methods of configuration are:
- The Firefox profile, stored in **~/.mozilla/firefox/something.default**
- **prefs.js**: This file contains interactively set configuration variables.
It is overwritten frequently and should not be modified from applications that
are not Firefox.
- **user.js**: A configuration file similar to `prefs.js`, but it is never written
to by Firefox, and is loaded after `prefs.js`, which means preferences defined
here take precedence.
- The Firefox distribution, created either by Mozilla directly, or by your
favorite Linux distribution package maintainers
- `$FIREFOX_EXECUTABLE/../lib/firefox/distribution/policies.json`: Allows defining enterprise policy settings,
which are applied to any instance launched from `$FIREFOX_EXECUTABLE`.
- `$FIREFOX_EXECUTABLE/../lib/firefox/defaults/pref/*.js`: These files are executed on every launch, and can
serve as an alternative to `user.js`
- `$FIREFOX_EXECUTABLE/../lib/firefox/browser/omni.ja`: Contains bundled resources and scripts, which are given
special permissions in some situations (e.g. pre-configuring a default search engine).
For this project, I decided against `user.js` for the following reasons:
- It's not recommended by Mozilla, I've seen enterprise policies recommended more often for shipping
preconfigured instances.
- Preconfiguration via `user.js` would require copying into every profile of every user it should apply to,
which requires either a wrapper script or a daemon to watch for new profile creations.
- The `user.js` files in the users profile directory are editable by users, and every process they execute.
This can be exploited to e.g. configure a socks proxy and spy on users without their knowledge.
- [Future support for configuration via user.js is uncertain](https://bugzilla.mozilla.org/show_bug.cgi?id=1543752)
- Installation-wide configuration should happen centrally, not in a dozen places all over /home.
Meanwhile, enterprise policies seem to enjoy more direct support from Mozilla, are applied to any profile launched
with the bundled Firefox, and the bundled preference files are not editable by ordinary user processes.
Depending on the selected profiles, a combination of enterprise profiles, a bundled settings file in `lib/firefox/defaults/pref/*.js`,
and even patching of `omni.ja` is applied in order to achieve their goal.
## Qwant Junior
I built a minimal extension to add Qwant Junior as a search engine in `profiles/addons/qwantjunior`.
Mozilla tried very hard to prevent the preconfiguration of bundled default search engines, and the only way
to do so (as far as I could tell), is to install the extension into FFs built-in extensions. Being a built-in
extension bypasses the prompt asking the user whether to allow setting a default search engine.
The extension works Fine™ if installed ordinarily, but it prompts the user with a dialog on the first start,
which had a bug in my testing, and I needed to be careful to prevent accidental dismissal.
And yes, Firefox refuses to load the addon if the id doesn't match `*@search.mozilla.org`.
## Known issues
- With this first attempt, usage errors can be silently ignored, which is probably going to be quite irritating for any non-Nix people.
- I plan to migrate this to Nix modules, which should result in a much better configuration exprience.
|