It's not just memory overhead, it is also CPU overhead.
One approach is to write the filtering engine from scratch. It is what I did, without looking at ABP's code beforehand in order to ensure a clean slate mind.
I didn't get it right the first time, I did spend quite a large amount of time benchmarking, measuring, prototyping, etc.
Once I was satisfied I had finally had a solid code base, I went and benchmarked it against ABP to find out how it compared:
As far as I can tell, HTTPSB is not available for Firefox, please fix!
I would love to use something better than ABP (in terms of performance, it does content filtering just fine), but I'm not so desperate to abandon the (warning: subjective content ahead) greatest browser of all times to lower the memory footprint of an ad blocker.
Would be nice if someone forked and start to adapt to Firefox. I would of course work in concert as this would allow to identify parts of the code which is browser specific and which parts can be turned into an independent library.
It however would be really awesome for HTTPSB (which I just installed on chromium and fallen in love instantly with) to be ported to firefox.
Seeing all the privacy-related features treated, by domain/site/everywhere rules, being able to block separately js/plugins/cookies (and by the way, the matrix is a great idea, a lot more useable than anything else out there)... in one extension only. Great work already, gorhill!
Whitelist the "cookie" cell in the matrix, save with one click on the padlock. Now cookies will be allowed everywhere by default (except for those ubiquitously blacklisted hostnames).
Unfortunately the developer is MIA, so the few bugs in the beta aren't going to be fixed anything soon. The most important feature of the beta is wildcard support, so you don't need to add every cloudfront sub-domain manually.
I did not like the beta interface for RequestPolicy and I hacked in support for using regex matching for whitelist entries so CDN domains like CloudFront work correctly.
1) I have absolutely no intentions of continuing any work on my hack. The changes I made meet my needs. Feel free to fork if you need additional features.
2) I don't pretend to be an elite javascript developer. I have no idea if my hacks are considered idiomatic javascript or not. I also make no promises that running my hacked version of this extension won't upload all your private data to a server in Russia or cause other problems like having your hard drive explode in a ball of fire.
Just installed the extension and it seems great. Particularly like the matrix UI for allowing/blocking things.
However, I definitely don't want to micromanage things like accepting scripts and cookies for certain sites I use. Is there a way to make it work essentially the same way as AdBlock does? Tried to look in the wiki but didn't find anything.
You can select a "scope" (top-left cell in the popup) which will tells where the rules apply. You can set it to automatically create a temporary domain-level scope when landing on a web page (in Settings tab), and if you select this, I suggest you also select "Auto-delete temporary scopes".
Now any rules will apply only to that scope. For web sites you use regularly, just lock down these rules for that scope, and they will be remembered every time you visit that particular domain.
This is actually the preferred way to use the extension, but I did not make it the default currently.
Note though that this will work best with the upcoming v 0.9.2.0 which supports almost all net request-based ABP filters (my benchmark on github was updated yesterday for that version).
In the above setup, HTTPSB has been set to work in allow-all/block-exceptionally mode, so nothing is blocked except for what appear in the above files.
Keep in mind that HTTPSB doesn't do element hiding (I see this as a separate extension.)
Thank you for putting in the effort to make this more usable out of the box. I will be all over this once the ability to use these filter lists is easy to access.
I'm with this guy, I don't really want to spend much time filtering/selecting. If I can block 90% of the crap in seconds vs. 99.9% of the crap with several day's investment in customizing the filtering, I'll take 90% please.
Thanks for providing the "adblock-like" preset, that was just what I was looking for. Then from here, if/when I run into particularly horrific js, I can block it one-by-one.
... and AdBlockPlus developers closed the issue. One of the reasons given: "missing features [of HTTPSB] are an issue [...] (filter groups, hit statistics etc.)". One of their devs adds "They don't support element hiding, which is one of the main causes for the high memory consumption when using Adblock Plus. Neither do they support popup blocking. [...] [T]here still might be some parts where we can learn from HTTPSB. But the main reason that it is faster and uses less memory is that HTTPSB is less powerful."
It's not easy to try to fit new code in old code, I empathize completely with that.
This is where I was at an advantage, I was writing new code to fit with new code. There are ideas though that were keys to performance breakthrough which they certainly could borrow.
By default though it comes in block-all/allow-exceptionally mode, just like NoScript and RequestPolicy.
Eventually, as usual, as time permit, I would like to have a wizard for first install which will let the user choose which setup (from the ones above) is preferred to get started.
Am I doing something exceptionally wrong? I click Restore from file in scoped rules, and then decode recipe. That gets me more json on the left (in a red box, so I assume parsing failed). I then try "Import Rules" and nothing seems to happen. The commit button at the top never allows me to click, and nothing changes.
This is using the abp setup (and a few of the others in stuff/), none of which worked.
Please post to HN when you have some sensible default config options built in! I really want to try your tool but can't be arsed to whitelist everything one by one.
The plugin looks really interesting, but I wish it would give more detail about the requests that were blocked/allowed and a better explanation if I blacklist something, is that permanent or do I have to save it each time?
All changes to the matrix are temporary by default. Click the padlock to make them permanent. At first, this might be annoying (though it is just one-click to make it permanent), but once you have all your rules for your usual sites, it's nice that all is temporary by defaults.
There is a request log in the dashboard/Statistics tab where you can see in details (full URL) what was blocked or not.
Does HTTPSB have a keyboard interface? I just installed it and it seems great, but I'd prefer to not use the mouse. E.g. NoScript has Ctrl+Shift+\ to temporarily whitelist the current page's domain and Ctrl+Shift+S to open the drop-down, and the drop-down works well with the arrow keys.
Someone else at some point asked for a pull request for keyboard shortcuts (and other stuff), but at the time I thought that the extension wasn't stable enough feature-wise, and I didn't want to deal with anything which would need constant revision before the feature set stabilize. For instance, I eventually trashed the context menu code that was put in too early because of this.
But now that it definitely is approaching v1.0, it probably does make sense to address that issue.
I've been using HTTPSB since the last time you answered a few questions for me on HN (about a week ago?) and I must say: stunning work!
A quick question: is there a keyboard shortcut I'm missing to enable/disable the request blocking? For the time being I do Cmd+L, Cmd+C, Cmd+Shift+N, Cmd+V to copy the URL into a private browsing window, but it'd be nice to just temporarily enable full functionality on the page, and then disable when I'm done.
Also, for those using the extension: there's a built-in set of rules to enable browsing Google sites: search, gmail, etc. that you can enable by clicking the puzzle piece in the HTTPSB menu. Very helpful.
By default all behind the scene requests are allowed (or else that would break auto-update and other extensions), but you can make it block everything (except of course for those net requests which are not routed through the chrome.webRequest API).
It is quite useful to also see (and control) net requests made by other extensions.
I think you'd see much greater adoption if you included the core HTTPSB library within an easier user interface, specifically targeted to blocking ads / ensuring privacy. At the moment it's a hacker tool that can block ads if you configure it correctly.
If that's not what you're interested in, more power to you, it's just a suggestion since the use-case isn't obvious especially to a "regular" user.
It all depends how you use HTTPSB, I can't decide for you.
For one thing, HTTPSB doesn't hide DOM elements (I consider this out of its primary purpose), so if you still want this feature, you will have to keep ABP (or whatever equivalent does element hiding).
As for Ghostery or Disconnect, they still can be useful if you use HTTPSB in a permissive way (allow-all/block-exceptionally).
You could even use HTTPSB to block nothing at all, but as a mere reporting tool (with very low footprint), to find out what the other blockers did not block, as net requests will still be reported in the matrix.
I think there are red and green elements there, but can't tell which is which. Also, I don't know how to set them to red or green specifically as I can't seem them. :)
Could you maybe include a check mark and an X or some other non-color dependent means of portraying that information?
I know nothing about color-blindness though, so I will need the input of color-blind people. If there is an option to use blue instead of green, would that work?
That would work for some. The best path would be to not solely rely on color for information representation. Add some other visual element, such as a pattern to the color, or a small icon.
And even to the extent that color is being used to convey information, don't rely solely on hue, make sure colors are distinguishable by value as well (in the case of text backgrounds, this is sometimes a better option than a pattern).
It seems to have noscript-level manipulation functionality, which I believe means "no". It appears to be able to block anything & everything, so you would just need to make sure you have the right filtering settings.
httpswitchboard looks like a very interesting extension. I haven't payed attention to what's happening with Chrome the last couple of years, but does this mean that you can finally genuinely block requests with Chrome extensions (something that has long been a problem with Chrome's Adblock extensions)?
This is my new favorite thing. It took me a few moments to 'get it' - eg sites like HN not loading by default, until I enabled them n the matrix display, but I worked it out without by experimentation very quickly and I love being able to edit preferences so fast. Well done, fantastic work.
Since everyone is talking about HTTPSB here, one wish from me. I think it would be easier to use, especially for newbies, if you would use text everywhere instead of icons.
I am also a bit confused if settings apply to the current domain only or not, some behaviour suggests they are global but I have to test this.
One approach is to write the filtering engine from scratch. It is what I did, without looking at ABP's code beforehand in order to ensure a clean slate mind.
I didn't get it right the first time, I did spend quite a large amount of time benchmarking, measuring, prototyping, etc.
Once I was satisfied I had finally had a solid code base, I went and benchmarked it against ABP to find out how it compared:
https://github.com/gorhill/httpswitchboard/wiki/Net-request-...
And for HTTPSB's numbers, keep in mind there were an extra over 50,000 rules in the matrix filtering engine (something not found in ABP).
So I think this shows clearly ABP's code can be improved.