Add more missing `Preferences` ? about policy-templates HOT 11 CLOSED

Sorry, I didn't mean to sound so confrontational. We're definitely looking at a few of the prefs in your list.

I just have found in the past that lots of these lists are:

1. Old prefs that don't matter anymore.
2. Prefs that people set without understanding what they do or what the ramifications might be.
3. Unnecessary oversetting of prefs (telemetry is a good example).

Fingerprinting in particular is one I don't want to put in policy simply because I'm concerned folks will start setting that and then wonder why so many things are broken.

If you want to see what is on my radar, you can take a look here:

https://bugzilla.mozilla.org/buglist.cgi?product=Firefox&resolution=---&classification=Client%20Software&component=Enterprise%20Policies

Honestly, it's pretty much just me, so it's what I have time for.

Feel free to open bugs if you have a pref you feel strongly about.

from policy-templates.

I'm unclear why most folks would want to set most of these.

You can turn off telemetry.

Many of those aren't designed to be user changed at all.

from policy-templates.

This is a subset from arkenfox/user.js, I didn't include all the prefs in it, but from there we can see some of the reasons why users would change these.

If they do serve a purpose, and if we don't provide them in the policy, the user can still set them via user.js, it's just more cumbersome and redundant.

I'd like to manage all these prefs in one place, unless we have a better reason to refute each one.

from policy-templates.

For the sake of everyone's time:

captivedetect.canonicalURL

/* 0360: disable Captive Portal detection
 * [1] https://www.eff.org/deeplinks/2017/08/how-captive-portals-interfere-wireless-security-and-privacy ***/
user_pref("captivedetect.canonicalURL", "");
user_pref("network.captive-portal-service.enabled", false); // [FF52+]

devtools.debugger.remote-enabled

/* 2608: reset remote debugging to disabled
 * [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/16222 ***/
user_pref("devtools.debugger.remote-enabled", false); // [DEFAULT: false]

permissions.manager.defaultsUrl

/* 2616: remove special permissions for certain mozilla domains [FF35+]
 * [1] resource://app/defaults/permissions ***/
user_pref("permissions.manager.defaultsUrl", "");

privacy.resistFingerprinting
privacy.resistFingerprinting.pbmode

/* 4501: enable RFP
 * [SETUP-WEB] RFP can cause some website breakage: mainly canvas, use a canvas site exception via the urlbar.
 * RFP also has a few side effects: mainly timezone is UTC, and websites will prefer light theme
 * [NOTE] pbmode applies if true and the original pref is false
 * [1] https://bugzilla.mozilla.org/418986 ***/
user_pref("privacy.resistFingerprinting", true); // [FF41+]
   // user_pref("privacy.resistFingerprinting.pbmode", true); // [FF114+]

privacy.resistFingerprinting.block_mozAddonManager

/* 4503: disable mozAddonManager Web API [FF57+]
 * [NOTE] To allow extensions to work on AMO, you also need 2662
 * [1] https://bugzilla.mozilla.org/buglist.cgi?bug_id=1384330,1406795,1415644,1453988 ***/
user_pref("privacy.resistFingerprinting.block_mozAddonManager", true);

security.mixed_content.block_display_content

/* 1241: disable insecure passive content (such as images) on https pages ***/
   // user_pref("security.mixed_content.block_display_content", true); // Defense-in-depth (see 1244)
/* 1244: enable HTTPS-Only mode in all windows
 * When the top-level is HTTPS, insecure subresources are also upgraded (silent fail)
 * [SETTING] to add site exceptions: Padlock>HTTPS-Only mode>On (after "Continue to HTTP Site")
 * [SETTING] Privacy & Security>HTTPS-Only Mode (and manage exceptions)
 * [TEST] http://example.com [upgrade]
 * [TEST] http://httpforever.com/ | http://http.rip [no upgrade] ***/
user_pref("dom.security.https_only_mode", true); // [FF76+]

⬆️ If it is indeed fully contained by HTTPS-Only mode or affects the working of the latter, then we can ignore it, otherwise deep security should be selectable to the user.

security.remote_settings.crlite_filters.enabled
security.pki.crlite_mode

