Blocking the IPv6 "Unspecified Address" ([::]) breaks latest NoScript (11.2.13) and other extensions.

[hackademix]

Prerequisites

• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• I am running the latest version of uBlock Origin

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

URL(s) where the issue occurs

https://mozilla.org

Describe the issue

The LAN intrusion blocking filter contains several references to [::], which is the IPv6 Unspecified Address.

This is breaking latest NoScript and other extensions relying on the NoScript Commons Library, such as FSF's jShelter, which use this address as a placeholder endpoint to implement synchronous messages for content script early configuration purposes.

Since this is not meant to be used by any node, either LAN or not, is there any reason not to have it blocked by the filter?
Thanks.

Screenshot(s)

No response

uBlock Origin version

Any

Browser name and version

Mozilla Firefox 96.0b8

Settings

Allowing Filter Lists>Privacy>Block Outsider Intrusion into LAN

Notes

No response

[gwarser]

With NoScript you should probably not use the lists because NS is by itself blocking local connections https://noscript.net/faq#qa3_9

If you really need, you can add exception to "My filters" for your specific "[::]" connection by

@@[::]:yourport/and path$domain=from.which.domain

or even badfilter this one filter:

||[::]^$3p,domain=~localhost|~127.0.0.1|~[::1]|~0.0.0.0|~[::]|~local,badfilter

---

BTW this address is redirecting to localhost, so it's rather not completely safe for random add-ons or libraries to use it freely:

[gwarser]

Apparently behind-the-scene https://[::]/nscl/moz-extension:// xmlhttprequest allow rule is working¹, so maybe exception filter like this will work too:

@@|https://[::]/nscl/moz-extension://$xhr,domain=behind-the-scene

Footnotes

1. https://forums.informaction.com/viewtopic.php?p=104772#p104772 ↩

[hackademix]

BTW this address is redirecting to localhost, so it's rather not completely safe for random add-ons or libraries to use it freely:

You're right about Chromium, in facts we use file://[::] there, while Firefox correctly treats it as unreachable.

Anyway, I'm thinking to switch the placeholder endpoint to [ff00::], which is a reserved multicast which should be invalid anyway in a HTTP request content (and is regarded as such by both browsers).

[gwarser]

You're right about Chromium, in facts we use file://[::] there, while Firefox correctly threats it as unreachable.

Screenshot is from Firefox.

[hackademix]

Thank you, fixed in NoScript 11.2.14rc1:

v 11.2.14rc1

x [nscl] Updated SyncMessage fixes conflict with other
content blockers (thanks gwarser, barbaz and Baraoic)

[gwarser]

@hackademix turns out [ff00::] get through webRequest API https://www.reddit.com/r/uBlockOrigin/comments/sn5x6t/new_connection_out_of_nowhere/, https://www.reddit.com/r/uBlockOrigin/comments/sndrw8/ff00_as_domain_on_every_website_suddenly_i_see/

---

At least in Chrome.

[gwarser]

something wrong with 1.46.0...1.47.0, maybe '• rewrite static filtering parser',
and noscript's xhr from uassets/11128 is losing its 'context: behind-the-scene',
so

@@|https://[ff00::]/nscl/moz-extension:/../syncMessage/$xhr,domain=behind-the-scene

doesn't work

---

Was

is

Probably because of gorhill/uBlock@6fd58c9

I see no issue on my side. Maybe because it's on Linux.

---

No issue in VM. Missing important STR?