User.js: spring cleaning part 2

[earthlng]

@Thorin-Oakenpants wrote:

Am trying to cut down the user.js if I can

a few things we can remove IMO:

• [x] user_pref("dom.allow_scripts_to_close_windows", false); - https://github.com/ghacksuserjs/ghacks-user.js/commit/449e32a8ca8d46ff6499d27ee1bed01e4c525b2c
  
  
  
  • default false (even in ESR52)
  
  
  • 1 of the prefs in PK's ignore.list
  
  
• [x] user_pref("dom.disable_window_flip", true); - https://github.com/ghacksuserjs/ghacks-user.js/commit/449e32a8ca8d46ff6499d27ee1bed01e4c525b2c
  
  
  
  • default true (even in ESR52)
  
  
  • in PK's ignore.list
  
  
• [x] 2733 (offline-apps.quota.warn) & maybe 2732 (browser.offline-apps.notify) - https://github.com/ghacksuserjs/ghacks-user.js/commit/f60a87f97f2d394441313bd4aa98dbc0a33de3be
  
  
  
  • was never active and we enforce sites to ask with 2731 + 2732 regardless of any quota
  
  
  • not in PK's user.js either
  
  
  • the text could be misunderstood to mean that FF will bypass the prompt enforced by 2731:
    
    FF will store small amounts of data in the offline cache without asking for permission.
  
  
• [x] user_pref("network.http.fast-fallback-to-IPv4", true); - https://github.com/ghacksuserjs/ghacks-user.js/commit/c66d1b08e7c634d3a8aa3da8134d1c364fe98a1b
  
  
  
  • default true (including ESR52)
  
  
  • I'd also like to disable IPv6 but that's another issue
  
  
• [x] double entry for 0422 - https://github.com/ghacksuserjs/ghacks-user.js/commit/01bd2a4f6d414f0c877afefe69356444e050f08a
  
  
  
  • Basic is the default anyway but another problem is that selecting strict via the UI just adds ,content-track-digest256 to the default value. If that default value changes or they change/rename the part that gets appended, we would fuck up people's configs. We will see changes to the default value in the diffs but not changes to the to-be-appended part.
  
  
• [x] 0101: browser.slowStartup.maxSamples & browser.slowStartup.samples & browser.slowStartup.notificationDisabled - https://github.com/ghacksuserjs/ghacks-user.js/commit/3edf7af85eb6f0bf9690e17b2100c5ff62e3fa3d & https://github.com/ghacksuserjs/ghacks-user.js/commit/3e5667fb3438bce37ad7e504f8625f6af7562acc
  
  
  
  • see comment below
  
  
• [x] 0101 browser.rights.3.shown - https://github.com/ghacksuserjs/ghacks-user.js/commit/f113cf84c33771ce6be58c06fccf75ef1468f248
• [x] 0101 4 x new profile/update welcomes/whatsnew -> personal, inactive - https://github.com/ghacksuserjs/ghacks-user.js/commit/acc5a1c2df5ed3cd12d551bfaf16505589f5d158
• [x] 0101 browser.laterrun.enabled - https://github.com/ghacksuserjs/ghacks-user.js/commit/9b1cf28e89d964e09de295d95639a8f25fb38f55
• [x] add removed prefs to scratchpad script - https://github.com/ghacksuserjs/ghacks-user.js/commit/8e60f412e47453c798e83c530e0bb2570386c143

[Thorin-Oakenpants]

I actually think that offline-apps.quota.warn hasn't worked for years - I swear I've seen a few bugzillas about it.

[Atavic]

Never worked here in years.

[Thorin-Oakenpants]

offline-apps.quota.warn introduced in 2008 in 397416 and then 8 yrs ago 621158 someone said it didn't warn you if it was in a iframe. Not much else I can find in a quick search. Would be totally surprised if that's been working flawlessly for over 10 years.

I think we need to make it clear (and check) that offline use is NOT the same as appCache. 2731+32+33 are not 2730 AFAIK.

On a side note: The whole new Storage v2 will probably make a diff

Edit:

• https://bugzilla.mozilla.org/show_bug.cgi?id=959985 = wontfix
  
  
  
  • that's 2732 browser.offline-apps.notify doesn't do anything
  
  
  • If so, that would make 2731 offline-apps.allow_by_default useless
  
  
  • and 2733 offline-apps.quota.warn just as useless
  
  

Maybe we should just ditch the lot. But find a test first!

[earthlng]

testpage: http://webdbg.com/test/appcache/ - you need to allow appcache on insecure sites!