/* 1224: enable CRLite [FF73+]
 * 0 = disabled
 * 1 = consult CRLite but only collect telemetry
 * 2 = consult CRLite and enforce both "Revoked" and "Not Revoked" results
 * 3 = consult CRLite and enforce "Not Revoked" results, but defer to OCSP for "Revoked" (default)
 * [1] https://bugzilla.mozilla.org/buglist.cgi?bug_id=1429800,1670985,1753071
 * [2] https://blog.mozilla.org/security/tag/crlite/ ***/
user_pref("security.remote_settings.crlite_filters.enabled", true);
user_pref("security.pki.crlite_mode", 2);

security.ssl.treat_unsafe_negotiation_as_broken

/* 1270: display warning on the padlock for "broken security" (if 1201 is false)
 * Bug: warning padlock not indicated for subresources on a secure page! [2]
 * [1] https://wiki.mozilla.org/Security:Renegotiation
 * [2] https://bugzilla.mozilla.org/1353705 ***/
user_pref("security.ssl.treat_unsafe_negotiation_as_broken", true);

datareporting.healthreport.uploadEnabled

/* 0331: disable Health Reports
 * [SETTING] Privacy & Security>Firefox Data Collection & Use>Allow Firefox to send technical... data ***/
user_pref("datareporting.healthreport.uploadEnabled", false);

⬆️ I can see it being controlled by DisableTelemetry, so we maybe can ignore that.

But the question here is does DisableTelemetry cover all the other telemetry stuff mentioned below? Otherwise we're disabling the user's ability to view about:telemetry without completely disabling all telemetry from working, which might not be the desired behavior?
Policies.sys.mjs#831-845

  DisableTelemetry: {
    onBeforeAddons(manager, param) {
      if (param) {
        setAndLockPref("datareporting.healthreport.uploadEnabled", false);
        setAndLockPref("datareporting.policy.dataSubmissionEnabled", false);
        setAndLockPref("toolkit.telemetry.archive.enabled", false);
        blockAboutPage(manager, "about:telemetry");
      }
    },
  },

app.shield.optoutstudies.enabled
app.normandy.enabled
app.normandy.api_url

/** STUDIES ***/
/* 0340: disable Studies
 * [SETTING] Privacy & Security>Firefox Data Collection & Use>Allow Firefox to install and run studies ***/
user_pref("app.shield.optoutstudies.enabled", false);
/* 0341: disable Normandy/Shield [FF60+]
 * Shield is a telemetry system that can push and test "recipes"
 * [1] https://mozilla.github.io/normandy/ ***/
user_pref("app.normandy.enabled", false);
user_pref("app.normandy.api_url", "");

breakpad.reportURL

/** CRASH REPORTS ***/
/* 0350: disable Crash Reports ***/
user_pref("breakpad.reportURL", "");
user_pref("browser.tabs.crashReporting.sendReport", false); // [FF44+]

toolkit.telemetry.coverage.opt-out
toolkit.coverage.opt-out
toolkit.coverage.endpoint.base

/* 0333: disable Telemetry Coverage
 * [1] https://blog.mozilla.org/data/2018/08/20/effectively-measuring-search-in-firefox/ ***/
user_pref("toolkit.telemetry.coverage.opt-out", true); // [HIDDEN PREF]
user_pref("toolkit.coverage.opt-out", true); // [FF64+] [HIDDEN PREF]
user_pref("toolkit.coverage.endpoint.base", "");

toolkit.telemetry.unified
toolkit.telemetry.enabled
toolkit.telemetry.server
toolkit.telemetry.archive.enabled
toolkit.telemetry.newProfilePing.enabled
toolkit.telemetry.shutdownPingSender.enabled
toolkit.telemetry.updatePing.enabled
toolkit.telemetry.bhrPing.enabled
toolkit.telemetry.firstShutdownPing.enabled

/* 0332: disable telemetry
 * The "unified" pref affects the behavior of the "enabled" pref
 * - If "unified" is false then "enabled" controls the telemetry module
 * - If "unified" is true then "enabled" only controls whether to record extended data
 * [NOTE] "toolkit.telemetry.enabled" is now LOCKED to reflect prerelease (true) or release builds (false) [2]
 * [1] https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/internals/preferences.html
 * [2] https://medium.com/georg-fritzsche/data-preference-changes-in-firefox-58-2d5df9c428b5 ***/
