PSA: warning to all Firefox users that install add-ons

the problem

there’s a long-standing bug with Firefox involving the use of Content Security Policy (CSP) to modify HTTP headers in that if two or more add-ons employ CSP, only one will be able to modify headers and it’s a roll of the dice as to which one wins - in short, it is suggested to not install more than one add-on that leverages CSP - uBlock Origin uses CSP and it’s a major player for many of us in the privacy arena - so does uMatrix, CanvasBlocker and HTTPS Everywhere, but it can be disabled in these add-ons

how to check if an add-on uses CSP

you need to search the add-on source code for “content-security-policy” - you could unpack the add-on and search the files, or you could do it the easy way by installing Extension source viewer - when you’re on the AMO site, search for the add-on you want to check, then use ‘Extension source viewer’ to view the source code - there’s a search input in it and you can enter the following (the preceding exclamation char tells it to look at file content instead of file names):
!content-security-policy
it will then list the files containing CSP if any are found

configure uMatrix, CanvasBlocker and HTTPS Everywhere to avoid CSP issues

Extensions - ghacks user.js wiki
regarding HTTPS Everywhere, consider HTTPZ instead - it’s much lighter and doesn’t rely on (inaccurate) human created lists

more info

Content Security Policy (CSP) - Mozilla
unofficial: the extension csp header modification game - ghacks user.js issue
Bug 1421725 - finalize how changing headers should work
- Mozilla
Extensions - ghacks user.js wiki

3 Likes

I personally advise against httpZ espeically because it does not rely on a list. If a domain supports https on the list, then you will be sure that it will never connect to the http version, where httpz will just try it out and then fallback to plain http.

1 Like

i understand your concerns but i think it’s not completely accurate to say that “httpz will just try it out and then fallback to plain http [if https fails]” because it will not fallback without first prompting the user

i get that httpz could downgrade the connection for a site that normally supports https if something is wrong such as a recent or temporary configuration problem on the server, etc., but if the https connection can’t be made, then HTTPS-E can’t make it either and from what you’re saying it seems it will simply block the connection without ever offering the user a choice

then there’s ‘x’ number of URLs that aren’t in the HTTPS-E list for which it will, i assume, allow the http connection whereas httpz would have attempted https first, or websites which did support https but for whatever reason don’t anymore and haven’t been changed in the lists, etc., and all of this is taking place in a very dynamic environment in which it makes no sense to me to have to rely on static lists (and a 20+ MB hit on RAM to hold them) and humans to find and fix all these problems when we have computers that can automate the process

then there’s the CSP issue which affects HTTPS-E, where if someone fails to disable ‘Encrypt All Sites Eligible’ and they use other critical add-ons that need CSP to protect privacy (uBlock), they’re screwed - and if they DO disable ‘Encrypt All Sites Eligible’, i would assume the advantage of HTPS-E is further eroded

from my POV, and given all of the caveats with HTTPS-E and considering the very real CSP issue, i’m not seeing where it makes any sense to recommend it

the only possible advantage i see with HTTPS-E is when a site links to a http resource that supports https in which case httpz won’t (or may not, because work was recently don in this regard) upgrade the http resource, but i think that is offset by the option in FF to disallow connecting to secure sites that link to http resources, so even that isn’t a significant advantage it seems and i think that’s the default FF behavior now