Certain blocked actions not logged by the logger?

[jimbobmcgee]

I'm trying to track down a functional issue with the web-based management console for my company's deployed antivirus, where it does not populate certain dropdown lists when UBO is active. I am fully willing to accept it is some facet of my own config or customisation which is preventing this, but I can't seem to find the culprit using the UBO logger.

I typically run UBO with inline scripts, 1st-party scripts and 3rd-party scripts/frames defaulted to red and I have some domains forcibly set to red. For this specific app's URL, have set the domains that are listed with a + or - to grey -- this is my normal approach to allow-listing a website through UBO:

The logger is showing me a number of grey entries for XHR/POSTs and some script/GETs, but these are not shown as blocked (red), just grey ones, and they all come from the anticipated domain.

I see no difference if have a log filter of Not allowed applied -- just grey log entries. I have always understood this to mean that these entries were for resources that were not blocked by any filter, and so would be allowed by default.

If I turn UBO off with the big blue power button, the management console works as expected.

So, for my better understanding, are there actions within UBO that are blocked, but are not logged in the logger? Or, is my understanding of the color-coding of the log entries incorrect?

If these are not logged in the logger, is there some other means I can use to determine exactly what is being prevented by UBO, so I can craft the necessary exceptions.

[stephenhawk8054]

Your dynamic rules are not blocking 1st party connections, and the logger in your screenshot shows correctly.

[jimbobmcgee]

Apologies, @stephenhawk8054 -- I'm very likely missing your point.

If the dynamic rules are not blocking connections, and the logger is correctly showing that these requests are not blocked, then what else might be blocking them, and how do I observe that in the logger?

I'm not seeing (what I would recognise as) a static rule/filter applying (i.e. no || pattern) in the log entry, no red lines in the log at all, no extra domains in the flyout menu that I can use to override, nor any increment in the counter on the badge/icon.

I've been using UBO for a number of months now, and this is the first time I've come across a site where I couldn't identify my issue with the help of those specific visual indicators.

What am I missing?

[stephenhawk8054]

I mean your dynamic rules in your 1st screenshot are not blocking 1st party connections, a.k.a the connections with the domain eu02.protect.eset.com which are shown in your 2nd screenshot of logger.

It's because you are noop-ing them, a.k.a you are marking the inline scripts, 1st party scripts and eset.com connections as grey, from your 1st screenshot above, so of course the eu02.protect.eset.com connections are not blocked.

[jimbobmcgee]

Thanks for the clarification. I think that means you agree with my initial assessment that, at least according to the logger, UBO is not blocking anything.

In that case, what would feasibly be the difference between me noop-ing eu02.protect.eset.com in the manner that I have, and me disabling UBO altogether with the blue power button? The former will not allow the application to populate its UI dropdowns, while the latter allows the app to operate normally.

And, following on from that, how can I detect whatever that difference is in the logger (or some other diagnostic), so I can adequately identify what needs to be excepted in the future?

[jimbobmcgee]

Stand down, I've found it! 😄

Nothing being blocked by UBO. Had a non-standard scriptlet interfering with the DOM -- GUI dropdown was actually a JS-driven popup; lists were being populated; scriptlet was screwing with the z-index of the popup.

Scriptlet was indeed shown in the log, just buried under about a thousand grey/noop XHR requests.

Had to use the webtools/JS debugger to break on DOM changes, so I could see exactly what was happening in the inspector before the app's JS removed the dropdown's popup, otherwise I would never have found it. Nothing to do with UBO, just an observation.

Thanks for looking, in any case.

[stephenhawk8054]

UBO is not blocking anything.

I still don't understand what you mean.

I NEVER say uBO is not blocking anything. Based on your configuration, uBO should block ALL 3rd-party scripts and frames, but not 1st-party connections and inline scripts.

You only show a screenshot of a little bit of the logger which just shows 1st-party connections, so of course they are not blocked. If the site has 3rd-party scripts and frames, they should be blocked, but you didn't show that.

---

Have you read uBO's wiki about 3rd and 1st-party connections yet?

[gorhill]

buried under about a thousand grey/noop XHR requests

Why did you not filter the logger output to reveal only what was blocked? This would have avoided already burdened enough volunteers here to spend time on a self-inflicted issue, you have all the tools to diagnose yourself such issues.

[garry-ut99]

gorhill : Why did you not (...)

He already did, like he already mentioned in his intitial comment:

jimbobmcgee :
The logger is showing me a number of grey entries for XHR/POSTs and some script/GETs, but these are not shown as blocked (red), just grey ones, and they all come from the anticipated domain.
I see no difference if have a log filter of Not allowed applied -- just grey log entries. I have always understood this to mean that these entries were for resources that were not blocked by any filter, and so would be allowed by default.

but he usednot + allowed instead of blocked.

jimbobmcgee : So, for my better understanding, are there actions within UBO that are blocked, but are not logged in the logger? Or, is my understanding of the color-coding of the log entries incorrect?

most likely documentation is confusing and misleading, or the logger doesn't follow documentaion, as documentation says that allowed includes:

The color of a row hints at how the resource was filtered:

• No color: The request for the resource was allowed to go through because it matched no filter/rule.
• Gray: The request for the resource was allowed to go through "Dynamic filtering" engine, because of noop rule.
• Green: The request for the resource was allowed to go through (++) because it matched a filter/rule whose purpose is to bypass a matching block filter/rule.

but in practice it shows only Green and Yellow (crossed out), but not "No color" (known as unmodified or as "Grey" by OP), hence not allowed excludes only Green and Yellow (crossed out), but not "No color". This creates a confusion when an user (expecially unfamiliar with uBO) thinks and expects that allowed label in the logger will inlude "No color" (unmodified) and that not allowed will exclude "No color" (unmodified).

jimbobmcgee : If these are not logged in the logger, is there some other means I can use to determine exactly what is being prevented by UBO, so I can craft the necessary exceptions.

• most of them are logged, just use label blocked instead of not allowed.
• sometimes some special background requests are not visible in the logger until "All" or "Tabless" is selected in page selector: https://github.com/uBlockOrigin/uBlock-issues/wiki/The-logger#page-selector, also see:
  • https://github.com/uBlockOrigin/uBlock-issues/wiki/Behind-the-scene-network-requests
  • "My rules" (dynamic filtering rules) #3226
• also there is one issue: Some cosmetic rules don't appear up in the logger or appear occasionally even if they are applied always #521