µBlock, a lean and fast blocker

OK. Will disable that list.

 

Hi all, missed this discussion.

First of all, gorhill, good work! I've looked at your code and I like it.

Now I want to clarify some things about content filtering.

Let's use a simple example.
Imagine we have a page with a banner:

Code:

<img src="http://example.com/banner.png" />

Extensions way
This way is used by any extension, Adguard/ABP/Adblock.

1. Extension blocks web request to this image.
2. After page has been loaded extension inspects each element of the page using special javascript code. If the element retrieval was blocked, this code hides the element. If we don't do it you'll see "broken" image instead.

That's why when you use extension - you can see that some elements are hidden just after the page has been loaded.

Standalone program way
1. The image is removed from the page code before browser start rendering it.
2. Of course image retrieval will be blocked if program could not remove it from the page for some reason.

Removing images is a very simple example. The real pain for extensions are inline scripts. Anti-adblock scripts for example. If you use standalone program for filtering, it can simply remove this script from the page.

 

Fixed in 0.1.0.8.

 

Ok, that was my understanding, except that you clarify that ultimately whatever unwanted requests fall through the cracks are also blocked, so you have both mechanisms.

It's just that the wording to describe what extensions do kind of lead to confusion, as highlighted by how demoneye's understood it. I certainly can see advantage at pruning as a standalone, fast, and I suppose using a DOM parser library makes it easy. And yes, it is true that removal of the resource placeholders (after they have been blocked) is not too straightforward with an extension (I have an issue filed for that -- there are solutions but not straightforward).

Yeah on chromium-based browsers it's just not possible to selectively disable inline scripts reliably (or at all really, I haven't tried). It's all or nothing for inline scripts. I think some extensions were using `beforeload` event, but it's no longer supported.

 

I like Http Switchboard but this extension is perfect for me. uBlock and deny scripts from within chrome allowing TLDs .com .org .edu .gov is all I need.

Thank you.

 

OK, thanks. Will test it...

 

You are right, we should rewrite this post and make the description more clear.

We've tried to handle it somehow in our Chrome extension but have not found any good solution. But in our case we have another way to handle such scripts - we have javascript-injection filter rules. But you know, using these rules involves third-party code analysis and sometimes it is really hard. Removing script is just so easy.

 

so what u are saying is , ad guard (or ad muncher ) are useless and your add on provide same cleaning and BW saving?

 

No way, you will never see me describe other blockers as useless (unless they really are).

I just provide benchmarks, and from there you make your own call. One thing is clear, they are all useful, just compare with the numbers when you do not use a blocker.

I run these benchmarks very carefully, and I explain how they were conducted, so they can be replicated is someone wanted to. I completely stand behind these, and if there are discrepancies with third-parties (relative to me) benchmarks, then I will try to find out the reason. But my benchmarks so far match well those of Ghostery's own benchmarks.

Edit: By the way, in the benchmark linked above, what was measured for Adguard the extension, not the standalone. From the author's explanation above, the standalone would remove those ads that will normally reach the browser but are hidden by extensions -- for example the ads which come with a Google search results (with µBlock you might even see them a fraction of second). It's definitely an advantage for the standalone Adguard over extensions. Same kind of reason why I believe a lightweight proxy HTTPSB is a good idea, you can accomplish more this way. My error was to think Adguard was not also using request blocking mechanism, the author corrected me above, they also do this.

 

Your benchmarks portray your addon to block more than ABP, yet from what I understand, your addon is meant to be nothing more than a lightweight ABP.

So, what are you doing to cause this discrepancy? If you're using the lists at different dates, or using more lists than ABP, then it simply isn't a fair comparison. Is there some "secret sauce" in your addon that somehow reads the exact same lists better? Seems suspicious to me.

 

"Lightweight" resource-wise.

Than according to your rule, nothing else than good ABP clones can be compared to ABP. Can't compare ABP against Ghostery, Can't compare ABP against Disconnect. Can't compare ABP against Adguard.

