"releases" which is the github term, is purposed for archiving legacy versions of the user.js. This is done *near* the end of each version's stable cycle (a week?), for the reasons given in the user.js. As soon as a "release" is done, the "live" version is incremented to the upcoming stable, and changes are started based on the diffs provided by earthlng.
I know it was there before 52, but it was flipped to true in 52 - unless someone wants to find when it was actually introduced, this is sufficient for people to use to be effective for versioning
shortened and evened out lines, added that extra link. I changed "Internationalized Domain Names" to IDNs to save space and then realized the kb and wiki articles don;t even say what IDN stands for, so I put it back.
Also swapped the order and wording of the pref to make it consistent with the action. Instead of
- "2672: eliminate possible .. show_punycode", true)"
- "2672: force Punycode .. show_punycode", true)"
my draft for network.IDN_show_punycode
added under 2600 but it would maybe also fit under 0800 (?)
the title and that one line are quite long, feel free to improve the wording etc.
- This is a rough draft, please read the old intro currently at the start of the user.js in the meantime.
- Paragraph here about not jumping in without reading first, and backing up, and understanding the changes
### Origins
- yada yada
### Purpose
- discuss why use a js (enforcement on startup, migration)
- outline trade-offs between security vs privacy etc
- explain expectations and site breakage
- explain this version is a "compromise" or balance that aims (with addons eg you WILL need uBlock Origin or turn safe browsing and tracking protection back on) to provide as much privacy and enhanced security as possible, and to reduce the fingerpritning attack surface as much as possible - while putting up with some incoveniences and as little site breakage as possible (but it will happen). It's only a starting point.
- provide troubleshooting: site breakage will happen. 90=% of the preferences cause no issues. It is only a small core of settings that people may or may not need to look at, depending on their objective.
- no one size fits all, this is a template, fork it! Customize it! (see goals, we won't set you wrong)
### Goals & Standards
To be **THE** template and resource all other user.js' come to for news, links, information and more, which means it needs to be:
- comprehensive (eg some prefs are included at default for completeness/enforcement, a lot are included and changed for future-proofing, etc)
- current and available and change-trackable (hey, we're on github now)
- easy to understand (good, simple, less-technincal descriptions)
- accountable and a resource (lots of links to authorative authors and tech papers, also repo wiki)
- correct and to dispell myths and bad advise (see accountable)
- eassy to follow and report and discuss (logical and numbered structure)
- give good advise (see trade-offs)
- expanded on with more information, such as FF version numbering for introduction and deprecation of preferences, hidden pref tags etc
- archived for each stable release (starting with 51)
- to provide illustrated wiki topics to help (help wanted please!)
- to make it as easy as possible for anyone to use a user.js and get it right for them
- to provide two or three future forks with differnent settings from "painless no-breakage no-addons" thru to a "super-hardened" version: for use with multiple profiles
### Implementation
- expectations of the user
- link to wiki on testing and tweaking in a portable FF first
- backup first: link to wiki article on backup & restore methods
- changing, resetting preferences: user.js and about:config
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Roman-Nopantski