spring cleaning #716
Comments
Reference:
|
Isn't it still enabled by default? |
Yea. I guess the missing OT: I only have like.. 17 unread notifications left now.. almost there! |
I aggree, defence in depth won't harm.
The same question. I personally doesn't have it. Also: /* 1602: ALL: control the amount of information to send
* 0=send full URI (default), 1=scheme+host+port+path, 2=scheme+host+port ***/
user_pref("network.http.referer.trimmingPolicy", 0);
/* 1603: CROSS ORIGIN: control when to send a referer [SETUP-WEB]
* 0=always (default), 1=only if base domains match, 2=only if hosts match ***/
user_pref("network.http.referer.XOriginPolicy", 1);
/* 1604: CROSS ORIGIN: control the amount of information to send [FF52+]
* 0=send full URI (default), 1=scheme+host+port+path, 2=scheme+host+port ***/
user_pref("network.http.referer.XOriginTrimmingPolicy", 0);IMHO this stuff should be controlled by extensions, allowing per-website settings for that. I have all of them 2 for long time with no brekage, but some years ago I have encountered a website, broken by that. I had to temporarily set them to 0 in order to use it. So maybe they should bs removed and an addon recommended. |
|
The first five numbered items, all we are doing is enforcing the default values that Firefox come with, and has been at for a long time, not even ESR users would be affected if we removed them. Oftentimes we flip something well before Firefox does, as they need to wait for the right time (when the metrics tell them breakage is down to low levels, or they've had time to test/develop it more), or slowly introduce it as part of a larger scheme (deprecating http). Whatever the reason we added them, there comes a time when we items like this just clutter the js adding unnecessary noise. The last two numbered items are inactive, always have been. And I wouldn't say they If I can remove 50 lines for end users to wade through, then lets do it. Look at how old they are: FF30, FF51, FF52 (for the ones we noted). They'll just get removed at some stage by Firefox itself, when they get around to it. They made sense to add when they first came out, but no longer |
|
0909 was a mistake, I meant 0906, will amend first post later, am doing my triple checking |
|
Just to be clear, I only want to remove items that don't do anything to enhance our goal. And that doesn't mean all of them - enforcing a default has benefits, e.g the highres timer pref recently deprecated (it was so ambiguously named, people were recommending to disable it), e.g the blocklist in I'm also mindful of the large number of inactive prefs, and for 95% of users, 90% of them are never read or used. Excluding deprecated and personal, there are 107 of them. This really needs reviewing. And anything to reduce active prefs is good too stats (excluding deprecated, personal, parrots)
That's a lot of things to trow at people. I am also aware of trying to be "comprehensive" and a one-stop shop for the info on stuff Clearing out this "dead wood" is just a natural part of the process, we've done it lots of times before. And well after the default has changed (to the "good" value, after FF testing/feedback etc). I only want to keep "dead wood" if it educates users |
|
I agree that it is better to take out unnecessary stuff when possible. What I didn't fully understand was what you guys were basing your decisions on when it came to enforcing values, but I'm sure the only reason I didn't fully get it is because I haven't been on top of things the whole time, and many of these dead wood items were discussed and added way before I even started getting involved. Anyway, thanks for the explanation, and don't pay me much attention. Prefs are not my specialty, after all. Actually, I don't even have a specialty. |
uMatrix should cover that, though. Personally, I wouldn't remove them from this template (at most make them inactive) but still, I think it would be better to leave that for the relaxed variant that is in the making. |
|
re referrer headers. The user.js has to work within it's scope, i.e assume the user has no extensions, as a fail-safe/fallback - but where we can, we will point out extensions Referrers is a minefield. Set it too lax (default), you leak too much info, too tight and things start to break (for most people: I don't seem to have an issue spoofing everything in uM - not a single domain scope override). The prefs are absolutely candidates to be in this user.js. And our settings are pretty relaxed, middle ground (AFAICT the only problem is badly configured or old routers). So whether to keep the prefs Compare with privacytoolsio's recommendations = probably loads of breakage (they just went with the hardest setting for all three they listed) But I have made a note to reword the section header. Watch the commits for my masterly wordsgirlship |
|
Also if we assume people read shit, there's #350 for stuff like that. |
|
a little something for 🐈 link |
|
Humans always mistaking their pets' intentions. They looked at each other thru the windows because they were just bored AF. Wouldn't be the case if they had something like.... A BOX |
|
I was more intrigued by the fact that both wimmins had shredded pants |
All of these are the same as default, checked back to ESR60 and Ff60. Except 2211 which is not considered an issue by TB for example, and it doesn't enhance anything IMO
- 0910 same as default for desktop. Android is the opposite, must be for a reason. Android is not really my concern. - 1005: always been inactive: one less warning to deal with - 1008: always been inactive. defaults are 60, 60
|
All done: 12 less prefs, and 39 more lines removed |
|
reopened for round 2: see OP |
|
|
|
yup: the bullet point says Edit: BTW: I have yet to check them, e.g 1703 wsn't flipped until 61. I'll have to think about it. I could just mark them to get removed for v68 release if they're still needed for ESR. PS: I'm just waiting for @earthlng to turn up and freak out over all the commits and stuff - I'm sure he'll point something out to me, and he'll probably be right!. Easy enough to put things back if I have to |
|
FYI: now 1 pref does not equal 1 number, but excluding those in the readme |
- no need to enforce defaults (except the second cross-origin) = less items in prefs and about:support - simplify header info - add in that you need an extension for real control: i.e for most people, e.g I use uMatrix and have never can to whitelist anything. Kolanich has been on settings of 2 for years and only found one broken site: these are anecdotal and don;t reflect the real world: which is why the settings are pretty relaxed - move the broken info out of header and onto the pref in a setup tag - reference: #716 (comment) - thanks Kolanich and 🐈
- no need to enforce defaults (except the second cross-origin) = less items in prefs and about:support - simplify header info - add in that you need an extension for real control: i.e for most people, e.g I use uMatrix and have never can to whitelist anything. Kolanich has been on settings of 2 for years and only found one broken site: these are anecdotal and don;t reflect the real world: which is why the settings are pretty relaxed - move the broken info out of header and onto the pref in a setup tag - reference: arkenfox/user.js#716 (comment) - thanks Kolanich and 🐈
Part 3
All these are same as default in windows ESR60, FF60, FF66, Android66 etc: physically checked, also checked DXr in case something sticks out for Mac/Linux.:Except where noted, everything is the same. Note I check ESR60 vs FF60 because sometimes ESR backports some pref flipping. Also checked TB just in case they did anything special with them.
0403: disable data sharing [FF58+]2663: enable warning when websites try to install add-ons2683: block top level window data: URIs [FF56+]2705: disable HTTP sites setting cookies with the "secure" directive [FF52+]2706: enable support for same-site cookies [FF60+]2730b: disable offline cache on insecure sites [FF60+]1703: enable a private container for thumbnail loads [FF51+]I'l leave this one in (we can revisit removing it when ESR60 reaches EOL), so strictly speaking we have never removed anything for a current ESR - even though ESR users should be using the archived versions: although I do get that we have improved/changed a lot of things since we put out v60 that aren't to do with new prefs.
Parts 1 & 2
suggestions
I will need to re-check current default, and ESR default (but ESR users should be using the archive version of the user.js, but still if we can avoid anything, it's a bonus), and also TB's settings. And yes, revisiting those 3 password ones that E suggested gone. I'm allowed to change my mindedit: earlier reference from E: #585 (comment)
🔴 same as default
same as defaults in windows 60, 66, ESR60, TB8 (all physically checked). Same as defaults in Android 66 (physically checked) except where noted below (2 don't exist and 0910 is the opposite, IDK why - must be a reason)
Also checked DXR (with as short a string as possible) just in case something might stick out: got nothing more from the above checking
0706: remove paths when sending URLs to PAC scripts [FF51+]0806: disable displaying javascript in history URLs0906: disable websites' autocomplete="off" [FF30+]0907: display warnings for logins on non-secure (non HTTPS) pages0910: disable autofilling saved passwords on HTTP pages and show warning [FF52+]2027: disable camera image capture [FF35+]2028: disable offscreen canvas2211: set max popups from a single non-click event2427: disable Shared Memory (Spectre mitigation)🔴 inactive & never used
1005: disable fastback cache1008: set DNS cache and expiration time (default 400 and 60, same as Tor Browser)copypasta error, I meant
09060909: disable formless login capture for Password Manager [FF51+]user_pref("signon.formlessCapture.enabled", false);Feel free to suggest anything else
@earthlng come in earthlng, this is major tom to ground control
The text was updated successfully, but these errors were encountered: