-
Notifications
You must be signed in to change notification settings - Fork 6
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
Enable blocking of service worker requests in Chrome #82
Conversation
// 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://')) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
common/platforms/webextension/platform.es
Line 19 in 319cc4f
// Note: Chrome-forks such as Edge or Opera will also be reported |
isChromium covers Chromium based browsers including Opera and Edge.
There was a problem hiding this comment.
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?".
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:
common/modules/adblocker/sources/adblocker.es
Line 235 in 319cc4f
if (context.urlParts === null || context.frameUrlParts === null) { |
And later it would throw in the whitelist check:
common/modules/adblocker/sources/adblocker.es
Line 255 in 319cc4f
if (this.whitelistChecks[i](context) === true) { |
There was a problem hiding this comment.
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.)
Closing in favor of #83 |
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.