Ignoring ping filters

[ghost]

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]

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]

@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]

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]

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]

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]

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]

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]

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