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

Enable blocking of service worker requests in Chrome #82

Conversation

philipp-classen
Copy link
Member

@philipp-classen philipp-classen commented Jul 6, 2023

POC (to be used together with ghostery/ghostery-extension#1223)

Requests from services workers on Chrome are not associated with a tab. That is why they are currently ignored.

// Requests from the service worker use a different protocol
// (e.g. https). If there is a more direct way to detect requests
// from the extension, this could be simplified.
if (isChromium && !this.initiator.startsWith('chrome-extensions://')) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about Opera and Edge? maybe we should check for http/https instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// Note: Chrome-forks such as Edge or Opera will also be reported

isChromium covers Chromium based browsers including Opera and Edge.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

http/https and ws/wss. But I tried to approach it from the other direction and identify requests from the extension. I think a better name for "isBackground" would be something in the line of "is it from the extension?".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've checked Opera and Edge and both use same chrome-extensions protocol

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think the change here (not the URL filling) would be safe. On isolation, it will not make a difference though because the request will still be skipped because of the missing fields.

context.tabUrl = context.tabUrl || (page && page.getTabUrl());
context.frameUrl = context.frameUrl || (page && page.getFrameUrl(context));
context.tabUrl = context.tabUrl || (page && page.getTabUrl()) || context.url;
context.frameUrl = context.frameUrl || (page && page.getFrameUrl(context)) || context.url;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this needs a change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it is sound to fill it with the url. But the reason that I added it was that there are multiple places where the adblocker assumes that it is present, for instance here:

if (context.urlParts === null || context.frameUrlParts === null) {

And later it would throw in the whitelist check:

if (this.whitelistChecks[i](context) === true) {

Copy link
Member Author

@philipp-classen philipp-classen Jul 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this here is the main problem still. Filling it in like this is risky. Potentially we could apply it only if it is a request from a service worker; but even then, it is not clear which URL to fill in.

The other question is if it is sound to even attempt to fill it. But IMHO you can argue that it is:

  • It matches the behavior on Firefox
  • The initiator should be very close to what so far was exclusively the tab

But conceptually cleaner might be to put the service worker information in a separate field. (But with the consequence that all places where it is used will need to be revisited. Through the whole stack down to the adblocker library.)

@philipp-classen
Copy link
Member Author

Closing in favor of #83

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants