Static filtering: Cannot prevent my filter from strict-blocking

[laniakea64]

Steps for anyone to reproduce the issue

1. install uBlock Origin, restart browser
2. Dashboard > My filters, add this filter

||noscript.net^$~document

3. visit https://noscript.net/

Expected results:

Page loads, but looks badly mangled due to all first-party resources being blocked.

Actual results:

Page is strict-blocked by uBlock Origin -

uBlock Origin has prevented the following page from loading:

https://noscript.net/

Because of the following filter

||noscript.net^
Found in: My filters

Your settings

new profile

• Browser/version: SeaMonkey 2.46
• uBlock Origin version: self build from 2d3cc2b

Your filter lists

default

Your custom filters (if any)

||noscript.net^$~document

[gorhill]

I agree that the page should not be strict-blocked (I will fix this), but I disagree that the page should be mangled because all other resources are blocked: the filter should result in no blocking at all.

There are request types which are standalone, and for these types, using the ~ should result in a noop. These types are:

• document
• generichide
• inline-script
• popunder
• popup

These types do not really map to network requests, and need to be tested separately and explicitly.

[gorhill]

😕

I rather you argue to convince me why you think it should different.

If you hold that ||example.com^$~document should result in all resources being blocked , then the logical consequence is to also hold that ||example.com^$~script should result in example.com being strict-blocked. This is really not the desirable behavior, that would be unexpected. Hence document has to be evaluated as a standalone type, without bleeding into other network request-based types.

[laniakea64]

I think I see what you're saying, let me restate it to be sure -
Unless told otherwise, uBlock Origin assumes all network request options apply. Thus, if $document is converted into a network request option, every filter would do strict-blocking unless $~document is added by the filterlist maintainer (in this case me). And we both agree that would be ugly. Correct?

---

The problem is this - the $document option is implied on some static filters. The filterlist maintainer doesn't specify that these filters should do strict-blocking.

Now, the implication is usually desirable, so it's a good default. But as I found out, there are exceptions.

So how can the filterlist maintainer disable the implied $document for one specific static filter? Well, I thought, since there isn't a documented $nostrictblock option, what's the opposite of $document?

---

I don't mind if $~document can't be used for this. As long as there is a filter option to prevent a static filter from strict-blocking, it works for me.

[gorhill]

So how can the filterlist maintainer disable the implied $document for one specific static filter?

There is an open issue for this: Cannot set exemptions to strict blocks.

I do still wonder if supporting @@...$document could have unforeseen effects given that the same syntax is used in filter lists to whitelist a site, while in uBO it would be to counter a blocking document filter.

Of course for now for your specific case, there is always: no-strict-blocking: noscript.net true.

[laniakea64]

There is an open issue for this: Cannot set exemptions to strict blocks.

That's for the ability to write whitelist filters with $document. It would not be equivalent to a filter option.

Consider these filters -

||example.com^
||example.com/foo/$document
! assuming https://github.com/gorhill/uBlock/issues/1754 is implemented
@@||example.com^$document

That second filter would need a ,important added to have any effect. But I might not be able to add it - it could be part of a 3rd-party filter list that I don't control. I'd have to know about the filter, copy it to my list, and add the $important option.

Now consider these filters -

! https://github.com/gorhill/uBlock/issues/2385 meaning of $~document
||example.com^$~document
||example.com/foo/$document

The second filter would just work, without need to carry around $importants everywhere.

Of course for now for your specific case, there is always: no-strict-blocking: noscript.net true.

Thanks, that would work for now for the case that brought this on.

[gwarser]

If you hold that ||example.com^$~document should result in all resources being blocked , then the logical consequence is to also hold that ||example.com^$~script should result in example.com being strict-blocked.

Now $document work like this for domain-only filters:
||example.com^$document,allresources - all network-like types implied.

On the other hand, network-like filters are excluded when $document is used with path-like filters
/foo/bar$document,~allresources

$document option should only enable blocking of main document. Should work for path-like filters, because for domain-like filters is now implied. Should not interfere with network-like types.
$~document should disable blocking of main document for domain-only filters. Network-like filters currently implied - good.

Then if network-like filters are implied, we need to negate whole list of network filters to achieve document-only blocking. For convenience I propose new filter option that will include all network-like filters.
$resources, $all, $network, $strict(?) ?

||example.com^ - network and document implied
||example.com^$~network - blocks only main document ($document implied). Should work like /foo/bar$document is working now.
||example.com^$~document - block only network-like types

/foo/bar - network implied
/foo/bar$document - network and document OR
/foo/bar$document,network - to block both if default behavior will not change

/foo/bar$~network - no blocking for network-like types (do not interfere with $document!)

@@||example.com$document^,
@@||example.com$~network^ - whitelisting, no-strict-blocking
@@||example.com$~document^ -> @@||example.com^
@@||example.com$network^ -> @@||example.com^

[gorhill]

These filter options ...

popup, popunder, document, generichide, inline-script, csp, redirect, webrtc

... cannot be negated, it just makes no sense. When uBO encounters something like ~inline-filter, it just discards the option.

[gwarser]

Cannot be negated, but can be disabled or excluded.

When uBO encounters something like ~inline-filter, it just discards the option.

So if you decide to automatically include inline-filter for domain-only filters, then this cannot be "negated"?
How about $~subdocument?
If I want to whitelist page, and still prevent popups? @@||example.com^$~popup? :)

[gorhill]

If I want to whitelist page, and still prevent popups? @@||example.com^$~popup?

Given this conversation, would @@||example.com^$all,~popup be fine? (this wouldn't solve the document issue for hostname-only filters though, this one is special).

[gwarser]

I just read again my above comments, and sorry, but I try again: maybe I was using "negated" in wrong context when referring to "~document" option. By "negate" I did not mean to invert whole filter set, but instead just flip one bit in set - switch off only "document". Negating "network-related" option should invert whole set of network options, but why not negating "behavioral" filters can just turn them on/off one by one?

[gorhill]

but instead just flip one bit in set

Yes, that is the exact change I did as part of all support I implemented locally. Currently code reviewing. This just won't work though for the issue raised here because there is no bit set in the first place, since document is implicit for pure hostname-based filters.

[gorhill]

Just to be clear @@||example.com^$~popup will still do nothing, however @@||example.com^$all,~popup will now work. The all option will allow users to be explicit about what ~popup and such means, whereas there is no ambiguity with ~image because as per filter documentation it means "all network-based requests except images".