1. All of 273x IS about the same thing ie offline cache aka appCache
   
   
   
   • you can also verify that this is the case via about:cache. It's listed under appcache but the file is called OfflineCache and when you set browser.cache.offline.enable to false the Storage disk location changes to none, only stored in memory
   
   
2. offline cache is kinda useless anyway in our case because we clear it on shutdown
3. the warning pref DOES work but isn't of much use (all 3 prefs DO work, at least to some extent: maybe the warning isn't displayed if it's in an iframe, IDK). If you set it to 1kb you'll get this message:
   
   By default you'll only get this message when a site stores more than 50MB
4. 2732 browser.offline-apps.notify is default true even in ESR52 so we can remove that as well IMO. If you'd set this to false you would not get the above warning message
5. the important pref here is offline-apps.allow_by_default which controls the prompt to allow or block appcache access

[Thorin-Oakenpants]

This is semi-confusing AF, because 2730 we tested and it did prompt (when we make that pref inactive due to the Site Data UI). But with 2731+ in those examples and in the above test, it doesn't prompt, it only tells you (if you lower the warning quota). There's some difference here.

Its also a tad confusing with ESR52.x, eg there is no "Maintain offline storage" site permission in FF60

Long story short, it's pretty much deprecated as a technology (since FF44 I believe, hence why no one cares about it), replaced by SW.

https://bugzilla.mozilla.org/show_bug.cgi?id=959985#c8

appcache is being replaced by serviceworkers.. only critical fixes are accepted in the interim.

[1] https://www.fxsitecompat.com/en-CA/docs/2016/application-cache-support-will-be-removed/
[2] https://www.fxsitecompat.com/en-CA/docs/2018/support-for-application-cache-on-insecure-sites-has-been-deprecated/

Given that FF60+ (pref 2730b) means its only non-secure sites, and given the rapid uptake now with HTTPS, exposure is low IMO. Doesn't help ESR52.x though (you dinosaurs!).

BUT, it does exist in the wild. Clearing on exit is one thing, but does nothing to block it being stored in the first place (for tracking in the same session). But again, low risk IMO. However, we don't have a complete solution, and probably never will.

I suggest based on defaults for ESR, remove as much as possible of 2731+32+33?

[Thorin-Oakenpants]

I suggest based on defaults for ESR, remove as much as possible of 2731+32+33

• 2732: user_pref("browser.offline-apps.notify", true);
  
  
  
  • both ESR52.8 + FF60 are default true
  
  
• 2733: // user_pref("offline-apps.quota.warn", 51200);
  
  
  
  • both ESR52.8 + FF60 are the same default
  
  
  • was only ever added as inactive with defaults as a FYI (hence why it matches)
  
  

These TWO can be removed, IMO.

• 2731: user_pref("offline-apps.allow_by_default", false);
  
  
  
  • both ESR52.8 + FF60 are default true
  
  

:+1: if this is OK, or throw :hankey: 's at me

[Thorin-Oakenpants]

new 0422 ?

/* 0422: set Tracking Protection list to use: "basic" or "strict" 
 * If you wish to use "strict", use the preferences UI to get the correct pref value
 * [SETTING] Privacy & Security>Tracking Protection>Change Block List
 * [SETTING-ESR52] Privacy>Use Tracking Protection>Change Block List ***/
   // user_pref("urlclassifier.trackingTable", "test-track-simple,base-track-digest256"); // basic (default)

note: also changed "enable" to "set", because it might implies that this is the TP enabling pref. Also "tracking protecting" -> "tracking protection" :+1: or :hankey:

[earthlng]

I'd prefer something like this (without listing the pref):

/* 0422: enable "strict" Tracking Protection list
 * [SETTING] Privacy & Security>Tracking Protection>Change Block List
 * [SETTING-ESR52] Privacy>Use Tracking Protection>Change Block List ***/

maybe with a note like "There's a pref for this but it's hard to keep track of and we don't recommend to add it to your user.js."

There's also this: https://www.bleepingcomputer.com/news/software/firefox-63-to-get-improved-tracking-protection-that-blocks-in-browser-miners/

The Firefox browser's Settings >> Privacy section now features an enhanced Tracking Protection panel that also allows users to select what anti-tracking features they can enable.

with Firefox 63, Tracking Protection will also receive support for blocking user fingerprinting scripts and in-browser miners (also called cryptojackers).

which I guess will change the TP prefs + their values quite a bit.

[Thorin-Oakenpants]

I'd prefer something like this (without listing the pref):

I spose. I like the pref being there, because it maps the UI to the pref. Although 0902 doesn't have one, but added to make a complete 0900s. We can always look at it again in 63

@fmarier should be able to give us some insight on the strings used

[Thorin-Oakenpants]

Haven't read the articles yet, but saw them earlier (eg reddit). I would suspect that the pref will just concatenate the selected lists with a delimiter

