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

Ignoring ping filters #1493

Closed
ghost opened this issue Mar 21, 2016 · 8 comments

Comments

@ghost
Copy link

@ghost ghost commented Mar 21, 2016

Describe the issue

uBlock Origin doesn't block ping requests in some cases and ignores filters using the ping option.

One or more specific URLs where the issue occurs

http://www.bing.com/

Screenshot in which the issue can be seen

Steps for anyone to reproduce the issue

  1. Update the filter lists.
  2. Open the logger.
  3. Go to http://www.bing.com/ and take a look at the logger.

Result: The filter ||bing.com/fd/ls/$~ping in EasyPrivacy is not being applied. Creating a filter like ||bing.com/fd/ls/ blocks the tracking requests including the ping.

  1. Enable I am an advanced user and remove behind-the-scene from the whitelist.
  2. Create a filter like ||bing.com^$ping.
  3. Open the logger.
  4. Go to http://www.bing.com/ and take a look at the logger.

Result: The ping request is not being blocked.

Your settings

  • Browser/version: Chromium 51.0.2684.0
  • uBlock Origin version: 1.6.5rc3
@gorhill

This comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Mar 21, 2016

I can not reproduce with Chromium 48, however I can reproduce with Chromium 49 Chrome 50. So apparently now Chromium support new request types, for which uBlock will have to account.

The ping one is quite certainly a result of navigator.sendBeacon, so this means finally uBO will be able to block these when the option "Disable hyperlink auditing/beacon" is enabled (which it is by default) -- and this without having to enable advanced user mode.

Not sure I will support specifically ping type in static filter, I think a global blocking of ping requests is good enough, I do not see any pro-user benefit to allow ping at all for now.

@anthonyryan1

This comment has been minimized.

Copy link

@anthonyryan1 anthonyryan1 commented Jun 2, 2016

@gorhill

I'd just like to throw a use case in here that will hopefully help you reconsider allowing filtering instead of simply blocking all "ping" requests.

I work on a customer support chat application that uses navigator.sendBeacon when the window closes, it sends a simple post to the server with a ChatID telling the customer support staff member that the user has closed the window and they may move on to the next customer waiting for help. Since Chrome 49 we've noticed a large number of sendBeacon's never making it to our server and the customer support agents needing to wait 15 minutes from the last reply to be sure the person had left the conversation. We ultimately traced this issue back to uBlock Origin.

I know navigator.sendBeacon can be seen as yet another way to harvest user information, but there are legitimate use cases for it as well. I feel as though it's more comparable to XHR / Fetch than it is to <a ping="...">. In fact, before navigator.sendBeacon existed, we used to use a synchronous XHR post on unload to accomplish the the same thing, sendBeacon just provided a cleaner API built into the browser that seemed to be designed for our exact purpose.

@gorhill

This comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Jun 2, 2016

sendBeacon just provided a cleaner API built into the browser that seemed to be designed for our exist purpose.

I see the issue, and I agree uBO should not blanket-block network requests of type ping -- especially considering the comments in Chromium issue 611453.

Before Chromium issue 512406 was fixed, uBO would completely ignore navigator.sendBeacon using default settings.

After the fix to Chromium issue 512406, all network requests of type ping became blanket-blocked if hyperlink auditing/beacon was disabled in uBO.

But the right thing to do for uBO is in between, as illustrated by the concrete use-case you report.

The one thing I will do immediately for the next release is to have network requests of type ping to be filtered just like if they were normal network request: not all ignored because they are behind-the-scene, not all blocked because they have the type ping, but rather filtered as any other network request.

@gorhill

This comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Jun 3, 2016

Well, of course I forgot that even if ping-requests are filtered as normal, their behind-the-scene context is whitelisted by default in uBO, so we would end up with the same original issue when ping-requests were not filtered at all.

The whole issue would be easily solved if the Chrome API provided the URL from which the navigator.sendBeacon was triggered, or at least its origin (Firefox WebExtensions will have details.origin in its API for this).

@anthonyryan1

This comment has been minimized.

Copy link

@anthonyryan1 anthonyryan1 commented Jun 3, 2016

Wouldn't that be addressed by https://bugs.chromium.org/p/chromium/issues/detail?id=522124 which recently got fixed (and will need ~3 months to make it's way through the release channels). I may be mistaken of course, you're more familiar with the matter than I am.

@ghost

This comment has been minimized.

Copy link
Author

@ghost ghost commented Nov 25, 2016

Thank you for the fix. Everything seems to work. If I create a filter like *$beacon it blocks the request in question.

The only issue as you can see is that the filter does not seem to be displayed correctly.

@gorhill

This comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Nov 29, 2016

The only issue as you can see is that the filter does not seem to be displayed correctly.

The beacon filter is converted into other for now. I haven't decided whether to support a new specific type for beacons, but I just looked in ABP repo on GitHub and apparently there is a specific request type for ping, and only four such filters in EasyPrivacy. These will work in uBO since they are also translated into other.

@gorhill

This comment has been minimized.

Copy link
Owner

@gorhill gorhill commented Dec 8, 2016

For a more complete fix, need to support ping filter option as in ABP.

@gorhill gorhill reopened this Dec 8, 2016
gorhill added a commit that referenced this issue Sep 22, 2019
Related issue:
- #1493

Documentation:
- https://help.eyeo.com/adblockplus/how-to-write-filters#type-options

Test page:
- https://testpages.adblockplus.org/en/filters/ping

Additionally, network requests of type `beacon` will
be mapped to `ping` by the static filtering engine.
@gorhill gorhill closed this Sep 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.