Loading…
Hiding elements blocked by HTTPSB #87
3 participants
I don't see the placeholders. Never mind, if I enabled js for the site, I see them.
What lists do you have enabled in HTTPSB?
I'm using:
Long-lived malware domains (malwaredomains.com)
Malware domains (malwaredomains.com)
Peter Lowe’s Ad server list (yoyo.org)
Malware Domain List (malwaredomainlist.com)
hpHosts’s Ad and tracking servers (overzealous lately) (hosts-file.net)
Dan Pollock’s hosts file (someonewhocares.org)
MVPS HOSTS (mvps.org)
Spam404 (spam404bl.com)
hpHosts’ HOSTS (hosts-file.net)
Use this cosmetic filter:
www.spiegel.de##a[href^="http://adserv.quality-channel.de/"]
That will collapse a lot of requests which were blocked by HTTP SB on the page. To see these hightlighted, bring the element picker, click randomly, and enter ##a[href^="http://adserv.quality-channel.de/"] in the text area, you will see them highlighted throughout the page.
Ah - thanks! That solved it. However, this rule wasn't presented to me by the element picker. Shouldn't it?
Looks like I may have to give HTTP SB the ability to collapsed elements which resource were blocked. Even though I assume more technical users for HTTPSB, this is not very practical to have to go through above steps to hide with uBlock what was blocked by HTTPSB (uBlock has no idea the requests were blocked).
It's in there somewhere in the pile of issues. I don't mind too much that part, it's really small piece of code -- nothing to do with full blown cosmetic filters or the UI-counterpart, the element picker.
this rule wasn't presented to me by the element picker
The element picker requires knowledge of how CSS selectors work. It will try to assist as much as it can, but in the end only a human can interpret what is onscreen and figure the optimal CSS selector to get rid of it. In the specific case here, I ctrl-click on the entry, and removed what appeared to be highly mutable, and used the ^= operator which means "match the beginning of". This way I found there were more than just the top placeholders, there were many throughout the page, and many at the bottom too.
Anyway, collapsing of blocked element has to be in HTTPSB, and creating custom cosmetic filters should become unnecessary eventually.
Although this cosmetic filter works great, it's not shown in the statistcs tab. Is this the intended behaviour?
Spam404 (spam404bl.com)
By the way, that list will be removed from HTTPSB eventually. Its format is ABP-compatible filters. HTTPSB will support only plain hostnames, or hosts-compatible files.
Is this the intended behaviour?
Yes. I don't want to conflate net and cosmetic filtering. Cosmetic filtering is completely unrelated to privacy-related issues.
Thanks again. The filter you presented is a good example for other cases.
I don't want to conflate net and cosmetic filtering. Cosmetic filtering is completely unrelated to privacy-related issues.
I think we discussed this earlier already for HTTPSB. Although I agree with your statement, we should acknowledge that there can also exist false positives for element hiding rules in the ABP filter lists. If such a false positive breaks a website, the µBlock user would never know why because he doesn't see that such a rule was triggered.
What is the recourse for a uBlock user for when a web site breaks? To disable uBlock for that site. It's the only solution whether the user knows the number of elements hidden or not.
As a developer, I see consequences when introducing new features: this will lead to more feature requests, which themselves will lead to more feature requests, bloat, overhead, inefficiency. So I will be very strict about what features make it into uBlock, and for the new HTTPSB, I am actually revising all those features which I should not have put in.
For instance, if I show the number of hidden elements on the page, this means new code to actually count the number of elements hidden, code to message back that information to the core extension from the injected script, increased code size for injected scripts (meaning increase memory footprint for every single page/frame). This also means as a consequence users now dreaming new feature of seeing which cosmetic filters was used, hgher memory footprint because internal store to keep track of what filters were used, a UI to show such a list, and that itself will lead to users dreaming a new feature where specific cosmetic filters could be disabled for a single web page, etc. etc. I just see feature creep ahead.
I am not against introducing new features, but I will play stubborn devil advocate against to ensure if a feature is accepted, it's because the case for was really made.
What is the recourse for a uBlock user for when a web site breaks? To disable uBlock for that site. It's the only solution whether the user knows the number of elements hidden or not.
Okay, but then a hint should be added to the statistics tab and to "3pParseAllABPHideFiltersInfo" that cosmetic filters are not logged, IMHO. I guess that many users do not really differentiate between network and cosmetic filters or are not aware of them, respectively. So they might desperately search for other reasons why a site doesn't behave as expected since they don't see anything reported in the statistics tab. I understand your reasoning (although I don't know how much code would be required) but I think that the users should be informed about this in order to avoid any confusion.
What does ABP do?
I don't know. I haven't used it for a long time. I'll install to see waht it does.
EDIT: Just tried it. The Chrome version only shows a number in the badge and no specific infos about the used filters. I remember that the Firefox version is much better in that respect but I haven't Firefox installed right now.
I haven't seen that issue raised elsewhere. I'm paying a lot of attention to the feedback from wherever I can find such feedback which is done outside the context of github.
Whitelisting and blocking element manually were overwhelmingly in demand. I worked on these, as these were obviously inevitable given this was a recurring demand. I did not see a single demand for being able to see the number of hidden elements on a page. Chromium ABP doesn't have anything related to that. It's possible to find out on the Firefox version, but you really need to be a tech-savvy user, no way around it.
My point is, at this point I want to focus on things which are wanted by typical mainstream users. It's not like I am waiting idle for something to do. Once I fulfill those widespread expectations for such an extension, then I can go back to start addressing the next version of HTTP Switchboard, instead of keeping sugarcoating uBlock with features which are not really in demand.
FYI, determining the number of blocked elements in ABP (or ABEdge) for Firefox can be done by simply hovering over the toolbar button which displays a tooltip. I use this feature frequently.
If you go to
http://www.spiegel.de/you'll see at the top and the bottom of that site several placeholders of requests (probably webbugs) pointing to
http://adserv.quality-channel.dewhich are already blocked by HTTPSB. Although those placeholders are not really annoying in this case I've tried to hide them with µBlock but to no avail. Regardless if I chose a network filter or a cosmetic filter, the respctive placeholder vanishes but reappears if I reload the site.