[fmarier]

Haven't read the articles yet, but saw them earlier (eg reddit). I would suspect that the pref will just concatenate the selected lists with a delimiter

Yes, that's what it does. Switching to the "strict" list for example, adds the content-track-digest256 list to urlclassifier.trackingTable. That's the difference between basic and strict.

This crypto-mining and fingerprinting stuff will show up as new lists (probably something like miners-track-digest256 and fingerprinting-track-digest256 TBD).

[earthlng]

Found 2 more to remove

user_pref("browser.slowStartup.maxSamples", 0);
user_pref("browser.slowStartup.samples", 0);

the slowStartup function immediately returns when browser.slowStartup.notificationDisabled is true, in which case those 2 prefs are never used.

IDK if we need to disable the slowStartup check at all. It's kind of nice to be able to see the average startup time (stored in browser.slowStartup.averageTime). And I don't think disabling it improves startup time by all that much.

All it does is measure average startup time and if it's higher than the value of browser.slowStartup.timeThreshold (+ the profile age is older than 3 months) it shows a message with 2 buttons: help + disableNotification. Clicking "Help" just opens https://support.mozilla.org/kb/reset-firefox-easily-fix-most-problems in a new tab.

[Thorin-Oakenpants]

And I don't think disabling it improves startup time by all that much.

I don't think you'll care about it when you move from ESR52 :snail: to 60 :rocket:

[earthlng]

then why not remove browser.slowStartup.notificationDisabled too? it's not security/privacy related

[Thorin-Oakenpants]

true. I considered it. Its similar to 0000 general.warnOnAboutConfig. Once you set it on a prompt, its done. We could also get rid of rights, welcomes,. update notices.

[earthlng]

Can we draw a line in the sand somewhere?

yeah np, was just an idea

[Thorin-Oakenpants]

I'm actually happy to remove browser.slowStartup.notificationDisabled - I mean if you have a shitty startup, why wouldn't you want to be told about it (and you then have an option to disable future notifications). I will remove it.

My point was your distinction about it being non-privacy/security. So I was just trying to be consistent. All that 0101 stuff really does belong in the 5000s. This them allows us to make some 5000s active based on overrides. I also think most of the 0101s are first runs (welcome urls? rights?) and we could lose that crap if we wanted to. Ideas welcome - keep em coming.

[Thorin-Oakenpants]

browser.rights.3.shown was introduced in FF 3.1b2 (remember the good ole days!! /s) see 462254 or rather this patch

DXR for both central and esr52 show its only in one place (well esr52 has it in a firefox.js as well which is just a massive list of pref values) - click here

I reset it in my FF60 (and commented it out in my profile user.js) and restarted several times. It doesn't seem to do anything. I really do not think this is even used anymore (come on, FF3!! A doorhanger for know your rights? it must have been replaced by something else, eg the urls loaded on new installs). I am not sure about a app update, but I could test - or you could maybe follow the code a little.

[Thorin-Oakenpants]

I did some testing.

FF 52.8: new profile: two pages load

