arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
9.97k stars 511 forks source link

uMatrix WE problem in combination with other WEs [Bug 1417249, 1477696, 1421725...] #265

Closed earthlng closed 5 years ago

earthlng commented 6 years ago

@gorhill, I found a problem with uMatrix in that, depending on the order in which FF loads the addons, uMatrix "restores" the Content-Security-Policy header when another addon already changed it or removed it completely. Maybe other headers are affected as well, IDK. uBO doesn't have the same problem so I assume you already fixed it there.

Since you closed your Issue tracker for uMatrix I didn't know how else to contact you. If you're interested let me know, I have a simple example addon ready to share and the steps to reproduce. Thanks

Renan19 commented 5 years ago

@earthlng @tartpvule @Thorin-Oakenpants I am trying to install the patch with no sucess.

Seted -> general.config.filename to "monkey_Bug1421725_WebRequest.cfg" Steed -> general.config.sandbox_enabled to false

user_pref("general.config.filename", "monkey_Bug1421725_WebRequest.cfg"); user_pref("general.config.sandbox_enabled", false);

Put monkey_Bug1421725_WebRequest.cfg in root Profile Path put monkey_Bug1421725_WebRequest.cfg in root Firefox path

Dont work! what i am losing?

Firefox Version: 66.0.2 OS: Windows 10

If anyone can help, thanks.

Thorin-Oakenpants commented 5 years ago

You'll have to ask tartpvule - create an issue at his repo where everything in the one place

Renan19 commented 5 years ago

@Thorin-Oakenpants

You'll have to ask tartpvule - create an issue at his repo where everything in the one place

I already created with no awaser yet, i will wait. i asked here too because i see the conversation about this and maybe anyone here can help with this.

earthlng commented 5 years ago

@Renan19

Hi,

@tartpvule wrote the patch based on the ESR code and it might not necessarily work in newer versions, or the underlying code could have changed in subtle ways or it might break with any future release. If you want to use it, you should best check if the modified code is still somewhat the same. If you just want to use it as is and hope for the best, then here's how you enable it:

create a file autoconfig.js in <install-dir>\defaults\pref\ with this content:

// Any comment. You must start the file with a single-line comment!

pref("general.config.sandbox_enabled", false);
pref("general.config.filename", "monkey_Bug1421725_WebRequest.cfg");
pref("general.config.obscure_value", 0);

and place the monkey_Bug1421725_WebRequest.cfg file in the root Firefox path (where firefox.exe is located).

FYI disabling the autoconfig sandbox with general.config.sandbox_enabled seems to still be allowed in Release at the moment but they already said that they only want to keep allowing it to be disabled in ESR in the future.

hope that helps :)

tartpvule commented 5 years ago

@Renan19 see the issue in my repo. @earthlng About monkey_AddonSettings.cfg that you tried, have you set xpinstall.signatures.required to false? What is the result of Components.utils.import("resource://gre/modules/addons/AddonSettings.jsm", {}).AddonSettings.REQUIRE_SIGNING in Scratchpad in about:config with and without the monkeypatch?

Renan19 commented 5 years ago

@earthlng @tartpvule Thanks, tested and it is working fine now on firefox lastest version.

earthlng commented 5 years ago

@tartpvule

have you set xpinstall.signatures.required to false?

I don't remember but I'm pretty sure I did. I had also tested it with a modified version of your script that didn't read the prefs and instead used hardcoded values but that didn't work either.

What is the result of ...

I just tested it again and REQUIRE_SIGNING is false with the patch and true w/o it. Ran it on both about:config and about:addons and the values are the same ie it should theoretically allow me to install unsigned extensions but it doesn't and IDK why. Maybe something to do with lazy loading of components that they changed since ESR or FF somehow keeping a cache of the values, I have no idea.

tartpvule commented 5 years ago

