I just updated my FF to version 44 (on Linux Mint 17.3 MATE 32Bit) and now it's telling me, this addon is not verified.So far, this has not been an issue, but as far as I know, the next FF will support only verified addons.WilI I lose this addon by then, or what can I do about this now, please?

I just updated my FF to version 44 (on Linux Mint 17.3 MATE 32Bit) and now it's telling me, this addon is not verified.So far, this has not been an issue, but as far as I know, the next FF will support only verified addons.WilI I lose this addon by then, or what can I do about this now, please?

No problems here. Fx 44 direct from Mozilla, not from Ubuntu's repos, and uBlock Origin (v1.5.5) from AMO.The whole business of not allowing signed extensions and when or whether that will happen is being gone over elsewhere in Mozillazine.

@Centauri - you already where pointed to AMO to get the latest "signed version. no reason to rush in rage all the time.and it makes no matter if you have the latest or not. btw your chip issue was solved also to have to ask Zitronella. dont know what you have messed up with your ublock, i have same config running in several browsers include vivaldi/opera.

as raymond spoke up its not only the uB picker, get also familiar with the firefox "Element untersuchen" to determine scripts which show ads after a period. time to improve yourself a bit

[I posted these unanswered questions as a separate thread -- possibly I didn't understand how this subforum works?]

I recently installed Firefox 44 on an Android phone and while trying to figure out how to get some of the security and control I'm used to on the desktop, discovered uBlock Origin. Really great work! There is a bit of a learning curve with some trial and error, as the online wiki documentation seems a bit sparse (at least for a semi-geek like me). So I do still have a few questions if anyone can help:

(1) Why do successive taps on the blocking chart boxes give first a grey box and then a partially colored one? It seems a grey box means "noop" but I'm not sure what's going on with the colors, why another tap doesn't go back to blank.

(2) How are rules best edited on a small phone screen, where once the keyboard pops up you can barely see what you're doing? Can the temporary-rule window at least expand to full screen width?

(3) How do you identify individual inline scripts to exclude, rather than simply blocking all -- does this require examining source code, presumably on the desktop?

Blocking via HTTP observer would indeed be faster but this hack would produce consistency issues because of missing context information (DOM node is unknown so it cannot be hidden, also it would considerably limit information available via blockable items feature).

Could anyone, please, explain what Palant is talking about and whether or not I should worry about this. I am a bit paranoid when it comes to security, and the words "hack would produce consistency issues because of missing context information (DOM node is unknown so it cannot be hidden)" sound like uBlock Origin doesn't block something it should block.

GHM113 wrote:Could anyone, please, explain what Palant is talking about and whether or not I should worry about this. I am a bit paranoid when it comes to security, and the words "hack would produce consistency issues because of missing context information (DOM node is unknown so it cannot be hidden)" sound like uBlock Origin doesn't block something it should block.

There is no "hack". Unfortunately, it's just that Wladimir Palant has a habit of misrepresenting my work, and in doing so he likes to use superlatives to make more of an impact, hence his use of "hack". This is another instance among others. I didn't feel like adding noise to the issue tracker to correct him -- and anyways I personally lost faith in his intellectual honesty a long time ago so I find it's pointless to argue with him. This specific instance worked, insofar has it made you worry needlessly.

To address his specific argument: his "DOM node is unknown so it cannot be hidden" comment is nonsensical because this would mean ABP on Chromium-based browsers would not be able to collapse the placeholder of blocked images -- which it does. So yes, it is possible to find the DOM nodes which needs to be collapsed as a result of having the network request counterpart blocked.

Before this change, scriptlets could be completely disabled just by stripping out ##script:inject filters and $redirect filter option. How to disable all scriptlets in uBlock Origin 1.9.15rc0?

You mean you were creating your own modified filter lists from the original ones without any instance of `##script:inject` or `$redirect` filters?If so, you could simply use an empty `assets/ublock/resource.txt` file and block the update of that resource by blocking the corresponding network request in the behind-the-scene scope.

But yes, I do see your point. I will try to implement asap the hidden (for now) settings to wholly disable script injection and redirections. I do want longer-term a new pane for advanced users in the dashboard to more easily toggle these advanced settings.

gorhill wrote:You mean you were creating your own modified filter lists from the original ones without any instance of `##script:inject` or `$redirect` filters?

Yes. I clone the uAssets repo and use a suite of scripts to construct modified filter lists from parts of uAssets as a base.

gorhill wrote:If so, you could simply use an empty `assets/ublock/resource.txt` file and block the update of that resource by blocking the corresponding network request in the behind-the-scene scope.

To be clear, that involves a custom build of uBlock Origin, and a "purge all caches" after installing it, right?

gorhill wrote:But yes, I do see your point. I will try to implement asap the hidden (for now) settings to wholly disable script injection and redirections. I do want longer-term a new pane for advanced users in the dashboard to more easily toggle these advanced settings.

Good news, thanks!

*Always* check the changelogs BEFORE updating that important software!