Add the I don't care about cookies filter to Regions, languages?

[ghost]

http://www.kiboke-studio.hr/i-dont-care-about-cookies/
Found it in Miscellaneous section of https://adblockplus.org/subscriptions
I don't know much about filters, but it has allot more then prebake. I'm guessing more is better ^_^

[gorhill]

That list is quite suboptimal for uBO to say the least, it prefixes all generic cosmetic filters with body [#.], which prevents uBO from optimizing their use. Unless somebody removes instances of body for filters matching /^##body [#.]/, I would advise strongly against using it with uBO.

[kiboke]

Hi, am am the author/developer of that list.

I can't optimize it as suggested, there is a reason why I built it this way. There are quite a few websites that put IDs and classnames (related to cookie warnings) on the body tag itself. If I do as suggested, all of them would appear blank and would need a filter exception. Would entries like #some_id:not(body):not(html) be more acceptable?

[gorhill]

There are quite a few websites that put IDs and classnames (related to cookie warnings) on the body tag itself

What you are talking about concerns only one entry in your list:

##body.cookieBox #alertBox

What I am talking about concerns almost all generic cosmetic filter in the list. An example of an entry -- the 1st one:

##body #sliding-popup

This means that the target element is a descendant of the body element, not that the id is on the body element itself. By order of efficiency, uBO is optimised to deal with cosmetic filters as follow:

• Specific cosmetic filters -- example: theguardian.com##.identity-noticebar-content:
  • These are just injected blindly whenever landing on the specific site, theguardian.com here.
• Generic cosmetic filters: injected on a per-need basis -- uBO surveys the DOM.
  • For ABP/AB/Adguard, it makes no difference, they are all injected unconditionally anyway.
  • Low generic cosmetic filters: no hostname, but starts with # or .. These are dealt with efficiently.
  • High-low generic cosmetic filters: of the form [alt="..."] or [title="..."]
  • High-medium generic cosmetic filters: of the them [href^="..."]
  • High-high generic cosmetic filters: everything which does not feed previous category.

The ##body #something or body .something filters end up falling in the high-high generic category.

The only reason I could think the filters were designed this way in your list was that you wanted to augment their specificity maybe to ensure the CSS rule has precedence over a page's own rule. For uBO this is rarely an issue because the filters are inject after the page's own CSS rules are loaded -- so the last CSS rule, which is uBO's one -- wins.

When I saw your list yesterday, I thought maybe I could remove the unnecessary body prefix at pre-compile time, but I haven't decided yet.

[kiboke]

It is not unnecessary.

I think you didn't understand me. There are websites with, ie. body id="one-of generic-selectors" or html id="one-of generic-selectors" and then again inside body they have div id="one-of-generic-selectors". If i remove "body " part from the rule, the page will appear blank. And there are different websites which do that with different generic selectors.

How can i avoid these websites turn blank without targeting elements only inside the body?

[gorhill]

If i remove "body " part from the rule, the page will appear blank.

Ugh, ok I see. Surely your suggestion of using:

#some_id:not(body):not(html)
.some_class:not(body):not(html)

Would work well for uBO, while probably making no difference for ABP and al. For uBO, this would move all those high-high generics into the efficiently-handled low generic category.

[corrected selectors]

[gorhill]

@kiboke

If the form ##body #[...] or ##body .[...] was more commonly used, another solution is to have uBO translate such filters at compile time to use the :not-based form -- but currently I can't find any other filter list using that form. This would not require adding any overhead, as that code would be executed only at compile time for when the filter is found to be high-high generic, a minority of filters. Let me know what is your decision.

[kiboke]

I can rewrite rules like "body .something" to ".something:not(body):not(html)". Would that be ok then?
I am aware it is not the prettiest code ever but... what can we do...

[gorhill]

Would that be ok then?

Yes that would work for uBO, all these filters would become low-generic, i.e. efficiently handled. Keep in mind this is not required for cosmetic filters which are to be applied to specific hostnames (.e. example.com##body .toto).

Incidentally, I notice you already have some generic filters in there with the form :not(body):not(html).

[kiboke]

i do, because some websites put a div directly into html tag, outside of body, lol.
i'll do it and reply when it's done.

[ghost]

@kiboke Any news?

[kiboke]

i prepared it, it will be available in a week probably along with the new "I don't care about cookies" extension version. I'll let you know.

[gorhill]

@kiboke

I had what I think is a good idea for making uBO classifies these cosmetic filters as low generic, and this is probably a better approach, as this removes what may appear as an arbitrary restriction to filter list maintainers. So it's up to you, you may prefer to not go ahead with the change if I can provide a more generic solution in uBO.

[kiboke]

I have already prepared what was needed to be done, it's just not published yet.

[LifeIsStrange]

Why it exist 3 lists (maybe more) for block cookies related messages ?
There is the I don't care about cookies list but also this https://github.com/r4vi/block-the-eu-cookie-shit-list
And this https://raw.github.com/liamja/Prebake/master/README.md
We should all benefit if this three list was merged for be more used and for share the work ;)

[kiboke]

I agree.

I created my own because people asked me to do it. And if I see correctly, my list is waaay better than these two.

[LifeIsStrange]

So you could speak at the developpers of the two others lists for merge and share work :)
It's the free software magic, because you have the same finality you can cooperate instead of compete and create doublons.
But you are the owner of your list, so as you wish ;)

[gorhill]

In any case, v1.3.6 (dev build available) can now load that filter list without the performance hit of causing thousands of high-high generic cosmetic filters being created. The fix was just to make uBO works a little bit harder to find a class- or id-based part in a whole CSS selector at compile time. This addresses the concern I had here for that specific filter list without the need to change the list.

[kiboke]

It would be even better if uBlock (and others) would filter out possible blocking of body and html, so i don't have to put :not(body):not(html) everywhere.

Someone may put, ie, id="Banner728x90" on body itself, god knows why. With uBlock or ABP, the whole page becomes hidden when it really shouldn't be, right?

[dungsaga]

@kiboke : Your idea could be useful for other list maintainers. I like it.

[kiboke]

@gorhill, i published the new version. your update certainly helps because some rules still have to have "body > " or "html > " prefix for some special reasons, although most of them have lost it.

[kiboke]

what's exactly broken?

On 01.12.2015 12:25, IDKwhattoputhere wrote:

I tried the filter list a few days ago because it seemed more thorough
than Prebake. I can confirm it is very thorough. Broke like every 3rd
site for me. I guess it's new and may get some fixes but at the moment
it seems unusable.

—
Reply to this email directly or view it on GitHub
#909 (comment).

[ghost]

A few days ago it completely hid vpnbook.com (like the entire site except the background color). Seems to work now :) (that's why I had deleted my response since I tested again and now don't have any problems anymore).

[Ronnie91]

Hi @gorhill,
how come you have not added the subscriptions "I don't care about cookies"?

I'm not finding any problem, indeed.

Best regards and Happy Holidays!

[gorhill]

Given that the author of the list prefers that users use the list through his extension rather than through a blocker^[1], I will decline adding it to uBO. I added the list to the "Filter lists from around the web" wiki page though.

[1] http://forum.palemoon.org/viewtopic.php?f=46&t=10585#p73651

[kiboke]

gorhill, it's only logical to use the extension instead of the filterlist (when possible) because the extension should do the task better. the extension is not available for all platforms, that's where the list becomes handy.