Items to followup on from #442

[Thorin-Oakenpants]

So... someone kindly dumped (#442) over 450 prefs on us me - prefs that were not in our user.js. These are the items that need more investigating

--
🔻 ADDED

• user_pref("gfx.downloadable_fonts.fallback_delay", -1); tor 27258 - 587194c
• user_pref("network.gio.supported-protocols", ""); // hidden pref 1433507 - 732c438
• user_pref("security.mixed_content.block_object_subrequest", true); 1190623 - 7351e56

🔻 PENDING

• maybe
  • user_pref("dom.requestIdleCallback.enabled", false); // FF55+ tor 26605
  • user_pref("network.http.prompt-temp-redirect", true); // earthlng: maybe add this?

---

• handler stuff, as per a PK diff, although this one has more items (32). would need to merge the two to be sure
  • network.protocol-handler.expose*
  • network.protocol-handler.external*
  • network.protocol-handler.warn-external*
    • 440892 fairly sure warn-external are not used (might require looking at the code again)

those 32 `protocol-handler` prefs

user_pref("network.protocol-handler.expose-all", false);
user_pref("network.protocol-handler.expose.about", true);
user_pref("network.protocol-handler.expose.blob", true);
user_pref("network.protocol-handler.expose.chrome", true);
user_pref("network.protocol-handler.expose.file", true);
user_pref("network.protocol-handler.expose.ftp", true);
user_pref("network.protocol-handler.expose.http", true);
user_pref("network.protocol-handler.expose.https", true);
user_pref("network.protocol-handler.expose.javascript", false);
user_pref("network.protocol-handler.expose.moz-extension", true);
user_pref("network.protocol-handler.external-default", false);
user_pref("network.protocol-handler.external.about", false);
user_pref("network.protocol-handler.external.blob", false);
user_pref("network.protocol-handler.external.chrome", false);
user_pref("network.protocol-handler.external.file", false);
user_pref("network.protocol-handler.external.ftp", false);
user_pref("network.protocol-handler.external.htp", false);
user_pref("network.protocol-handler.external.htps", false);
user_pref("network.protocol-handler.external.http", false);
user_pref("network.protocol-handler.external.https", false);
user_pref("network.protocol-handler.external.javascript", false);
user_pref("network.protocol-handler.external.mailto", false);
user_pref("network.protocol-handler.external.moz-extension", false);
user_pref("network.protocol-handler.external.news", false);
user_pref("network.protocol-handler.external.nntp", false);
user_pref("network.protocol-handler.external.snews", false);
user_pref("network.protocol-handler.warn-external-default", true);
user_pref("network.protocol-handler.warn-external.file", true);
user_pref("network.protocol-handler.warn-external.mailto", true);
user_pref("network.protocol-handler.warn-external.news", true);
user_pref("network.protocol-handler.warn-external.nntp", true);
user_pref("network.protocol-handler.warn-external.snews", true);

---

🔻 NAH

• user_pref("accessibility.blockautorefresh", true); KB
• user_pref("browser.disableResetPrompt", true); // hidden pref moz support
  • highly unlikely to get triggered (requires 60 days of stale profile), is a prompt only (you can say no), and is not privacy/security etc related
• user_pref("browser.meta_refresh_when_inactive.disabled", true); 518805
• user_pref("browser.search.isUS", false); - removed in 62
• user_pref("network.cookie.blockFutureCookies", false); // hidden pref KB - removed in 61
• user_pref("general.useragent.site_specific_overrides", true);
  • I knew about general.useragent.override.websitenamehere.com, but didn't know it relied on this master pref. Not interested in adding to the user.js, because, see the header for section 4700 - it's an incomplete half-baked solution.
• user_pref("accessibility.indicator.enabled", false);
  • we have accessibility.force_disabled=1 2601 so this is moot. A fallback of true would be good, but we already do way too much. Not interested.
• ping-center: covered by a pref 0506 as well as telemetry pref 0333
  • // user_pref("browser.ping-centre.production.endpoint", "");
  • // user_pref("browser.ping-centre.staging.endpoint", "");
• device sensors: covered by device.sensors.enabled 4604 & RFP
  • // user_pref("device.sensors.motion.enabled", false);
  • // user_pref("device.sensors.orientation.enabled", false);
  • // user_pref("device.sensors.ambientLight.enabled", false); 1462308
  • // user_pref("device.sensors.proximity.enabled", false); 1462308
• pdf stuff - nah, can't be bothered anymore
  • pdfjs.disableRange tor 26540 & tor 15599 & 1506693
  • pdfjs.disableAutoFetch
    // TBB 7.5.6=false, FF61=true. If false, only renders pages that are visible, see github
• some items at default from part 3: maybe enforce them - nah, can't be fucked
  • user_pref("devtools.cache.disabled", false);
  • user_pref("devtools.debugger.force-local", true);
  • user_pref("network.http.sendOriginHeader", 0);
• WebVTT 1390465 - nah, really low priority if even a privacy concern
  • user_pref("media.webvtt.pseudo.enabled", false);
  • user_pref("media.webvtt.regions.enabled", false);
• WASM extras (add to js as inactive under 2422?) tor 21549, tor 26407 slider - nah, master pref is enough
  • user_pref("javascript.options.wasm_baselinejit", false);
  • user_pref("javascript.options.wasm_ionjit", false);
• user_pref("plugin.disable", true); - nah, too complicated
  • handled internally?,allowing plugins to take over in full page mode (in one code snippet), handled differently on android? see nsPluginHost.cpp. 599119#c21 which was 8 yrs ago, so pref is older than that. The only plugin now in 60+ is flash (maybe pdf also uses this)
• user_pref("network.proxy.no_proxies_on", "localhost, 127.0.0.0/8, 192.168.0.0/24, 10.0.0.0/8"); - nah, not fucking with people proxy settings
  • blank in TBB 7.5.6, default in FF61 "localhost, 127.0.0.1"
  • Options>General>Network Proxy>Settings>No Proxy for...
• user_pref("browser.sessionstore.max_resumed_crashes", 0); - nah
• user_pref("media.benchmark.vp9.threshold", 0); 1436226, tor 22548 - nah, let RFP cover it down the track
• user_pref("layout.css.font-display.enabled", false); 1157064

[Thorin-Oakenpants]

device sensors: We can ignore proximity & ambient light

• FF62+ https://www.fxsitecompat.com/en-CA/docs/2018/ambient-light-and-proximity-sensor-apis-have-been-disabled/
• https://bugzilla.mozilla.org/show_bug.cgi?id=1462308

[earthlng]

user_pref("pdfjs.disableAutoFetch", true);
// TBB 7.5.6=false, FF61=true. If false, only renders pages that are visible, see github

I don't think this makes any difference. It's very unlikely that a pdf exploit would need to wait until you load page 3 or whatever. That may be also why TBB removed the pref again IDK.

[grauenwolfe]

user_pref("browser.search.isUS", false); // (hidden pref? may depend on locale, etc) DXR

@Thorin-Oakenpants
That link is for Nightly or Beta isn't it? It can be found enough in DXR Release.

I haven't moved to FF62 yet, maybe it's gone already and I don't know if it's used or not but since it's still in DXR I only assume it is. Similarly, I don't how regularly DXR gets updated (seems to always be current) so who knows but I went ahead and added it as "true" because of this bit:

Tell the search service we are running in the US. This also has the desired
side-effect of preventing our geoip lookup.

Probably one of the least worrying prefs out there. Just wanted to be clear it is still around on Release channel.

[earthlng]

the code that used network.cookie.blockFutureCookies was removed in 61

proof:
https://dxr.mozilla.org/mozilla-esr60/search?q=blockFutureCookies ==> still used in ESR60
https://dxr.mozilla.org/mozilla-release/search?q=blockFutureCookies ==> no longer used in Release (62)

[Thorin-Oakenpants]

started a nah section in OP. Still mulling over the ESR thing - it would make life easier

[earthlng]

browser.search.isUS removed in 62

[Thorin-Oakenpants]

browser.disableResetPrompt is pretty much useless (for us). It's only a prompt (users can ignore it). The prompt only triggers if your profile hasn't been used for 60 days (eg when reinstalling and it picks up an old profile etc).

• DXR: https://dxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js#1297

moving to nah section

[Thorin-Oakenpants]

Moving to nah section. I do not think these are privacy/security/FP'ing/tracking issues anyway.

---1

browser.meta_refresh_when_inactive.disabled, ooh a double negative naming convention

• https://bugzilla.mozilla.org/show_bug.cgi?id=518805#c9

This is controlled by browser.meta_refresh_when_inactive.disabled, which is false (allow refreshes) on desktop, and true (disable refreshes) on Fennec

It's a battery thing for mobile. If you search DXR you can see the default for mobile is true, false for everything else.

---2

accessibility.blockautorefresh - if you read the linked KB says

Instead of refreshing a page automatically when is present (or Refresh HTTP headers), display a browser message indicating the refresh and allow the user to follow it manually

This used to be under Options as “Warn me when web sites try to redirect or reload the page”

Not sure (I am but one person) how prevalent this is on the web these days, but I would find a browser prompt annoying. If a site requires auto-refreshing for content etc, big deal.

Redirects are a different matter. I don't think this pref is the answer. I miss the legacy NoRedirect, but in the meantime, I think the damage redirects can do is mostly mitigated by other means - well, at least for me (hardened uM with default no JS)

What damage can redirects do? Send you to a malicious site? Send you on a ticket clipping ad network ride? IDK, we already have mechanisms to make most of that a moot point

What are your thoughts @earthlng

[Thorin-Oakenpants]

^^ bump > What are your thoughts @earthlng

[earthlng]

yeah IDK. Refreshes work even when JS is disabled and can be quite annoying when they're used to redirect non-JS users to a warning page or something like that. But I tend to agree that it's probably not worth adding to the user.js

[Atavic]

user_pref("general.useragent.site_specific_overrides", true);

If True, you can create entries like: general.useragent.override.soundcloud.com

and give it a value corresponding to the UA you want to use on that URL:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:99.9) Gecko/20100101 Firefox/99.9 (Pale Moon)

