Hostname exclusion not working with importScripts()

[nstepien]

Our internal GitHub loads a shared worker at

https://github.[workplace.com]/assets-cdn/worker/socket-worker-[hash].js

which works.

The worker's only content is

importScripts('https://assets.github.[workplace.com]/assets/socket-worker-[hash].js')

but this fails.

I have [workplace.com] in the No filtering list, but it doesn't seem to work for the importScripts() call.

Disabling the default Ads, trackers, miners, and more does make it work though, because [workplace.com] is otherwise blocked.

I have the filtering mode set to Optimal. I'm on Chrome 121.0.6167.140.
Dunno if this is an MV3 limitation or not 🤷‍♂️

[gorhill]

When looking at Network pane in dev tools, what is the "Initiator" when the script if fetched by the browser?

[nstepien]

The initiator is the shared worker's script as expected.

[nstepien]

Same thing with uBlock Origin Lite turned off.

[gorhill]

What I am wondering is whether the domain of the initiator matches your "No filtering" entry.

[gorhill]

uBOL uses allowAllRequests, this tells the DNR engine to not block anything which is fetched from a context which has that allowAllRequests:

const rule = {
    id: TRUSTED_DIRECTIVE_BASE_RULE_ID,
    action: { type: 'allowAllRequests' },
    condition: {
        requestDomains: [ ... ],
        resourceTypes: [ 'main_frame' ],
    },
    priority: 100,
};

However I suspect in your scenario that rule is not matched because your service worker script is fetched from another service worker script, not from a document (main_frame). Maybe with an extra rule this would work, i.e.:

const rule = {
    id: TRUSTED_DIRECTIVE_BASE_RULE_ID+1,
    action: { type: 'allowAllRequests' },
    condition: {
        initiatorDomains: [ ... ],
        resourceTypes: [ 'script' ],
    },
    priority: 100,
};

If I could reproduce similar case on my side I would investigate a solution.

[nstepien]

If I could reproduce similar case on my side I would investigate a solution.

looks like github.com works basically identically to our own internal GitHub Enterprise.
I see a shared worker in chrome://inspect/#workers
Inspecting it shows an importScripts()

Maybe try blocking githubassets.com and excluding githubassets.com?

[nstepien]

What I am wondering is whether the domain of the initiator matches your "No filtering" entry.

GHE page's hostname is github.[workplace.com]
Shared worker script's hostname is github.[workplace.com]
Imported script's hostname is assets.github.[workplace.com]

If I don't exclude [workplace.com], then the shared worker and other assets are blocked.

[gorhill]

Maybe try blocking githubassets.com and excluding githubassets.com?

I added a filter to block anything from githubassets.com, and as expected this broken loading pages from GitHub. Once I add github.com to "no filtering" list, the page loads fine but I am not seeing any service worker being created, and nothing is reported as being blocked by uBOL.

[nstepien]

I am not seeing any service worker being created

There should be a shared worker

nothing is reported as being blocked by uBOL

Could it be because it's not blocked on the page itself, but in the worker?

[gorhill]

Couldn't get a SW on github.com, so I tried links on front page of Hacker News and found a site with a service worker with an importScripts statement in it, so now I have something to work with: https://spectrum.ieee.org/ai-domains.

[gorhill]

DNR's allowAllRequests can be used only with main_frame and sub_frame, hence why secondary resources pulled by workers aren't affected by allowAllRequests since the context is neither a main_frame nor sub_frame.

I found that a solution is to add an extra rule to exempt resources of type script when the initiator matches a whitelisted hostname.

The fix will be in next release.

[nstepien]

Thanks for your patience and hard work!

[nstepien]

Seems like it's still an issue on 2024.2.14.104

[gorhill]

Unfortunately without being able to investigate first-hand, I won't be able to make a diagnosis, which is necessary to come up with a solution.