HTTP Switchboard for Chrome/Chromium:

BTW: Smart auto-reload works again, too.

 

There was definitely a problem which could occur when loading the ubiquitous rules lists was more on the slower side than the faster side. Fixed in 0.8.4.2, which is currently waiting validation in teh Chrome store.

 

I've now removed ABP+

 

If I understand correctly, you suggest a rule which would look like, using the above example, "css $first-party", where "$first-party" would mean "top domain of the current page". Is that it?

This sure would make the extension even more malleable, where I get stuck is how can this be represented in the matrix without overcomplicating the current UI -- which I think is currently optimal for the majority of cases.

 

Thanks! Will be waiting for 0.8.4.2 build.

I have this problem (occurs randomly), extension icon stays gray color. Checked extension console, could not see any errors and it works internally by blocking the requests. but the count of distinct requests were not shown.

Thanks, harsha

 

I couldn't remember where I saw this request, and then I remembered somebody suggested this through email, and I had forgotten to enter it as an issue, so here it is: https://github.com/gorhill/httpswitchboard/issues/200

I didn't give any thought on how this could be implemented yet.

 

What browser + browser version? I think I've seen this, but very rarely, and I believe at the time my findings was that the browser was just slow at processing the browser extension icon change request. I will revise the code to see if I can spot anything.

 

I am using Chrome 33.0.1750.146. (stable build, private mode always on)
the good thing is
- It is just a cosmetic issue, blocking still works
- It is rare to reproduce
and not so good thing is
- It only happened or i started seeing with 0.8.4.1 build

edit 1: fyi, i dont have abp+ complex filters enabled yet

Thanks, Harsha.

 

V. 0.8.4.2 seems to have fixed those problems, indeed. Thanks, Raymond!

I just read your site about ABP complex filters. Very interesting! Just a few comments:

1. Regarding the memory footprint of ABP: Have you also looked into Adblock? It's a completely different project although it uses the same filterlists. Comparing the source code of both extensions might be interesting for you.
2. Using regular expressions has been discouraged for several years already, indeed, and I believe that only few ones are still used in the filterlists. Wladimir Palant even offers an online tool which translates regular expressions back into simple filters.
3. I understand that you haven't implemented an UI for the ABP filters. However, I'm afraid that it will be difficult to avoid it in the future (particularly once filters with options are supported). In my experience it's necessary to whitelist specific sites or, at least, disable specific filters for some sites in order to make them work properly. I don't see how that can be done without a UI.

 

Re. 1), no I didn't look at others. For now I prefer to keep a virgin mind with regard to how best to implement this. Once I had my prototype, I was just really curious as to why ABP was such a tax on CPU/memory. We both use a dictionary to lookup the filters -- because there is really no other sane way to do this anyways, but other than that the implementation is quite different.

Re. 2) Regexes are frowned upon in the filter lists, but ABP itself uses regexes internally to evaluate filters. This is another part which hurts performance and memory footprint in my opinion. My exprerience is to avoid regex at all cost when speed and/or memory are important. I have to look more to confirm my understanding of why he ended up using regexes (his solution to reduce the number of filter items per entry I believe), while my solution was to figure a way to generate a more distinct hash which would lead to a lower count of filter items per dictionary entry. The inadequate hash generation leads to the use of regexes, which lead to a (naive) caching mechanism, which leads to large mem and CPU footprint.

Re. 3) Though I am open to have a some sort of tab in the dashboard to deal in a finer grain way with ABP data.

 

Thank you Raymond for the good work on your blocker. This thread really should be moved into the security section of this forum if possible.

Just changed my signature and would not be running Chrome anymore without your extension

 

The person who sent the email probably wasn't referring to those pesky redirects in noscript tags. Just so everyone's on the same page, here's an example:

Code:

<noscript><meta http-equiv="refresh" content="0;url=http://example.com" /></noscript>

NoScript for Firefox has an option to ignore these:


https://i.imgur.com/hQm3wyp.jpg

Keep up the good work!

 

I wonder how HTTP SB works when combined with AdBlock, aside from that harmless extension error. Does it block first and AdBlock takes care of the rest? I have found that these two work fine together so far. When combined with HTTP SB I can forgo Fanboy's Annoyances and EasyPrivacy subscriptions and just use EasyList + Germany. That way both extensions together use less ram than AdBlock did alone before. Performance seems very good as well.

Of course I have disabled the complex AdBlock filters in HTTP SB in this case. They did nothing for me anyhow. Those pages which showed ads before still did so with the complex filters enabled.

 