• Welcome to FF ( https://www.mozilla.org/en-US/firefox/52.8.0/firstrun/ )
• FF Start Page
• browser.rights.3.shown = true
• reset to default false and restart
• it got changed back to true

FF60 new profile: two pages load

• Welcome to FF ( https://www.mozilla.org/en-US/firefox/60.0.1/firstrun/ )
• FF Privacy Notice ( https://www.mozilla.org/en-US/privacy/firefox/ )
• browser.rights.3.shown = false

AFAICT, ESR52 just sets the sucker regardless to true, and FF60 ignores it entirely

[earthlng]

browser.rights.3.shown was removed in FF62 but there's a ticket for maybe bringing it back as part of Activity-Stream: https://bugzilla.mozilla.org/1463277

also see this comment

In ESR I think it's shown on the FF Start Page (about:home) the 1st time it loads.

Up to you whether you want to remove it now or wait for FF62 and then move it to 9999.

---

while digging in the code I also noticed that the following 3 prefs are never used when browser.startup.homepage_override.mstone is set to ignore

user_pref("startup.homepage_welcome_url", "");
user_pref("startup.homepage_welcome_url.additional", "");
user_pref("startup.homepage_override_url", ""); // what's new page after updates

these pages are just shown once after each update/upgrade or in new profiles. If someone actually wants to see (some of) them, commenting out just (some of) those 3 prefs won't do anything.
We could do something like this:

/* 010x: disable all "Welcome" and "What's new" pages ***/
   // user_pref("browser.startup.homepage_override.mstone", "ignore");
/* 010xb: disable the "Welcome" or "What's new" pages ***/
   // user_pref("startup.homepage_welcome_url", "");
   // user_pref("startup.homepage_welcome_url.additional", "");
   // user_pref("startup.homepage_override_url", ""); // What's New page after updates

[Thorin-Oakenpants]

Thanks for the links - the rights pref is pretty much "dead" AFAIC (so it moved to a snippet, and since 57 hasn't been factored in at all, etc). Most of these 0101 prefs came from a TBB patch, and I guess this was so they didn't show mozilla's legal info etc. It's a non-event pref (re privacy/security) so it can go rather than clutter up deprecated.

I need to think about the startup messages. What's so bad about being told you updated (esp when auto-updated)? Can't see it being annoying really with how few dot releases are done. If we keep them, they could go in personal, or in keeping FF quiet, or stay in startup.

I also want to check out laterun (and yeah, fix up that title and description)

[Thorin-Oakenpants]

https://dxr.mozilla.org/mozilla-central/source/browser/modules/LaterRun.jsm is interesting .. 50 sessions or 1 month ..

I think we could ditch this (only did a quick search, need more info on what it does), but not probably make it commented out in the removed.js

[nostromov]

Not trying to spam (just an honest question!), bt the whole trackingprotection deal; do you guys, actually, use it?!

As we've got various ad-blockers, script-blockers and /or other Add-ons - who's using the built-in lists?.. Would it not make more sense to go around Mozilla, since we're excluding - pretty much - everything else??

o.0

[Thorin-Oakenpants]

If you use the user.js as is, then TP is off - its only on in PB mode by default. Personally, I never use PB mode because one off windows are not automated (i.e domains can't be assigned to auto-magically use PB mode, unlike containers), so therefore I never use TP.

That said: it can't hurt .. if at least one entity blocks a request, then it is blocked (eg if uBO allows it thru, but TP blocks it, then it is blocked: and vice versa), so it really comes down to efficiency of lists and overhead. The user.js defaults don't block TP, i.e they are inactive, so at least users can flip on some extra protection, eg from the UI, and the user.js doesn't interfere. So there is no benefit in disabling it, but the info is there for those who want to.

[Thorin-Oakenpants]

so ... where are we at

/* 0101: disable some startup options ***/
user_pref("browser.laterrun.enabled", false);
user_pref("browser.shell.checkDefaultBrowser", false);

I will dig some more into laterrun (looks likely I will ditch it). That leaves default browser check, which leaves me in two minds - it is a privacy/security setting in the sense that wouldn't you WANT your external links to opened in your FF - and if something else takes over the file associations etc you would WANT to be notified.

On the other hand, you can't do this in FF portable (I have no idea how Linux works with this) since the file set as the default is FirefoxPortable.exe, not firefox.exe (either in the respective 32 or 64 bit app/ sub dirs). And if anyone clicks "yes" when prompted with portable, when you relaunch, it acts like an installed version and creates a new profile (on windows) under username/appdata or whatever it is.

Also, as soon as I move to 61-alpha (when I can close this), startup page options/settings UI changes in 61, so we can update 0102+0103 and 0514 - and also look at including FYI browser.newtab.url eg as about:blank (which is one of the drop down options)

[earthlng]

I will dig some more into laterrun

looking forward to hear what you uncover :trollface:

browser.newtab.url was removed a long time ago.
The 2 drop down option prefs are browser.startup.homepage and browser.newtabpage.enabled

[Thorin-Oakenpants]

browser.newtab.url exists in my shiny FF60 - update: it's been set by an extension which I installed in FF57, I just assumed the modified value meant it actually existed. Remnants in FF52.x

But sure. We'll clean up those prefs

[Thorin-Oakenpants]

hmmm still not entirely sure what a laterrun is. But the default in FF60 is false. BRB, will check in 52.8. Update: 3x laterrun* prefs in ESR52.8, .enabled is true (modified, set internally), if it's reset, it defaults to false.

Note: https://bugzilla.mozilla.org/show_bug.cgi?id=1200639

[Thorin-Oakenpants]

^^ I think it's safe to remove laterrun from the js. Most users are well past the session number and time since install (don't know exactly what the threshold). It's also gone in 60 branch. Can also add it to the removed items not commented out, since default is false in both ESR & stable.

[Thorin-Oakenpants]

do we want to do anything about the default check pref? If not, I can close this, and after your DNT flip, we can move to 61-alpha and deal to the startup/newtab/homepage options

just lemme know what u want to do

[Atavic]

Prevent Firefox from opening a page on a second or later run and/or after some amount of time

Source

[Atavic]

Supported on: Windows 10

Source

[earthlng]

do we want to do anything about the default check pref?

no