[Thorin-Oakenpants]

/* 0710: disable GIO as a potential proxy bypass vector
 * [1] https://bugzilla.mozilla.org/1433507
 * [2] https://en.wikipedia.org/wiki/GIO_(software) ***/
user_pref("network.gio.supported-protocols", ""); // (hidden pref)

• Did I get the right link for "GIO", or is it something else entirely?
• Excuse my ignorance ^^see above q^^, but does this means that the pref is applicable to [LINUX] only?
• Is 0710 OK? Its directly related to networking protocols: SMB (Server Message Block), SFTP (take your pick: SSH File Transfer Protocol, Secure file transfer program, Simple File Transfer Protocol - I have NFI which one it applies to).
• Maybe ditch the wiki link (assuming I got it right), and just expand on the description to say that this blocks SMB and SFTP?

[Thorin-Oakenpants]

I think we should flip 1403 entirely. Making prefs active should "harden" things. Currently it's the reverse. Default is true which is what we are currently enforcing. Make it inactive, and add the delay pref.

/* 1403: disable icon fonts (glyphs) (FF41) and local fallback rendering
 * [1] https://bugzilla.mozilla.org/789788
 * [2] https://trac.torproject.org/projects/tor/ticket/8455 ***/
   // user_pref("gfx.downloadable_fonts.enabled", false);
   // user_pref("gfx.downloadable_fonts.fallback_delay", -1)