Such nonsense. If you want to make a case my benchmark is flawed, make your own benchmark and explain how you proceeded, and come up with your own conclusions. I will be happy to review and comment on your results if needed.

It's not my fault if ABP doesn't support hosts files. uBlock does. And the comparison is still fair because these are meant to block ads and malware, which is what ABP asked me to choose when it installed.

The main point of my extension is that it can block more while using significantly less resources.

EDIT: typos

 

Well done, impressive one-in-all solution. Just added it to my Chrome (group policy) extension white list and removed Ad.... from the list

 

LOL!

I like how you mention 3 addons, none of which use the public ABP lists, unlike yours, lol. It's completely fair to compare your addon against Ghostery, etc. because they use their own internal lists, unlike ABP.

The fact that you're trying to market this with deceiving tactics like a businessman with something to gain even furthers said suspicion.

"My addon has better blocking power than ABP... because I have more lists installed than I do with ABP!". Ugh, yeah, congratulations on proving nothing.

Maybe just stick to "lightweight" being the selling point of your addon. Trying to state that it's better at blocking than ABP with flawed benchmarks isn't going to fly. I'm not saying being lightweght isn't a good enough reason to use this, or promote this over ABP. Just cut the "blocking power benchmarking" nonsense.

 

I guess, that it is not compatible with Chrome based browsers? I have disabled all extensions, cleared cache, but I am unable to install it.

 

Thanks for the suggestion, but I will keep highlighting that it does indeed blocks more while using less than half the resources, and actually prove it using benchmarks.

 

If I understand correctly, you are using Yandex on Windows? I will investigate and see what I can find.

 

Yes, thank you.

 

Ok I checked and I could install it both through the Chrome store, or manually using "Load unpacked extension...", so not sure what the problem is. I have Yandex 14.4 installed by the way, on Windows 7 (in a virtual machine)

The kind of message you get is something I have seen with HTTP Switchboard when the behind-the-scene matrix is in block mode: in such case that's the error message I get if I try to install another add-on, because requests to googleusercontent.com were blocked.

So somehow maybe some requests to the Chrome store are blocked? If so, you should have same problem installing any other extension from the Chrome store.

Edit: added last parapgraph.

 

I have tried a few more times and it works now, it downloaded some empty .crx files, but it is OK. Thanks for the effort.

 

Raymond,

Adding those malware lists is fine, but when using regular Chrome build in list, Would not Chrome will have them allready incorporated?

Regards Kees

 

You means the "Enable phishing and malware protection" setting? That's a good point. Is the list used by the browser available somewhere?

But still, I prefer to leave the user to uncheck those lists if they choose to. The thing is, other similar add-ons also offer "malware protection", I suppose this is still useful especially if a user uncheck the above setting for whatever reason (it was disabled in my installation in order to prevent silent requests to Google servers).

I was just trying to quickly check with HTTPSB if I would get hit on these lists by randomly visiting some of the top (bloated) web sites, and nothing was blocked, so I suppose it's a rare occurrence. But peace of mind is priceless.

 

Nothing on this? I'm seriously considering replacing ABP and HTTPSB here.

 

NGoogle makes it available through API-calls: see https://developers.google.com/safe-browsing/ Some claim a privacy gain when the API is used (only hashed URL's)

Maybe throw a question (do you have blabla enabled in A or B) and decide to enable or disable based on that answer.

Still technically a smart feat to combine public available blocking lists.

 

That's not a simple feature to implement, if I ever decide to implement it. As it is now, I lean toward keeping as boring as possible, it does appear a lot of people like it this way. Maybe I could fork another version, mBlock, which would have a bit more feature for the more technically inclined. But I would be spreading myself pretty thin (I think I am already). Best is to complete the task I set to myself to spin off a standalone library for the filtering engine, this part is the key characteristic of uBlock's low resource usage. With a standalone library, other devs could create something else with possibly features not found in the original very boring uBlock. (uBlock can already be forked if someone wants to improve on it, its GPL).

 

I see, but I thought it'd be easier like a copypasta from HTTPSB.