uBlockOrigin/uBlock-issues

Req: Allow '* * 1p noop' as a valid rule.

bs27975 opened this issue · 12 comments

bs27975 commented

Enhancement request: Allow '* * 1p noop' as a valid rule (doing the expected, for it's presence, given everything else / all surrounding uBo goodness already present.)

In trying to drink from the firehose that is (thankfully) uBo, is seems intuitive, already having a rule of '* * 1p-script noop', that it actually did '* * 1p noop' - that it does not was eventually realized. Attempting to add a rule of '* * 1p noop' was, of course, ignored. '1p' not being a currently understood beastie.

Could it made to be so. [This is an ease of use / understanding request, only.] The user would not then have to discern and 'greylist' the domain(s) of the currently visible web page, for each and every web site they ever visit.

  • principle being, let the domain of the web page being visited do its thing.
    • while not allowing that thing to be done at other web sites.
    • and while still not allowing other domains operation upon the current web page. (3p beasties, being blocked.)

As it would only effect (that domain) on that domain's web pages, (being '* *',) that it may inadvertently permit some static blocks through, seems unlikely to be an issue.

Edit:
Further observation, e.g. on calendar.google.com -

  • Until 1p noop'ed [google.com, thereby noop'ing calendar.google.com] (on calendar.google.com),
  • fonts.googleapis.com, googleusercontent.com, and gstatic.com were not visible upon drop down [click uBo toolbar icon {within Chrome}].
  • a '* * 1p noop' rule would have allowed these other domains to be immediately user visible, making it user enabling visible that some content remained undisplayed.
  • as it stands, that content remains invisible is not apparent until the 1p domains were 'greylisted'.
stephenhawk8054 commented

Can you give which rules you are using and describe which site is having issues in more details with screenshots?

Even in the hard mode, e.g all 3p blocked, 1p is already nooped, so I don't understand what you are trying to solve.

stephenhawk8054 commented

OP is likely referring to this post:

https://old.reddit.com/r/uBlockOrigin/comments/1bhztp3/1stparty_eg_examplecom/

Yeah I saw that, but I still don't get it. There's no reasons to use

* * 1p-script noop

since it's not blocked from beginning. Same as

* * 1p noop
gothic-bum commented

Right, it was explained to OP in the post that noop rules are used to bypass any inherited dynamic filtering rules.

And links to the dynamic filtering wiki pages were also provided to OP several times.

bs27975 commented

It's about usability and intuitiveness.

Further observation, e.g. on calendar.google.com -

above is an example.

Consider, for example, coming from ScriptBlock

  • unblock the domain and get on with your day.
  • equivalent in uBo is to (dark)grey images, inline scripts, 1st-party scripts, to get on with your day.
    • regardless of what is set elsewhere (user 'thinking') is just 'whitelist' (never mind wrong term/context) the page they're on, and get on with whatever they're in the middle of.
    • so whether or not that is impactful (for already being the default) the user is certain nothing else not yet understood is going to get in the way.
  • request is to make '* * 1p noop' a valid rule.
  • see above calendar.google.com example for a usability demonstration.

And links to the dynamic filtering wiki pages were also provided to OP several times.

AGAIN, references to go drink from the already known firehose are not helpful. Is they were going to be, the request would not have been posed in the first place.

stephenhawk8054 commented

So I'm using your ruleset

* * 1p-script noop
* * 3p block
* * image noop
* * inline-script noop

and access https://calendar.google.com

So what issue are you having on that site that you are trying to solve?

image

gorhill commented

Until 1p noop'ed [google.com, thereby noop'ing calendar.google.com] (on calendar.google.com)

What rule is blocking calendar.google.com?

gwarser commented

I think OP want to completely whitelist 1p requests. Answer can be: do not touch dynamic filtering, put @@$1p into My filters.

gorhill commented

I see the issue here as an XY problem. We are asked for a new feature, without fully disclosing the real world issue.

There is no * 1p * block rule, so why should there be a way to 1p * * noop? What actual scenario does OP have that a block rule applies to first-party domain? It is not disclosed. We are left to guess.

One guess is that OP has a lot of global block rules for specific domains, but doesn't want to create noop rules to unblock those specific domains when they are first party. f so, I can't comprehend having so many specific global block rules that setting a noop rule for those domains becomes a chore.

uMatrix had the concept of first-party rules, but then uMatrix was able to load hosts file as dynamic rules -- not the case with uBO. (correction: even with uMatrix one had to override specific block from hosts file -- the first-party-based rules were needed in uMatrix because first-party domains were blocked by default -- not the case in uBO).

bs27975 commented

I think OP want to completely whitelist 1p requests. Answer can be: do not touch dynamic filtering, put @@$1p into My filters.

By which you mean:
@@$first-party
and not:
$~first-party

?

[And if something else interferes, first party will be ${\color{lightblue}blue}$, and thus very noticeably being blocked, for the user to manually unblock on that particular website if so desired.]

I think OP want to completely whitelist 1p requests

Yes. Which is what I thought '* * 1p noop' would do (if allowed). [Premise being 1p stuff on the 1p site is not leaking outside 1p, while permitting the 1p stuff to operate as the site author's intended / expected.]

Point throughout has been (explicitly visible) usability, especially for so called newbies just trying to get a handle on drinking from this fire hose. Not only be done, but seen to be done. '* * 1p noop' would do that by making first party dark grey in the dropdown. [As even @@$first-party does not (get made visibly dark grey).] Visibly not blocked flies under the radar, while visibly excepted does not.

If the above holds correct, then some text to that end within https://github.com/gorhill/uBlock/wiki/Dynamic-filtering would be useful. [Although the request for '* * 1p noop' being accepted still stands, making 1p entries go dark grey, and so be more visibly in effect, to the user.]

Responders simply referring to 'https://github.com/gorhill/uBlock/wiki/Dynamic-filtering/*' without context is very irritatingly unhelpful. Assume the poster has already done so - but, obviously, not yet correctly consumed all of the material and consequent nuances. Instead, write "If you would notice this text about such and so at <this> link, you will notice this and that which applies to your description." - if you actually wish to be helpful, and not just irritate into making yourself seemingly irrelevant.
[Just re-reading the same content incompletely understood the first time, without such context, makes the energy consumed to write the link, pointless and counter-productive.]

  • 😕1
gorhill commented

I think OP want to completely whitelist 1p requests. Answer can be: do not touch dynamic filtering, put @@$1p into My filters.

Yes.

I prefer to decline.

garry-ut99 commented

In such case, such an answer has been already provided also here:

However, (just an information) it's worth to mention that exceptions like @@$1p work only on static filtering level, which means they don't have effect on filters which contain important : https://github.com/uBlockOrigin/uBlock-issues/wiki/Static-filter-syntax#important, which might be an issue for some users.