uBlockOrigin / uBOL-home

uBO Lite home (MV3)
GNU General Public License v3.0
1.13k stars 46 forks source link

Hostname exclusion not working with `importScripts()` #114

Open nstepien opened 8 months ago

nstepien commented 8 months ago

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. image

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 commented 8 months ago

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

nstepien commented 8 months ago

image image

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

nstepien commented 8 months ago

image

Same thing with uBlock Origin Lite turned off.

gorhill commented 8 months ago

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

gorhill commented 8 months ago

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 commented 8 months ago

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()

image

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

nstepien commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

I am not seeing any service worker being created

There should be a shared worker

image

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

Thanks for your patience and hard work!

nstepien commented 8 months ago

Seems like it's still an issue on 2024.2.14.104

gorhill commented 8 months ago

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.