Description of the issue: How can this issue be reproduced?
Go to https://stackoverflow.com/ and bear witness to the horrendous cookie notice (bottom left, giant square).
In brave://adblock , enable Easylist-Cookie
Go back to stack overflow. It’s still there.
Expected result:
Cookie notice should be gone. I make this claim based on using what I presume to be the same list in uBlock Origin (uBlock Dashboard → EasyList Cookie). When I do the latter, it does kill that cookie notice.
Brave Version( check About Brave):
1.27.109
Additional Information:
This is not TEOTWAWKI but I wonder if this feature is working correctly, considering the above.
brave://components says the list is at version 1.0.391.
I can only reproduce the issue when Trackers & ads blocked is set to Standard. It most likely is related to that Standard doesn’t block first-party stuff and doesn’t apply cosmetic filtering to it.
For Standard vs. Aggressive, the issue (Cookie acceptance dialogue) goes away on its own when I use Aggressive mode, regardless of whether this particular list is enabled in brave://adblock – at least for this site. So then is it expected that lists enabled in brave://adblock are potentially partially neutered by ‘Standard’ Shields settings refusing to take action on first-party elements?
I would have expected the reverse, IOW that if you enable something in brave://adblock that those elements would be blocked regardless of Shields settings, but maybe this is a problem of misplaced expectations.
I’ll have to see if I can find another site to test this against, it would just be nice to see that brave://adblock settings actually work. Not sure how easy it would be to find a site that loads the cookie prompt from a 3P site that isn’t also already blocked by ‘Standard’ shields.
Ehm, are we talking about the same cookies prompt? The screenshot below features only Aggressive mode without the filter list being enabled via brave://adblock.
Yeah, same cookies prompt – large square in bottom-left corner.
Behavior was different here, it was as I described in my prior post – however it turns out that is apparently stemming from also having the “Fanboy Annoyances List” enabled. If I shut off all other ‘Additional Filters’ except that one, toggling it will change the behavior when toggling Standard <-> Aggressive mode.
So I guess getting back to the behavior/interaction between these two config methods, and seems consistent with your Fandom example, some (or all?) features of ‘Additional Filters’ are only enforced when Aggressive mode is used? Is that a fair conclusion to reach?
Fanboy Annoyances includes Easylist-Cookie and Fanboy Social. I couldn’t reproduce the same behavior as you once again, don’t know the reason for this difference, but also don’t understand why Easylist-Cookie hides the consent window, and Fanboy Annoyances doesn’t although the latter includes the first in it.
Standard blocking is more web compatibility-friendly, it does limit the extent of Brave Shields blocking so things break fairly less compared to Aggressive blocking. Further, Brave developers are working on implementing a flag that will be used to determine whether all sub-requests with the same eTLD+1 as the top level document (i.e., "first party requests") will be allowed in Standard blocking mode.