Nits?

Edit: Note on why it was at active true: I assume it's because too much broke for end users when false, and we can always control third party fonts with uM - or is this something else - fonts confuse me, @font-face is usually 3rd party right?. At inactive false, anyone who flips it themselves, then the breakage is on them.

[Thorin-Oakenpants]

MOAR fonts: user_pref("layout.css.font-display.enabled", false); 1157064

• this seems to tie in with all that fallback stuff above? Not sure if this is too integral now - I did disable it in testing the browserspy.dk font thing a week or so ago, and I'm on document fonts = 0, and I saw zero issues/differences when browsing. It was "experimental" but that was 3 years ago
• What is the value in TBB latest 8? I don't have one handy. If anyone can let me know, cool. If not I will DL TBB tomorrow and look.

Edit: PS:

google: No results found for site:trac.torproject.org "layout.css.font-display.enabled"

Edit2: Is this just a master switch for killing @font-face? I am soooo confused right now

[earthlng]

GIO:
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/gio/nsGIOProtocolHandler.cpp#920

// Gvfs/GIO has a set of supported protocols like obex, network, archive,
// computer, dav, cdda, gphoto2, trash, etc. Some of these seems to be
// irrelevant to process by browser. By default accept only smb and sftp
// protocols so far.

---

does this means that the pref is applicable to [LINUX] only?

I'm not sure. LINUX for sure and perhaps MAC, IDK.

Is 0710 OK?

👍

Did I get the right link for "GIO"

yes I believe so. We should also add https://en.wikipedia.org/wiki/GVFS and maybe a link to the TBB trac issue so users can immediately see that it's a hardening thing also used in TBB:

