Adding blacklisted SSL really sets ublock apart. When it might push the limits of the parser: drop the malware feature: (90% ordinary Chrome users have Chrome's safe browsing on, of those 80% have an AV, so what is the added benefit) Here are some more https://launchpad.net/ubuntu/ source/openssl-blacklist/ http://codefromthe70s.org/sslblacklist.aspx
There is no "malware feature" per se, it's just hosts files which purpose is to block requests to malware sites. There are other hosts files in there with other purpose. The support of these hosts file already set uBlock apart from other popular blockers, I can't drop that.
I feel adding blacklisted SSL part is a good thing...but not sure how much of an impact to the ublock engine. I hope gorhill will take a look at this request one more time.. Also, if the chrome's safe browsing is on, (which is set to ON by default) - how much is the added benefit of malware lists in ublock? which one can be disabled safely? If its covered by chrome already, i think it can be safely disabled, and thus reducing a little overhead on the engine.. Edit 1: If adding support for another format, pushes the limit of ublock, perhaps you might add some kind of wrapper to the extension itself, whose sole purpose is to convert this lists to one of ublock supported format. i know its not an elegant solution, just a random thought..
Agreed! If someone really wants to rely solely on chrome's safe browsing (I wouldn't), he/she can easily disable the hosts files.
No most AV's have URL blocker and most IE and Chrome users have safe browsing on. How much will uBlock stop as the third in the row? Do some tests you will see how little traffic is blocked. The issue is not the sole usage of Chrome or the ability to turn them off, that is all true. Raymond said that the parser would be pushed to its limits when a third would be added. When that is the case I would opt for real security (first safety net for blacklisted URL's) in stead of piece of mind security (of a third safety net). But the answer of Raymons is clear, it is his time and effort (I am using uBlock as a replacement of Addblock, also enjoying the blocklist on IP-address).
Why don't you provide some evidence for your claims and do the test yourself? Head over to MDL or wherever and post back the results. Most doesn't mean all, and going against user choice is not the way to promote yet another list for yourself and a few others. The issue is their format, Ray can add whatever he wants easily as long as they're supported. Yet you think removing some simple work is equivalent of the complex task of supporting another format? Why do you even want to remove them in the first place, what kind of improvement is that? There is no comparison, one instead of the other doesn't even apply. As for "real security", I could argue browsers and many AVs handle SSL perfectly fine already tyvm. Once again, do provide some evidence before such grand claims that an average user would benefit more by having SSL blacklists and doing without malware blacklists.
Probably something is lost in translation: I said "that is all true", so not going against user choice. Also I don't want to remove them, Raymond said that supporting a third format would push the limits of the parser. The host (IP) blocklist are also used for ad-blocking not only malware blocking (what Raymond's made clear), therefor I said that I am enjoying ad blocklists based on IP. Do you know which AV's check on blackisted SSL certificates?
The IP addresses in there are not the issue, it's supported by uBlock without any problem. It's the parser, i.e. piece of code which reads in files, parse the content. I looked into it and it would current fail parsing that specific file format. Ideally, it would be nice that whoever is responsible for these lists to just make available a hosts-compatible format, so it can be used more widely, including uBlock and HTTPSB.
I won't drop hosts files support, it's used for more than list of malware hostnames. It's also used for ad servers, trackers, nuisances, etc. It's just not going to happen. When I said "pushing it", I meant "yet adding another code path to the parser for yet another format, aside ABP- and hosts-filtering". As a developer I resist adding code paths because it's added complications, higher likelihood of bugs, etc. But it's entirely possible, I could create ugly hack to detect something specific in this file so that I trigger on the ability to parse this kind of specific CSV format. Ideally, whoever is behind that file could just make a format which is already widespread, like hosts, or just a list of plain hostname/port.
Sorry, too many things in my head at the same time. Edit: I though about contacting the site to ask if it was possible to provide a plain list of IP addresses etc, but I am such a nobody that when I faced the contact form I became pessimistic and thought that was pointless.
One question for developer: is µBlock compatible with 64 bit Chrome? If not, will it be when Google releases 64-bit version?
It's plain javascript code, 32-bit or 64-bit is irrelevant at this level. It will consume more memory though, like all other extensions. I have been using Chromium 64-bit since the beginning.
It lists all items which can be blocked on a page with a search field. I don't like to use lists with adblock, so when something can't be blocked by NoScript, I'm adding it to adblock.
Well the element picker will offer you whenever possible a net request filter. Otherwise there is issue #68 which I suppose would address this?
To be honest I had no idea about element picker. That icon, I thought it is a quick way to whitelist the website.