As Clover gets older I’m starting to assess which digital tools are appropriate for them to use; fortunately, a web browser is still a ways off. I currently don’t have a browser to recommend, for my kid, or for any user, really. I mainly use Firefox, but I customize it so much I can’t recommend it without a user’s manual, and that doesn’t make any sense.
And what I mostly configure Firefox to do is not sell me out, which is is constantly trying to do. Like, it’s ridiculous. But it’s also the only browser that loads the limited interactive sites I use, such as Discourse sites or Wikipedia projects, sites that are important to me.
And so I now turn my attention to a the policies.json file that may be used to configure many settings for Firefox, including disabling a huge amount of “features” that we all probably want to go away.
I have a few profiles in mind for policies.json usage:
Me
Clover
kiosk computer, as used at events or by volunteers
public access (labs, libraries, etc.)
community computers
By that last one I mean: a policies file I could install on computers I refurbish/setup for community members needing a computer. It makes no sense to enable a person to become enthralled by Google as soon as they need to look something up.
This topic will contain a setting-by-setting reflection on the policies.
That link go to a document detailing, “… how to add enterprise policy support to your extension to allow enterprises to preconfigure settings in your extension.”
Which amounts to formatting the data in a way that the extension may read from local storage, via this policy. Neat! (I don’t generally use web extensions, so it sounds interesting in theory…)
Define domains allowed to access Google Workspace.
This policy is based on the Chrome policy of the same name.
If this policy is enabled, users can only access Google Workspace using accounts from the specified domains. If you want to allow Gmail, you can add consumer_accounts to the list.
I didn’t quite understand this, so I read that link, where it explains:
Setting the policy turns on Chrome’s restricted sign-in feature in Google Workspace and prevents users from changing this setting. Users can only access Google tools using accounts from the specified domains (to allow gmail or googlemail accounts, add consumer_accounts to the list of domains). This setting prevents users from signing in and adding a Secondary Account on a managed device that requires Google authentication, if that account doesn’t belong to one of the explicitly allowed domains.
Leaving this setting empty or unset means users can access Google Workspace with any account.
I don’t use nor endorse Google Apps, so I’ll likely not set it. Potentially useful for a workforce where you don’t want folks setting up what is essentially a company Google device with their personal Google accounts. Kinda funny it’s in Firefox, perhaps for feature parity?
If set to true, application updates are installed without user approval within Firefox. The operating system might still require approval.
If set to false, application updates are downloaded but the user can choose when to install the update.
If you have disabled updates via DisableAppUpdate, this policy has no effect.
{
"policies": {
"AppAutoUpdate": true | false
}
}
This policy will depend on how the app is being upgraded on the device. For personal use I install Firefox via Flatpak, which has it’s own update mechanism; in such cases I might set DisableAppUpdate. Actually, for most cases where a policies.json is set, one probably wants the user to not mess around with updates (because it’s a different part of system admin, whereas the browser is for… browsing).
Huh, that’s kinda interesting… I wonder if one can package Firefox to include these policies installed? Probably not worth it, except in large deployments (many machines).
This document provides an overview of Mozilla’s support for integrated authentication. This entails support for the the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) internet standard (RFC 2478) to negotiate either Kerberos, NTLM, or other authentication protocols supported by the operating system. SPNEGO is commonly referred to as the “negotiate” authentication protocol.
Mozilla does not have its own internal implementation of SPNEGO. Instead, it leverages system libraries that provide SPNEGO; SSPI on Microsoft Windows, and GSS-API on Linux, Mac OSX, and other UNIX-like systems.
The Mozilla implementation of SPNEGO can be found under {{ Source(“extensions/auth/”) }}. It used to live in extensions/negotiateauth.
Mozilla also supports raw NTLM authentication using an internal implementation (based on the documentation provided by Eric Glass) that supports NTLMv1/LMv1 and NTLM2 Session Key modes. As of Mozilla 1.7, there is no support for NTLMv2/LMv2. This is mainly due to the fact that NTLMSSP does not provide a means to negotiate use of NTLMv2/LMv2.
Flow Diagram
The diagram below shows how various components interact.
Configuration
By default, Mozilla rejects all SPNEGO challenges from a web server. This is to protect the user from the possibility of DNS-spoofing being used to stage a man-in-the-middle exploit (see {{ Bug(17578) }} for more info). Moreover, with Windows clients NTLM may be negotiated as the authentication protocol. So, it is paramount that the browser does not freely exchange NTLM user credentials with any server that requests them. The NTLM response includes a hash of the user’s logon credentials. On older versions of Windows this hash is computed using a relatively weak algorithm (see Hertel for more info on NTLM authentication).
Mozilla currently supports a whitelist of sites that are permitted to engage in SPNEGO authentication with the browser. This list is intended to be configured by an IT department prior to distributing Mozilla to end-users.
network.negotiate-auth.trusted-uris lists the sites that are permitted to engage in SPNEGO authentication with the browser, and network.negotiate-auth.delegation-uris lists the sites for which the browser may delegate user authorization to the server. network.automatic-ntlm-auth.trusted-uris lists the trusted sites to use NTLM authentification.
If you wish to use non-fully-qualified entries of the form mydomain.com in the above preferences for NTLM and SPNEGO authentication, you will also need to set the preferences network.automatic-ntlm-auth.allow-non-fqdn and network.negotiate-auth.allow-non-fqdn (respectively) to true.
Meaning unless one is using the “Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) internet standard (RFC 2478)”, this setting is irrelevant.
I’m not sure at this point if a default should be provided, or omitted. I’ll investigate in time.
Define a list of external protocols that can be used from listed origins without prompting the user. The origin is the scheme plus the hostname.
The syntax of this policy is exactly the same as the Chrome AutoLaunchProtocolsFromOrigins policy except that you can only use valid origins (not just hostnames). This also means that you cannot specify an asterisk for all origins.
I’ve got some thoughts on this, but I’m still developing them. At any rate, the primary way I see these being used online is to launch websites or applications for specific protocol prefixes. I’m fond of apt, but mostly see folks referring to steam. We’ll get there…
Enable or disable automatic application update in the background, when the application is not running.
If set to true, application updates may be installed (without user approval) in the background, even when the application is not running. The operating system might still require approval.
If set to false, the application will not try to install updates when the application is not running.
If you have disabled updates via DisableAppUpdate or disabled automatic updates via AppAutoUpdate, this policy has no effect.
So far I hadn’t been including “Compatibility”, presuming it was the earliest version of Firefox that supported a given policy, and any policy in the list would be current. However, this is a Windows-only policy. And because I don’t use Windows personally, I don’t know how it works.
What is the preferred ways to keep software updated in Windows?
For most policy deployments I think the use case excludes end-users managing addons, so this should be true, to block access.
Fortunately, there are ways to manage Extensions via policies, so we’ll address the use-cases and check how it actually works when we get there. I hope that shows a reasonable path to providing language support in a public lab scenario, as well as being able to configure some parts, as necessary.
Basically, the ability to access config depends on whether the computer is public or private. For public computers it doesn’t make much sense to expose config; hopefully everything needing to be customized can be done with policies.json.
For private computers, it makes sense to expose the config settings, so the user may configure their user-agent as desired.
Edit: I had to tuncate the data copied to fit in the 32,000 character limit in Discourse; it’s all fairly boring, though.
I haven’t read through each thing, but I don’t think there is any personal information included. I’ll continue to investigate, but I think that all users of Firefox benefit from having access to this page.
Note: ManagedBookmarks is the new recommended way to add bookmarks. This policy will continue to be supported.
Add bookmarks in either the bookmarks toolbar or menu. Only Title and URL are required. If Placement is not specified, the bookmark will be placed on the toolbar. If Folder is specified, it is automatically created and bookmarks with the same folder name are grouped together.
If you want to clear all bookmarks set with this policy, you can set the value to an empty array ([]). This can be on Windows via the new Bookmarks (JSON) policy available with GPO and Intune.
These are pages used to login to networks, such as for using a wireless network at a public library.
I’m not sure about this setting, it’s about the detection of captive portals. Reasons to keep it on is for users to easily get online various networks that require captive portals for access. Reasons to not detect them might be so a pre-configured connection is setup, and the user ought to not be notified of potential networks the device is connecting to…
I’m not sure! Why would we turn off captive portal detection?
I read the bug reports, and the idea for Linux is to read the system CA store, or install and link your own…
Certificates | Install
Install certificates into the Firefox certificate store. If only a filename is specified, Firefox searches for the file in the following locations:
Windows
%USERPROFILE%\AppData\Local\Mozilla\Certificates
%USERPROFILE%\AppData\Roaming\Mozilla\Certificates
macOS
/Library/Application Support/Mozilla/Certificates
~/Library/Application Support/Mozilla/Certificates
Linux
/usr/lib/mozilla/certificates
/usr/lib64/mozilla/certificates
~/.mozilla/certificates
Starting with Firefox 65, Firefox 60.5 ESR, a fully qualified path can be used, including UNC paths. You should use the native path style for your operating system. We do not support using %USERPROFILE% or other environment variables on Windows.
If you are specifying the path in the policies.json file on Windows, you need to escape your backslashes (\) which means that for UNC paths, you need to escape both (\\). If you use group policy, you only need one backslash.
Certificates are installed using the trust string CT,CT,.
Binary (DER) and ASCII (PEM) certificates are both supported.
Okay, so installing certificates this way is useful for some cases, but I can’t think of any at the moment. I mean, practically. I don’t know of a public lab or personal user that wants to install certificates. So we’ll say for now: useful if needed.
Okay, now we’re talking! We’re definitely going to mess with cookies policies, for everyone. And because there are so many options, we’ll return to this and dive into each of those settings, with explanations for different profiles.
I know right now, my personal cookies settings are going to be very restrictive, probably more so than most folks are used to. On the other hand, I don’t suffer foolish websites.
For public computers this is useful to set where files will download, such as the Desktop or a special user directory on a network mount.
For personal use I will definitely set this, but I’d prefer it Firefox followed XDG_DOWNLOAD_DIR, but that has never been my experience. Maybe I could try debugging that…
I believe there are a couple of other places updates are addressed in policies, so after I’ve gone through them all I write up how they work together, and how they ought to be applied.
I personally install Firefox from Flatpak, which I think address a lot of issues for updates, and I’m interested in describing a potential public computer deployment strategy that takes a mutable OS and Flatpak approach.
This is very interesting. I haven’t done research, but I imagine this is a useful feature, given how often organizations give people information in PDF. A decade ago all my clients wanted to know if we could turn on this functionality, for any user, rather than download a PDF directly…
For public computers I think there are select scenarios where one wants to disable and send externally; computers are print shops with specialized printer hardware, for instance.
For personal users I suppose it comes down to preference. I don’t view PDFs in the browser, but that’s because I’m used to selecting the context for all downloads…
