Using uBlock Origin to replace NoScript surrogates?

General discussion about web technology.
Post Reply
barbaz
Senior Member
Posts: 9180
Joined: Sat Aug 03, 2013 5:45 pm

Using uBlock Origin to replace NoScript surrogates?

Post by barbaz » Tue Sep 03, 2019 10:44 pm

From uBlock Origin 1.22.0 release notes -
redirect-rule=

This new option allows to create a pure redirect directive, without a corresponding block filter as would be the case with the redirect= option. For example, consider the following filter:

||example.com/ads.js$script,redirect=noop.js

The above filter will result in a block filter ||example.com/ads.js$script and a matching redirect directive. Now consider this following filter:

||example.com/ads.js$script,redirect-rule=noop.js

The above filter will not cause a block filter to be created, only a redirect directive will be created. Standalone redirect directives are useful when the blocking of a resource is optional but we still want the resource to be redirected should it ever be blocked by whatever mean -- whether through a separate block filter, a dynamic filtering rule, etc.
This new functionality sounds like a superset of NoScript Classic's unprefixed surrogate script. Since NoScript Webext does not support surrogates yet, I would be interested to experiment with using uBlock Origin for this functionality.

Two questions:

1) Does this work even if uBlock Origin didn't do the blocking of the resource? e.g. if the resource is blocked by NoScript, will uBlock Origin still perform the $redirect-rule? Or would another addon blocking the resource create a race condition?

2) I think I should be able to combine this with https://github.com/gorhill/uBlock/wiki/ ... eslocation to add back custom surrogates (that are not default part of uBlock Origin). I couldn't find documentation of the details of user resources file format, but it appears it's of the form:

Code: Select all

[comments lines starting with "# "]
[resource-name] [MIMEtype]
[resource data, can't contain blank lines]
[2 blank lines]
...
Is this correct, or is there more to it than this?
*Always* check the changelogs BEFORE updating that important software!
-

gorhill
Junior Member
Posts: 42
Joined: Sun Mar 30, 2014 12:19 pm

Re: Using uBlock Origin to replace NoScript surrogates?

Post by gorhill » Wed Sep 04, 2019 3:04 pm

Does this work even if uBlock Origin didn't do the blocking of the resource?
No. The order to redirect can only be made at onBeforeRequest or onHeadersReceived time, so by the time another extension cancels a network request, it's too late for uBO to redirect, as onErrorOccurred is observational only. Reference documentation:

https://developer.mozilla.org/en-US/doc ... g_requests

If Firefox extended the webRequest API with say a blocking onRequestCancelled in which it's possible to redirect, what you want could work. As usual it's probably a case of having enough use cases to justify the development efforts of adding such API.
I couldn't find documentation of the details of user resources file format, but it appears it's of the form: [...] Is this correct, or is there more to it than this?
If you want to create scriptlet resources, probably best to use the new syntax instead of the legacy one. Examples of the new syntax are found in:

https://github.com/gorhill/uBlock/blob/ ... iptlets.js

Use three slashes to introduce key information to parser, two slashes will be discarded as comments. The new syntax does not need mime information. Avoid blank lines inside the scriptlet code, it's used to signal end-of-scriplet. I use two blank lines in uBO's code just to better visually separate scriptlets.
Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

barbaz
Senior Member
Posts: 9180
Joined: Sat Aug 03, 2013 5:45 pm

Re: Using uBlock Origin to replace NoScript surrogates?

Post by barbaz » Wed Sep 04, 2019 9:06 pm

Thanks for your help gorhill! With that I think I got this working.

I figured the best way to prevent silly mistakes on my part, would be to put each surrogate .replacement code in its own JS file, and use a script to dynamically construct the scriptlets resource file in the new syntax form:

Code: Select all

/// <filename>.js
{
<content of filename.js, with blank lines stripped, and lines starting with "///" changed to "// /">
};
<2 blank lines>
...
(The added { }; is for NoScript Classic parity. NoScript Classic runs each surrogate in its own block so that variables declared with "let" are private to the surrogate.)

I then created uBlock Origin filters with $script,redirect-rule= rule(s) for each surrogate, to be equivalent to the .sources values from the surrogates.

Then I went into uBlock Origin advanced settings, and set the userResourcesLocation, and set

Code: Select all

ignoreRedirectFilters false
Upon clicking "Apply changes", the custom scriptlets file was fetched.
(In my case I put the rules as a separate custom subscription. Seems like the custom scriptlets are also fetched when this new subscription is fetched?)

In testing, I only had to set uBlock Origin to block an affected resource in dynamic filtering... and the surrogate ran, even though NoScript was also blocking the resource! Image
I'm still not clear if this setup is reliable, or if I just created a race condition where uBlock Origin happens to be winning atm?
*Always* check the changelogs BEFORE updating that important software!
-

gorhill
Junior Member
Posts: 42
Joined: Sun Mar 30, 2014 12:19 pm

Re: Using uBlock Origin to replace NoScript surrogates?

Post by gorhill » Thu Sep 05, 2019 2:05 pm

In testing, I only had to set uBlock Origin to block an affected resource in dynamic filtering... and the surrogate ran, even though NoScript was also blocking the resource!
If NoScript blocked the request, there should be no redirection, as blocking has precedence over redirecting. Consider two extensions A and B:

Code: Select all

A           B          request
--------    --------   -----------
noop        noop       not blocked
noop        block      blocked
redirect    block      blocked
noop        redirect   redirect-B
redirect    redirect   redirect-? (implementation-dependent)
Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Post Reply