user_pref("toolkit.telemetry.unified", false);
user_pref("toolkit.telemetry.enabled", false); // see [NOTE]
user_pref("toolkit.telemetry.server", "data:,");
user_pref("toolkit.telemetry.archive.enabled", false);
user_pref("toolkit.telemetry.newProfilePing.enabled", false); // [FF55+]
user_pref("toolkit.telemetry.shutdownPingSender.enabled", false); // [FF55+]
user_pref("toolkit.telemetry.updatePing.enabled", false); // [FF56+]
user_pref("toolkit.telemetry.bhrPing.enabled", false); // [FF57+] Background Hang Reporter
user_pref("toolkit.telemetry.firstShutdownPing.enabled", false); // [FF57+]

webchannel.allowObject.urlWhitelist

/* 2617: remove webchannel whitelist ***/
user_pref("webchannel.allowObject.urlWhitelist", "");

from policy-templates.

We have policies to turn off telemetry, studies, the captive portal and crash reporting.

They turn off the whole features internally and correctly.

There is no need to set all of these preferences for each of these features.

The goal of enterprise policy is to make available things that enterprises commonly set, not everything.

If you have the need to set arbitrary preferences, you can use Autoconfig.

from policy-templates.

We've evolved from AutoConfig-Driven CCK2 to the current enterprise policy, and most things have worked well. Thanks to everyone who has contributed.

I'm not sure what enterprises commonly set means here, but what I can say for sure is that different enterprises have different needs and depth of security accuracy rules, and some enterprises will never give feedback and raise needs like I do, they just silently adopt other solutions to solve some of their issues.

So I don't think there is such a thing as COMMONLY SET, if we don't have a valid reason to make a restriction, you never know who needs it. Like many accessibility features, I believe most users will never use or even understand them in their lifetime, but every a11y item has its place.

If this is not considered and there is no value in continuing the discussion, I will close the issue. Thank you again for making this happen.

from policy-templates.

I just have found in the past that lots of these lists are:
Old prefs that don't matter anymore.
Prefs that people set without understanding what they do or what the ramifications might be.
Unnecessary oversetting of prefs (telemetry is a good example).

I understand these, and I feel the same way, which is why I have some "background knowledge" here, since I've done so much research.

The reason why I ultimately chose to use arkenfox as my main reference and mention is because it is a list that is actively maintained and has been the subject of a lot of research and version follow-up by its maintainers, followed and recognized by many users.

As for telemetry, I think people's skepticism and confusion are completely justified, and I'll quote other developers directly:

Chris H-C :chutten Comment 1 • 7 years ago
This, rather unstraighforwardly, does not mean Telemetry is enabled. This means that, if telemetry is enabled, we collect somewhat more information. More details about our unfortunately-confusing Telemetry preferences can be found in the docs[1] and in the bug tree rooted at bug 1406390.

We plan on straightening out the confusion caused by these historical naming artefacts next year.

Published in Georg Fritzsche Nov 2, 2017
Currently the naming of these various controls is inconsistent and confusing. While we focused on the minimal required changes first, we will clean this up in the near future. Updating the Telemetry documentation to match the new behaviors is on-going.

Over the years, some things never really changed....

from policy-templates.

Honestly, it's pretty much just me, so it's what I have time for.

@mkaply Thank you for everything you've done and the time you've put in. As I mentioned in another issue, I never want to add some hassle or other people's workload, instead I want to reduce the manual workload of the project and make anything better.

from policy-templates.

Fingerprinting in particular is one I don't want to put in policy simply because I'm concerned folks will start setting that and then wonder why so many things are broken.

I think I'll reply additionally to this point because, I fully understand your concern. And I include it in the list is NOT because I want to enable it, rather I use it for locked or clear to avoid the damage that can be caused by immature RFPs being misinterpreted and turned on by people. Instead, I'm more excited about the progressively maturing FPP feature set.

I hope this explains why I was hoping to add some missing Preferences, like I said above, you can't assume what people will use it for, it may be used in ways that were not predicted. All we can do is provide the capability when people need it, accompanied by as much clear documentation as possible to provide guidance.

from policy-templates.

BTW, the URL has a circular redirection issue, maybe you should fix it:

https://mike.kaply.com/cck2/

from policy-templates.

Thanks, Fixed the redirect.

from policy-templates.