What is your browser, browser version, JShelter version, and uBlock Origin version?

I could not reproduce the issue.

W.10 21H2 x64
Edge x64 build stable - 100.0.1185.44
Ublock Origin v. 1.42.4 in HARD MODE
JShelter v. 0.9
+
Xubuntu 21.10
Chrome - latest build
Ublock Origin v. 1.42.4 in HARD MODE
JShelter v.0.9

JShelter does not generate any outgoing requests. How did you came into conclusion that it is JShelter that generates the request?

Because if I disable JShelter the problem disappears.

I will close the issue for now. If you have more information regarding the source of the request, what is the request about, how it can possibly be connected to JShelter, please, let us know. I will reopen the issue once I learn any relevant information.

I do have more information: it is NSCL's SyncMessage.

This is a non-issue since the [ff00::]
1. Is a reserved multicast IPV6 address
2. Is not a valid HTTP endpoint (if you try to navigate http://[ff00::] the browser will always tell you it's unreachable)
3. The SyncMessage back-end cancels the webRequest (anyway fake and never allowed to reach the network) as soon as it processes the message.

uBlock should just ignore these requests (and depending on the order which the extensions are installed it may not even see them, since they could already have been blocked before they reach it).

In short, what you're observing is just an implementation artifact, and you can probably even instruct uBlock not to show it.

@sampei-nihira: I am sorry for not believing you.

@gioma1: We need to explain the request and add it to the documentation. Why is it needed, what is the code trying to do? Why does NSCL not use 0.0.0.0 or ::?

This also raises a question about NBS implementation. We currently block access to https://www.iana.org/assignments/locally-served-dns-zones/ipv6.csv rom the public internet. But I think that we should also block multicast addresses.

I updated the issue title and initial post to reflect the actual issue.

Happy Easter to all

JShelter enabled:

JShelter Disabled:

@sampei-nihira: This has nothing to do with uBlock Origin. We identified the responsible code in JShelter, or NSCL to be more precise. We also identified another bug in NBS. We need to clearly document the request so that users are not confused as you are or redesign based on the purpose of the request.

@gioma1: We need to explain the request and add it to the documentation. Why is it needed, what is the code trying to do? Why does NSCL not use 0.0.0.0 or ::?

The reason is pretty simple: using http://0.0.0.0 (or [::]) does trigger an actual request to localhost.

What the code is trying to do is exploiting synchronous XHR and webRequest.onBeforeRequest to effectively work-around the WebExtensions limitation of lacking any kind of synchronous messaging API.

Using https://[ff00::] doesn't cause any actual network request, no matter what. uBlock is reporting a false positive due to the fact the webRequest API in its first stage (onBeforeRequest) reports also invalid requests, even if (like in this case) they could not ever possibly reach the network.

This also raises a question about NBS implementation. We currently block access to https://www.iana.org/assignments/locally-served-dns-zones/ipv6.csv rom the public internet. But I think that we should also block multicast addresses.

Nope, on the contrary you should ignore them (like uBlock should do) because they cannot be used as the endpoint of any HTTP request.

@polcak

It has been pointed out to me elsewhere that my response may appear disrespectful,that was not my intention.
If it helps even with AdGuard Adblocker you get the same "issue":

If it does not help please disregard this additional information.
TH.

@sampei-nihira: Yes, I was confused and I apologized to you. I did not know that NSCL is making that request. As you can see it the source code, the request is there and it is cancelled. There is no need to point more tools that see it.

@gioma1 You are right that NBS likely will not need any adjustments. I was thinking also about other multicast addresses like ff02::1. But it seems that Firefox is blocking all such requests. It's understandable because multicast TCP does not make sense.

You are also right about 0.0.0.0. Firefox treats it the same way as localhost. It seems that we should revert 0ed2eec. We have the possibility do disable notifications. And we limit the number of notifications.

Added explanation to FAQ https://pagure.io/JShelter/webextension/blob/websitefaq/f/website/content/pages/faq.md?text=True#_336

Firefox treats 0.0.0.0 depending on the underlying OS: see also https://pagure.io/JShelter/webextension/blob/websitefaq/f/website/content/pages/faq.md?text=True#_160