kill @@$generichide and @@$genericblock pls! or at least allow to globally ignore those

[ghost]

Prerequisites

Prerequisites

• I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

Description

I'm starting to see trend in use of $generichide and $genericblock again.

it breaks a lot of good old, generic web-cleaning rules.

every d.bag only needs to add @@||d.bag.com^$genericblock
and @@||d.bag.com^$generichide
to immediately and effectively disable a lot of rules with very little effort.

it is pretty much just like saying: oh? you've got some rules? na, I don't like that, let me show you some ads regardless.

EasyList would have quite a lot *some* ^(edit) of those.
and a lot of smaller lists would copy from one to another,
spreading this cr^ap around.

this is essentially abusing the @@ syntax,
which was meant to unbreak site's functionality,
it become a kind of a master-switch,
being such a major game changer,
I would very much like (pls) a way to integrate a master switch of our own,
allowing us to prevent that syntax abuse..

...feel free to discuss/re-define this better if you have a better experience with those stuff :|

Ps.
allowing an even stronger override, such as:

• *$important,generichide
• *$important,genericblock
  would be hilarious!

thanks!

A specific URL where the issue occurs

https://blog.adblockplus.org/development-builds/new-filter-options-generichide-and-genericblock

Steps to Reproduce

0. varies with lists.

Expected behavior

ability to override, ..or something..

Actual behavior

1. being d.bag advertiser.
2. $$$ -> list maintainer: += '@@d.bag.com$genericblock' + '@@d.bag.com$generichide'
3. profit.

versions

uBlock Origin version

recent one.

Browser name and version

Chromium

Operating System and version

Kali Linux

[gorhill]

uBO does not support genericblock, and you can already use *$important,generichide if you want.

---

If you do not trust the list maintainers, you are free to not use their lists, you can maintain your own. It makes no sense to not trust list maintainers for a specific list and yet use this list.

[ryanbr]

EasyList and even AdGuard Base would have quite a lot of those.

We have only one genericblock; easylist/easylist_specific_block.txt:@@||spiegel.de^$genericblock,generichide

And we generichide for webcompat purposes, Where domains aren't serving ads. https://github.com/easylist/easylist/blob/master/easylist/easylist_allowlist.txt#L298

and some previous anti-ad cosmetic checks: https://github.com/easylist/easylist/blob/master/easylist/easylist_allowlist.txt#L379

Nothing "suspect" or anything, given you can look through all our commits, pull requests etc. We'll occasionally prune these when the sites remove the anti-ad cosmetic checks. I'll be happy to re-review these ghides later in the week

[iam-py-test]

Maybe I am wrong, but can't you badfilter the offending rule? (or, if that fails, do something like this [domain]##table,thead,tbody,tr,td,th:style(border-color:rgba(150,150,150,.30) !important; border-style:dashed !important; border-width:1px !important; border-collapse:collapse !important; border-spacing:0px !important;))
Not a pretty solution, but it works.

[JohnyP36]

Instead of using generichide to pass adblock detection it's better to make a specific rule for that domain allowing the request or element that causes detection.