Issues with UBO?

[herdsfgdgf]

Noscript shows up in the dynamic filter list of uBlock Origin as [ff00::] and the UBO logs show a lot entries like this:

Logger output:

+0
en.wikipedia.org
3
get
xhr
https://[ff00::]/nscl/common/SyncMessage/request.json?id=6c79033d-596c-4017-ae97-d22fab6c6053%3Ade205c92-cae4-44c5-bfba-340a1f5254cf

+0
https://en.wikipedia.org/wiki/Main_Page


All of the requests fail with: "TypeError: Failed to fetch"


My question is now: Does this mess with with either UBO's or Noscript's functionality or can I safely ignore it?

Adding the lines from the thread linked below didn't help:

viewtopic.php?p=106516&hilit=ff00#p106516


Thanks in advance for your help!

[barbaz]

All of the requests fail with: "TypeError: Failed to fetch"

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.

Adding the lines from the thread linked below didn't help:

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? -

Code: Select all

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

[herdsfgdgf]

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? -

I don't know what blocks these requests. I tested it with all other extensions disabled so it's either UBO or Noscript.

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...

I added the line in addition to the 3 lines from the other thread and it does show up green but still fails to fetch.

[barbaz]

Is the "TypeError: Failed to fetch" from when you click the arrow on the far right of the entry in the uBlock Origin logger?

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.

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...

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

[herdsfgdgf]

Thanks for your reply! I'm thankful for it.

Is the "TypeError: Failed to fetch" from when you click the arrow on the far right of the entry in the uBlock Origin logger?

Yes, that's right.

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.

Yeah, I see it under Network too. Status code 307 Internal Redirect for the request and 200 OK for the response.

So far so good it seems. So I guess my ending questions are:

1. Does that mean everything is normal?

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?

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

Thanks for your reply! I'm thankful for it.

You're welcome!

1. Does that mean everything is normal?

Yes.

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?

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.

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?

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?

Would I have to re-add the rules if I were to install UBO and Noscript extensions on a newly installed Windows for example?

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.

[herdsfgdgf]

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.

Great stuff thanks!
I think I'll leave all 4 rules in. Can't hurt to leave them in I guess.
Because the thing is at the moment my web experience is really fast and responsive and I'd rather not mess with it.