user.js: sticky: Prefs vs Recommended Extensions: Co-Existance+Enhancement | Conflicts

A list of stuff - thanks @smithfred for the ideas

Extensions can often work better than a global pref because of their flexibility (but may still have downsides or issues), or they can enhance/compliment them, or they can clash. Either way, there is always more than one way to skin a cat ^{no cats were harmed in the making of this issue}.

Here are some solutions that may fit your needs. If you have any other suggestions to this list-in-progress, please let us know 😃

---

🔶 Mixed Passive Content

• pref: security.mixed_content.block_display_content=true (1241)
• alternative:
  • set the pref to false
  • add https-strict: * true to uMatrix
  • allow exceptions on a site by site basis

---

🔶 Web Workers

• pref(s): dom.workers.enabled=false (2301) and/or dom.serviceworkers.enabled=false (2302)
  • Note: dom.workers.enabled was removed in FF60
• alternative:
  • set the pref(s) to true
  • add no-workers: * true to uMatrix
  • allow on a site by site basis
• note:
  • FYI: uMatrix (and FF) can’t use workers if cookies are set to “Keep until I close firefox” 1429714
  • if FF prefs allow web workers, but uMatrix blocks them, there may be instances where the web site detects workers are available but can’t actually use them, leading to breakage, rather than falling back to the non-web-worker version [read this somewhere on uM repo but can’t find it now]

---

🔶 Cookies [1]

• pref: network.cookie.cookieBehavior=2 (block all) (2701)
  • use FF site exceptions (allow eg for logins, allow for session eg for sites that require them to work)
• alternative:
  • set pref to allow cookies (recommended value of 1 for same host only)
  • add * * cookie block to uMatrix
  • allow on a granular level
• notes: uMatrix wiki on cookies
  • “Blacklisted cookies are not prevented by uMatrix from entering your browser. However they are prevented from leaving your browser”
  • This is about standard HTTP Cookie header. Cookies can still be read, and sent to remote servers by javascript in other data structures (POST request for example)
• issues:
  • cookies control other persistent storage (local storage, IndexedDB), both when allowing creation and for FF and extensions when cleaning. While uMatrix has a setting to automatically delete blocked cookies, currently FF/Extensions have issues/limitations with sanitizing/FPI. Just removing a cookie can leave behind orphaned persistent data ^{99% sure AFAIK}

---

🔶 Cookies [2]

• pref: network.cookie.cookieBehavior=2 (block all) (2701)
  • use FF site exceptions (allow eg for logins, allow for session eg for sites that require them to work)
• alternatives
  • set pref to allow cookies (recommended value of 1 for same host only)
    • I think Cookie Autodelete requires cookies to be enabled or it won’t work
  • cookie extensions
• notes
  • these block/allow cookies coming in. They allow lots of flexibility (white-black-greylists, auto-clearing on tab close etc), and will one day be able to properly handle related persistence storage and FPI (see issues for Cookies [1])

---

🔶 Canvas

• pref(s): privacy.resistFingerprinting=true (4501) (RFP)
  • so much is bundled under this pref that it is not feasible to set it to false
  • for the gazillion things RFP does see #7
• alternatives:
  • CanvasBlocker (or similar)
• notes:
  • RFP canvas protection currently prompts for every site (but can remember site permissions). In FF59+ canvas has been added to the PageInfo>Permissions panel. RFPCanvas might have a pref for its default permission (but looks unlikely). Hopefully it will also be added to the options Site Preferences section for site management. Update: preferred fix is to restrict/lower the prompts
• strategy:
  • set CanvasBlocker to fake. Do NOT set to block as this will disable the API and you will not get the same result as RFP.
  • block sites when prompted: RFP takes over and CB is never used
  • allow sites IF you must: RFP allows CB to take over which will fake
  • use a CB whitelist for sites that MUST have the real thing

---

🔶 Referers

• pref(s): section 1600
  • these are global settings, and at defaults and in our user.js, they only limit some data in some cases (otherwise way too much of the internet breaks)
  • if you want ANY real control over referers, you NEED an extension
• terms:
  • source: the site you loaded, 1st party
  • destination: a site linked to, or the site being requested for 3rd party content
  • example:
    • load SiteA (SOURCE, 1st party)
    • SiteA requests content from 3rd party SiteB, SiteC, SiteD (B,C,D are DESTINATION)
    • SiteA might include a referer (basically saying “Hi I’m requesting this for SiteA”) to any or all of those destination sites
• EXTRA Solution 1: uMatrix
  • spoof by default: referrer-spoof: * true
    • Dashboard>Settings>Privacy>“Spoof HTTP referrer string of third-party requests”
    • uMatrix spoofs any referers as the destination (see this uMatrix wiki entry)
  • allow exceptions on a per scope basis (this is under the three vertical dots dropdown in your uMatrix panel)
  • uMatrix can only control the SOURCE, not per DESTINATION (so in the example above, Sites B C + D would all get referers)
• EXTRA Solution 2: Smart Referer (instead of uMatrix’s setting)
  • whitelist, blacklist, built-in whitelist to reduce breakage, etc
  • allows source-destination control: so in the example above, you could allow SiteB but still block Sites C + D
  • allows blocking, spoofing as destination, faking, allowing, etc
  • the ultimate referer tool