Thanks - that's good May I suggest again that you look at Adblock? It has a very useful "list of blockable items". The Chrome version of Adblock Plus does not have that (unlike its Firefox counterpart). It might give you an idea how to implement something similar.

 

Are these ads blocked by ABP? If so, can you provide me a URL where I can look at why HTTPSB didn't block the ads. There should be a revision today to support more filters (those with wildcards), and also I have added all the lists which are listed on ABP site.

 

Which one is it? I just installed Adblock from "getadblock.com" and I didn't see any such UI.

Roughly my current thinking is that I would show all the filters which have been "hit" for a particular web page (page URL selectable thru a drop down) and so a user would have the ability to disable filters in that list. This would also serve as interesting information as to which filters had an effect on a particular web page. Maybe I could even extend the existing request stats to provide information about which ABP filter, if any, is responsible for blocking a particular request.

 

Yes, that's the one. Just click the Adblock symbol and you'll find it in the menu. It might be called resource list or whatever in the English version. The list has 4 columns:

The first column contains the element. It's red if it's blocked, green if it's an exception rule, and black if no rule is applied.
The second column shows the element type (script, graphic, css etc.)
The third column shows the filter rules for the blocked elements and the exceptions.
The fourth column shows if the element is 3rd party or not.

If you want to create an exception rule, you just click the respective blocked element which opens a dialogue where you can define such a rule (either global or site-specific). A new block rule can be defined accordingly by clicking a black element.

 

I see, found it. My first impression is that I don't think I would want to go to that level of details for HTTPSB, at some point, adding stuff endlessly is a sure way to spoil good software.

Having an extension dedicated to assist in building/diagnose ABP-syntaxed rules seems a more sensible option to me, so that the main extension doesn't become bloated with stuff which is likely less used by a majority of users. There could be a button somewhere to send the resulting filters to HTTPSB.

Side note, I see this one version of Adblock is even more demanding in term of resources than Adblock Plus, which I thought was itself quite taxing. It runs at over 3 times the footprint of HTTPSB.

 

I understand. It's difficult to find a good balance of usability and complexity.

I must admit that I've never checked that. I prefer Adblock over Adblock Plus because the latter doesn't have that list - and I like it a lot.

 

With the same subscriptions (Easylist + Easylist Germany + EasyPrivacy + Fanboy's Social Blocking List) both AdBlock and AdBlock Plus run at around 80-100mb in memory for me.

 

It does look like extensions consume more on linux -- I would like to understand why... I just tested in Chrome/Windows to check all is fine with 0.8.4.3, and I noticed that HTTPSB is significantly leaner on Chrome/Windows, settling under 20 MB after the garbage collector does it's job following the load, while on linux it settles at around 28 MB. So I suppose this applies to other extension as well.

 

Yes, when I have tried Linux Mint 16 and Ubuntu 13.10 x64 on a VM with Chrome x64, I have observed a significantly higher memory usage. AdBlock with my suscriptions was running at almost 180 MB.

 

Anybody got a problem with the last release, 0.8.4.3? The Chrome store removed the extension from view and I am served this error message:

"This item may not install properly on Chrome 33. Please check the package and the manifest and re-upload if necessary"

I did check that it loads properly in Chrome 33, using developer tools though of course since it can't be in the store before I publish it. I re-submitted after adding a "short_name" in the manifest file, and removing some shell scripts in "assets/" which I use to update the assets (it's part of the project on Github, so I just zip all together) but which are not needed to run the extension.

I don't know, I added many new extra ABP lists (Germany, Italy, China, etc.), maybe there is something in there which trips something on Google side. I wonder if it could be the overall size of the extension, I've been thinking about removing the 14 MB hosts.txt, I regret having put it there in the first place.

EDIT: Looks like there is something going on at the Chrome store: http://stackoverflow.com/questions/...ge-is-invalid-details-could-not-uzip-extensi#. I hope this won't screw up users' installation where they would loose all their settings.

EDIT2: Issue is resolved. It was one of the new ABP filters file I added, it had a character in it which is a reserved character on Windows. I wish the Chrome store was able to se the problem at submission time, rather than install time.

 

Wow in leaps and bounds you're up to 0.8.4.7 already great stuff as usual Raymond, thanks!

 

Now I realize, the extra footprint is because I am developing using a 64-bit version: "Google Chrome does not use 64-bit version on Windows". That is actually funny, because I dedicated an inordinate amount of time figuring ways to reduce mem footprint because I always considered it was too high, only to find out it's just an expected outcome of running the 64-bit version. This extra work wasn't wasted I suppose, I guess HTTPSB can claim bragging rights of being the leanest blocker out there.