3 ms·

What are you using in place of uMatrix?

minimalist 5y ago
It's worth reaching out to the maintainer of nuTensor, which seems to be the most active continuation of uMatrix. https://github.com/geekprojects/nuTensor https://github.com/geekprojects/nuTensor
- nieve 5y ago
  Is it actually still maintained? It's been nine months since the last update and Github's for network for uMatrix shows several forks updating more recently than that.
  - OJFord 5y ago
    The intention was always just to handle patches like this, not that the forker had any intentions of adding new features or anything. The concern iirc was mainly that a Firefox update might require some change to keep it functional.
btdmaster 5y ago
It may not be a perfect solution, but uBO's advanced mode[1] might help. [1] https://github.com/gorhill/uBlock/wiki/Blocking-mode https://github.com/gorhill/uBlock/wiki/Blocking-mode
- vtriolet 5y ago
  uBO's advanced mode has been my replacement so far. I have struggled to use it in the past because I was trying to directly map uMatrix rules to uBO dynamic rules, which isn't really possible due to syntax differences. I've realized now that I'll have to embrace both uBO's dynamic rules and uBO's static filters to truly replace uMatrix. For example, I like to block all XHR requests by default. In uMatrix, the rule `* * xhr block` handled this for me. While uBO's dynamic-rule syntax does have an "xmlhttprequest" keyword, it cannot be used in a blanket rule like `* * xmlhttprequest block`. I had to use the static filter `*$xhr` to accomplish the same blocking instead. This was a bit awkward at first because I had to compartmentalize rules for different request types based on the limitations of the dynamic-rule syntax. I've been using the uBO wiki on GitHub and r/uBlockOrigin as references to help me understand the differences. I've also been using uBO's logger to help me generate rules and filters. Clicking on a blocked request will pop up a dialog that can be used for pretty fine-grained blocking. Seeing rules change on the fly is also nice for learning the intricacies of uBO's filtering capabilities.
  - mro_name 5y ago
    I even go as far as * * * block * 1st-party * allow * facebook.com * block * facebook.net * block * fbstatic-a.akamaihd.net * block * instagram.com * block * whatsapp.com * block and think I'm not affected – correct?
    - vtriolet 5y ago
      You should be able to trigger the DoS issue with your custom rules by changing 'http://googleadservices.com http://googleadservices.com' to 'http://facebook.com http://facebook.com' in the uMatrix POC code. You will also be affected if you have any of the filter lists enabled on the "Assets" tab in the uMatrix dashboard. There may be other ways of triggering the bug, too--those are just two of the more obvious ones.

It's worth reaching out to the maintainer of nuTensor, which seems to be the most active continuation of uMatrix. https://github.com/geekprojects/nuTensor https://github.com/geekprojects/nuTensor

nieve 5y ago
Is it actually still maintained? It's been nine months since the last update and Github's for network for uMatrix shows several forks updating more recently than that.
- OJFord 5y ago
  The intention was always just to handle patches like this, not that the forker had any intentions of adding new features or anything. The concern iirc was mainly that a Firefox update might require some change to keep it functional.

btdmaster 5y ago

It may not be a perfect solution, but uBO's advanced mode[1] might help. [1] https://github.com/gorhill/uBlock/wiki/Blocking-mode https://github.com/gorhill/uBlock/wiki/Blocking-mode

vtriolet 5y ago
uBO's advanced mode has been my replacement so far. I have struggled to use it in the past because I was trying to directly map uMatrix rules to uBO dynamic rules, which isn't really possible due to syntax differences. I've realized now that I'll have to embrace both uBO's dynamic rules and uBO's static filters to truly replace uMatrix. For example, I like to block all XHR requests by default. In uMatrix, the rule `* * xhr block` handled this for me. While uBO's dynamic-rule syntax does have an "xmlhttprequest" keyword, it cannot be used in a blanket rule like `* * xmlhttprequest block`. I had to use the static filter `*$xhr` to accomplish the same blocking instead. This was a bit awkward at first because I had to compartmentalize rules for different request types based on the limitations of the dynamic-rule syntax. I've been using the uBO wiki on GitHub and r/uBlockOrigin as references to help me understand the differences. I've also been using uBO's logger to help me generate rules and filters. Clicking on a blocked request will pop up a dialog that can be used for pretty fine-grained blocking. Seeing rules change on the fly is also nice for learning the intricacies of uBO's filtering capabilities.
- mro_name 5y ago
  I even go as far as * * * block * 1st-party * allow * facebook.com * block * facebook.net * block * fbstatic-a.akamaihd.net * block * instagram.com * block * whatsapp.com * block and think I'm not affected – correct?
  - vtriolet 5y ago
    You should be able to trigger the DoS issue with your custom rules by changing 'http://googleadservices.com http://googleadservices.com' to 'http://facebook.com http://facebook.com' in the uMatrix POC code. You will also be affected if you have any of the filter lists enabled on the "Assets" tab in the uMatrix dashboard. There may be other ways of triggering the bug, too--those are just two of the more obvious ones.