/* 0710: disable GIO as a potential proxy bypass vector
 * Gvfs/GIO has a set of supported protocols like obex, network, archive,
 * computer, dav, cdda, gphoto2, trash, etc. By default only smb and sftp
 * protocols are accepted so far. (as of FF64)
 * [1] https://bugzilla.mozilla.org/1433507
 * [2] https://trac.torproject.org/23044
 * [3] https://en.wikipedia.org/wiki/GVfs
 * [4] https://en.wikipedia.org/wiki/GIO_(software) ***/
user_pref("network.gio.supported-protocols", ""); // (hidden pref)

[Thorin-Oakenpants]

we can squeeze that text into 2 lines (both under 100chars), I'll do a commit

[Thorin-Oakenpants]

FYI: pdfjs.disableRange doesn't honor OA: 1506693, which I've been following in tor 26540. When this lands, I assume it will not just be ESR60, in which case the pref can probably be ignored. I'm not sure how this ties in to pdfjs.disableAutoFetch but I'm inclined to put both on the ignore list

[Thorin-Oakenpants]

moved to NAH

• general.useragent.site_specific_overrides
• accessibility.indicator.enabled

---

• security.mixed_content.block_object_subrequest
  • added the bugzilla 1190623. I'm in two minds: screw Flash but then I also don't see any any movement on this getting flipped, and it does no harm (we can always remove it after the next ESR cycle assuming it's flipped by then). So where would we add it? 1243 seems the appropriate place (1242 is taken in deprecated). Otherwise, it would fit under the 1800s

/* 1243: block http-subrequests triggered by Flash (FF59+)
 * [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1190623 ***/
user_pref("security.mixed_content.block_object_subrequest", true);

👍 or nits?

[earthlng]

1243 seems the appropriate place (1242 is taken in deprecated)

👍

maybe include MitM in the title? for example

Block plain text requests from Flash plugins on encrypted pages to mitigate MitM attacks

or "Block unencrypted requests ...".

I'm not sure if "http (sub)requests" is appropriate because unencrypted websocket requests are probably possible in Flash as well (ws://... instead of wss://)

[Thorin-Oakenpants]

I got mixed up with the two ping-center prefs and in my head associated them with Pingsender (which is external to FF and probably bypasses proxies etc), and I wanted to future-proof.

But ping-center is a different thing. Current js has:

/* 0506: disable PingCentre telemetry (used in several System Add-ons) (FF57+)
 * Currently blocked by 'datareporting.healthreport.uploadEnabled' (see 0333) ***/
user_pref("browser.ping-centre.telemetry", false);

This info is 7 releases old, NFI what's changed. I'll do a DXR search later. Assuming 0333 is the master switch to 0506 which in turn controls use of the two prefs in OP .. do we really need to clear them? (I do like future proofing, and multiple fallbacks)

[Thorin-Oakenpants]

https://dxr.mozilla.org/mozilla-central/source/browser/modules/PingCentre.jsm is the only place I can find these prefs (outside tests etc). The hard-coded countries with less than 10K users is interesting 1421422

FHR_UPLOAD_ENABLED_PREF still looks like a master switch, but I'm a moron, so I could be wrong.

Edit: FYI: land PingCentre FF57 => use PingCenter FF57

So lemme know: worth it to add the two prefs for in-depth defense?

[Atavic]

FHR_UPLOAD_ENABLED_PREF appears into browser_healthreport.js and it's master switch is
0333

[Thorin-Oakenpants]

FHR_UPLOAD_ENABLED_PREF appears into browser_healthreport.js and it's master switch is 0333

Yup, I know. I was just referencing the constant to save time

[Atavic]

worth it to add the two prefs for in-depth defense?

I clear most of the child entries, even if the master switch is disabled.

[earthlng]

worth it to add the two prefs for in-depth defense?

the code using the endpoint URL is never reached because it returns early if either datareporting.healthreport.uploadEnabled or browser.ping-centre.telemetry are set to false.
Feel free to add them if you want but IMO it's unnecessary bloat.

[earthlng]

NAH to device sensors and WebVTT

[Thorin-Oakenpants]

all moved to NAH

• pdf stuff
• wasm extras
• webvtt
• those three items at default
• plugin.disable
• proxy stuff
• SR max resumed crashes
• media.benchmark.vp9.threshold
• layout.css.font-display.enabled

[Thorin-Oakenpants]

can't be bothered with the rest. I don't get the BS with the handlers, block everything and have to allow all the exceptions.

As for the other two prefs left, or some I just moved to nah .. if anyone ever does any research or feels like sharing, by all means, speak up.