Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hostname exclusion not working with importScripts() #114

Open
nstepien opened this issue Jan 31, 2024 · 14 comments
Open

Hostname exclusion not working with importScripts() #114

nstepien opened this issue Jan 31, 2024 · 14 comments

Comments

@nstepien
Copy link

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
Copy link
Member

gorhill commented Jan 31, 2024

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

@nstepien
Copy link
Author

image
image

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

@nstepien
Copy link
Author

image

Same thing with uBlock Origin Lite turned off.

@gorhill
Copy link
Member

gorhill commented Jan 31, 2024

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

@gorhill
Copy link
Member

gorhill commented Jan 31, 2024

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
Copy link
Author

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
Copy link
Author

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
Copy link
Member

gorhill commented Jan 31, 2024

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
Copy link
Author

nstepien commented Jan 31, 2024

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
Copy link
Member

gorhill commented Jan 31, 2024

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
Copy link
Member

gorhill commented Jan 31, 2024

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.

gorhill added a commit to gorhill/uBlock that referenced this issue Jan 31, 2024
@nstepien
Copy link
Author

Thanks for your patience and hard work!

@nstepien
Copy link
Author

Seems like it's still an issue on 2024.2.14.104

@gorhill
Copy link
Member

gorhill commented Feb 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants