Disabling ublocklite doesn't fully disable it

[Clashpoint]

I am trying to disable ublock completely on some website so I see ads, an example of a website I need the ad block to fully ignore is tab.gladly.io (tab for a cause) , the issue when I fully disable the filters (the extension clearly says no filters and after reloading) it still wouldn't show ads at all .

[gorhill]

You need to provide more information if you want me to reproduce on my side, I can't investigate what I can't reproduce. Tell me everything I need to do in details for me to reproduce -- keep in mind I am not behind you looking at your monitor.

[Clashpoint]

that's fair, I apologize for not being clear , let me know if any more info is needed
I am using google chrome version Version 108.0.5359.125 (Official Build) (64-bit)
while testing this I have only ublock origin lite and tab for a cause as my enabled extensions
these are the errors that I have in my console

and this is whay my ublock shows

page with ublock as an active extension with filters fully disabled

and the page when it's disabled as an extension

tho even while disabled I am getting these errors in my console

[gorhill]

What's your default filtering mode in uBO Lite?

[Clashpoint]

default filtering mode is optimal with these filters

[gorhill]

The problem does not occur when default mode is set to Basic.

Unfortunately, I do not know how this can be fixed, as there is no way to tell the scripting API to declaratively exclude script injection according to the root context. Another limitation is that with the permissions API there is no way to exclude a specific site from an extension.

For now the only workaround I see is to work in Basic mode by default, and enable higher blocking modes only for specific sites.

---

The CSS style being injected in the Google Ad frame:

I might open an issue with MV3 people to make them aware of this sort of issues.

[Clashpoint]

I see, thanks for the reply

[erock8303]

This issue is affecting other extensions from being used on specific sites for me and my team.

We use Hubspot for our sales emails to track and log them in our CRM. Their Hubspot Sales Extension allows us to do this within the Gmail interface. Unfortunately, uBOL does not completely "turn off" when I select 'no filtering' on mail.google.com. The Hubspot extension fails every time uBOL is installed. It works when uBOL is uninstalled. uBOL is our companies only allowed adblocker.

I've worked with Hubspot support team and have exhausted all options to work around uBOL. They provided a list of their domains that I added to uBOL's "allow" list, but no change to the failing functionality.

Any suggestions?

Let me know if you need any more info, screenshots, or anything else. We would really appreciate your help in solving this issue.

[gorhill]

This can only be solved by the browser API providing new functionality to the scripting.registerContentScripts equivalent to DNR's allowAllRequests.

[gorhill]

Following the discussion at w3c/webextensions#668, I did try the suggestion to use a synchronous XHR-based hacky solution, and I have a prototype which solves the issue. It works this way:

Create a dynamic DNR rule as follow

{
    id: ALLOWALL_HACK,
    action: {
        type: 'redirect',
        redirect: {
            extensionPath: '/web_accessible_resources/filtering-enabled'
        },
    },
    condition: {
        resourceTypes: [ 'xmlhttprequest' ],
        urlFilter: '|https://ubol.invalid/filtering/',
    },
    priority: 100,
}

priority is set to the same priority used to declare the allowAllRequests rules used to implement the no-filtering mode, hence only those allowAllRequests can bypass the ALLOWALL_HACK rule.

Content script side, there is this code:

// https://github.com/uBlockOrigin/uBOL-home/issues/20
// https://github.com/w3c/webextensions/issues/668
// Hacky, until a better solution is possible in MV3.
// If the xhr fails, this means the request was not redirected to a local
// resource by the extension, which indicates that no-filtering mode is in
// effect for the root context.
{
    const ancestors = document.location.ancestorOrigins;
    if ( ancestors && ancestors.length !== 0 ) {
        const rootOrigin = ancestors.item(ancestors.length-1);
        if ( rootOrigin !== document.location.origin ) {
            const xhr = new XMLHttpRequest();
            try {
                xhr.open('GET', `https://ubol.invalid/filtering/`, false);
                xhr.send();
            } catch(ex) {
                return; // no filtering should occur
            }
        }
    }
}

So when disabling filtering for example.com, an allowAllRequests rule is created for example.com, which will cause the ALLOWALL_HACK rule to be disabled when example.com is one of the ancestor, and the content script will return immediately as a result.

However this comes at the cost of undesirable side effects:

https://ubol.invalid/filtering/ is not secret, so websites could use it to find out whether uBOL is installed and enabled. A per-release random part could be used but the URL would still be public and usable for the duration of the release

With sites for which uBOL is disabled, the console may be polluted by numerous error messages because https://ubol.invalid/filtering/ is unreachable:

[stephenhawk8054]

https://ubol.invalid/filtering/ is not secret, so websites could use it to find out whether uBOL is installed and enabled. A per-release random part could be used but the URL would still be public and usable for the duration of the release

Hmm... That sounds like a trivial way for websites' anti-adblock?

[gorhill]

That sounds like a trivial way for websites' anti-adblock?

Yes, hence why it's unlikely I go ahead with this fix, it was just a proof of concept that this can be done, but there is a cost. The real solution would be for uBOL to be able to dynamically register data to be injected in isolated and main world and accessible to registered scripts.