InformAction Forums

herdsfgdgf wrote: ↑Sat Mar 01, 2025 9:58 pm All of the requests fail with: "TypeError: Failed to fetch"

herdsfgdgf wrote: ↑Sat Mar 01, 2025 9:58 pm Adding the lines from the thread linked below didn't help:

* https://[ff00::]/nscl/ xmlhttprequest allow

barbaz wrote: ↑Sat Mar 01, 2025 10:19 pm
As long as NoScript is what blocked these requests and caused them to fail to fetch, this is not a problem.

This is an implementation detail of NoScript due to limitations of WebExtensions APIs. NoScript makes and then blocks these requests as a means of sending itself needed information in time.

If another extension blocks these requests before NoScript can see them, NoScript will not function properly, e.g. blocking scripts you configured it to allow or erroneously not being able to see scripts loaded by webpages.

The purpose of those rules is to ensure uBlock Origin does not block NoScript's internal requests. So if they're showing green/allowed in uBlock Origin logger, you're good. If they don't, try also adding this rule in uBlock Origin Dashboard > My Rules? -

herdsfgdgf wrote: ↑Sat Mar 01, 2025 10:26 pm My worry is that it's blocked by UBO and Noscript is not working correctly. But due to limited technical understanding of such matters I cannot know...

barbaz wrote: ↑Sat Mar 01, 2025 11:20 pm Is the "TypeError: Failed to fetch" from when you click the arrow on the far right of the entry in the uBlock Origin logger?

barbaz wrote: ↑Sat Mar 01, 2025 11:20 pm The reason NoScript uses [ff00::]/... URLs for its internal requests is because those URLs are invalid to actually connect to. Trying to access such URLs outside of NoScript should simply fail to connect. This doesn't help tell whether or not NoScript is receiving its own internal messages.

I tested checking using the Chromium devtools (F12) > Network: if this panel is open while NoScript is messaging itself by this method, both the request and NoScript's synthetic response were listed there.

Don't worry. The symptoms of that are pretty glaring stuff. If it were happening to you, you'd definitely notice.

herdsfgdgf wrote: ↑Sun Mar 02, 2025 6:30 pm Thanks for your reply! I'm thankful for it.

herdsfgdgf wrote: ↑Sun Mar 02, 2025 6:30 pm 1. Does that mean everything is normal?

herdsfgdgf wrote: ↑Sun Mar 02, 2025 6:30 pm 2. Can I just ignore ff00 in dynamic filter list for every website I visit and just not touch it or create noop or whatever rules for it?

herdsfgdgf wrote: ↑Sun Mar 02, 2025 6:30 pm 3. Are all of the 4 lines needed for it to work (3 lines from the linked thread and the one you provided here) correctly?

herdsfgdgf wrote: ↑Sun Mar 02, 2025 6:30 pm Would I have to re-add the rules if I were to install UBO and Noscript extensions on a newly installed Windows for example?

barbaz wrote: ↑Mon Mar 03, 2025 2:13 am
You're welcome!

Yes.

As long as it shows green/allowed in uBlock Origin logger, you can safely ignore it and not touch it. If you do need site-specific dynamic rules to keep it green/allowed, I would exceptionally use allow for this instead of noop, to ensure no uBlock Origin filter list can ever block these.

Actually, I think only the rule provided here is needed in current NoScript. The behind-the-scene variant of this rule is for Firefox, and looking at NoScript code the noscript-csp.invalid usage looks to have been removed?

Whether you need the rule on a particular installation depends whether your uBlock Origin filter lists on that installation happen to block NoScript's internal requests. I always add the rules to be sure.