@earthlng Thank you for pointing out the problem As it turns out, my monkey_AddonSettings.cfg has not been working for quite a while, even in ESR 60. The problem is that dependent modules like XPIProvider.jsm would have already acquired a reference to the old AddonSettings by the time the patch is applied (a race condition? I don't know). I have updated the file, though "no reliability guarantees", at least it seems to work on my ESR 60 enough and that's what I am focusing on.

Thorin-Oakenpants commented 5 years ago

from Jan 2018 https://github.com/ghacksuserjs/ghacks-user.js/issues/265#issuecomment-359462026

Pants... but please don't take this to ghacks! I still have enough faith in the mozilla devs to think that they'll do something about it when @gorhill is the one telling them how bad this is.

It wasn't me: https://www.ghacks.net/2019/05/23/firefox-csp-issue-may-cause-extension-conflicts/

But given that HTTPS-E are aware of the issue, and that extension is used in Tor Browser, and given that it finally got an issue at uBlock-issues, and some other external factors - it seems as if KM is considering doing something about it. Just watch the relevant bugzillas

Thorin-Oakenpants commented 5 years ago

I don't get it. WTF is wrong with people. A non-event such as a pref to control profile/chrome/ lookups, where nothing is lost, gets so much outrage and attention and yet this issue which actually breaks things and can compromise a user's security and privacy gets absolutely no comments or anything.

reddit-csp

reddit-chrome

r/Firefox usually has some knowledgeable rational and well spoken people - but I can't understand why no-one has picked up on it. Are they all fixed fixated (edit) on looks over form?

Thorin-Oakenpants commented 5 years ago

why are you confused @gwarser, or is that just the best of a limited set of emojis you could choose ?

I don't expect everyone on r/Firefox to understand the ramifications of this bug, but not a single person has commented, and yet they're always happen to discuss in depth technical issues about other security issues. Isn't anyone there concerned that their extension can often not work as expected? Extensions that help security, tracking, FPing ...

I think I'll do a Wonko the Sane and build an inside out house called The Outside of the Asylum to house the world. I shall live inside it and any of you are welcome to come visit (if you are sane)

jingofett commented 5 years ago

I don't get it. WTF is wrong with people. A non-event such as a pref to control profile/chrome/ lookups, where nothing is lost, gets so much outrage and attention and yet this issue which actually breaks things and can compromise a user's security and privacy gets absolutely no comments or anything.

reddit-csp

reddit-chrome

r/Firefox usually has some knowledgeable rational and well spoken people - but I can't understand why no-one has picked up on it. Are they all ~fixed~ fixated (edit) on looks over form?

https://old.reddit.com/r/firefox/comments/btvixo/firefox_bug_causes_addons_ublock_origin_https/ this thread seems to be getting a bit more traction and has a more informative headline

Thorin-Oakenpants commented 5 years ago

Well, I kept track of that for all of 8 hrs. It trended up very quickly into second place on hot (after the PSA userChrome thing which I think is a sticky). 251 points, 35 comments. It was there when looking at new items in its right place. Now you can't find it unless you know it exists. It doesn't even show when looking at items in chronological order. r/Firefox, AFAIK, has demoted it so it doesn't show. And it has now died and nothing has changed for over an hour.

Thorin-Oakenpants commented 5 years ago

yup .. shadowbanned. I don't understand why? People are now asking why it's shadowbanned. FFS, do they not want a better product? Fucking jerks. For some reason they've always hated this repo and associated it with the Mozilla haters at ghacks itself

jthile commented 5 years ago

It just popped back up, but it was definitely shadowbanned for a few hours. Maybe there was disagreement among the mods of the sub. Still very disappointing to see that suppressing information about a bug is on the table at all.

Thorin-Oakenpants commented 5 years ago

I guess its par for the course (I don't hang around and read these sorts of things) but 2/3rds of the comments are off topic - I guess you get that with everyone wanting to chime in and bitch about something, and/or lack of knowledge

Thorin-Oakenpants commented 5 years ago

OMFG ... https://bugzilla.mozilla.org/show_bug.cgi?id=1462989#c24

Hey folks, we're getting a lot of advocacy chatter on this bug, so I'm going to close comments on it for the time being

First of all, only one comment was marked advocacy - five days ago. No-one has said anything on the bug for over 3 days. WTF? Way to win friends and influence people. Fucking bollocks. I don't care about looking backwards, I just want the problem addressed. But they seem to have their mind somewhere else right now. WTF?!

shree1717 commented 5 years ago

Instead of begging Mozilla on our knees wouldn’t it make more sense to

  1. write an extension that taps into the WebRequest API and provides a way for other extensions to register with this extension in some (user-configurable?) way
  2. have co-operating extensions (uMatrix, uBlock0, CanvasBlocker, I would hope) use this extension instead of WebRequest directly?

I know, it’s a tall order, but at least it seems a way forward.

claustromaniac commented 5 years ago

I considered that idea a long time ago, but there would be more than a few problems with that, technically speaking... It can be done, but it wouldn't be easy for extension developers to adopt in the least. They would need to make pretty extreme changes to their respective extensions and, even then, that approach wouldn't allow them to do some of the things they can do now. It's not worthwhile.

tartpvule commented 5 years ago

I just developed a new experimental patch for Bug1421725 against mozilla-central, not yet extensively tested. This patch do what MDN says: "the second listener will see modifications made by the first listener". Anyone interested in checking it out?

https://github.com/tartpvule/my-firefox-patches/blob/master/Bug1421725_WebRequest_central.patch

girst commented 5 years ago

@tartpvule: I've tested the monkey-patch version and it seems to work. I've got a relatively small test case that I used to verify it:

  1. install canvasblocker and javascript toggle
  2. toggle js off by clicking the 'js' icon in the toolbar
  3. dis- and reenable canvasblocker, so its csp directives get applied
  4. visit https://gir.st/tmp/javascript.html

do you have intentions of submitting this patch to mozilla? (please do!)

tartpvule commented 5 years ago

@girst Thank you for your interest in my patch. https://bugzilla.mozilla.org/show_bug.cgi?id=1421725 The patch was rejected, as expected, citing performance reasons :( I don't see any performance regressions in my daily use, though.

Oh well, back to maintaining private patches and builds I guess. IMO: "merging" headers is a mess of glaringly obvious edge cases.

crssi commented 5 years ago

The patch was rejected, as expected, citing performance reasons :(

Yes, that is shame, I really don't know what is the hold reason at Mozilla... 😞

I don't see any performance regressions in my daily use, though.

... and performance for sure its not the real reason.

girst commented 5 years ago

On Sat, Jul 27, 2019 at 09:58:46AM -0700, tartpvule wrote:

https://bugzilla.mozilla.org/show_bug.cgi?id=1421725 The patch was rejected, as expected, citing performance reasons :(

missed that, thanks! this sorta-WONTFIX is just the worst response--i can't even see any perf tests (they should have the infra) linked in the bug report, while multiple people have shown multiple problems this causes :|

Oh well, back to maintaining private patches and builds I guess.

I've gone to great length avoiding that--including patching omni.ja. recently, I've managed to confine my modifications into AutoConfig[1]

[1]: for reference to who else might need it: https://gir.st/blog/legacyfox.htm

M83tUt3 commented 5 years ago

@tartpvule Thanks for your work. Is this patch still valid for FF68? I'm doing my own builds anyway so I could easily apply it myself. I'm also staying on ESR so if it still works I'll be good for another year, which would be wonderful.

tartpvule commented 5 years ago

@M83tUt3 Use my Bug1421725_WebRequest_central.patch from https://github.com/tartpvule/my-firefox-patches/blob/4dd8c06da18d2137d86ea43a2a4f936b5b100228/Bug1421725_WebRequest_central.patch, after patching in https://hg.mozilla.org/mozilla-central/rev/308ef98e6e4b (Bug 1450965)

After ESR68.1 is released and I finalized my private build, I will update my Firefox patches repo with updated instructions.

Thorin-Oakenpants commented 5 years ago

... aaaaand now they changed the docs

edit: FYI: @gorhill @gwarser @ublock-user

crssi commented 5 years ago

^^ lamest way to do it. 😢