HTTP Switchboard for Chrome/Chromium:

Of course! I was so fixated on something more granular, but this is fine, especially if the "click to play" for plugins is used. Thanks!

 

Interesting, on my system it's XHR, I suppose due to it being ChromeOS.

Regardless, with scope there's little issue.

 

I found a new use for HTTP-SB. I allowed access to my microphone in Google Chrome. I allowed access to everything(cookies, frames, plugins, other, etc)
and Google still could not access my microphone.

Its nice to know that HTTP-SB has my back and I'm not being exploited. Linux does the rest for me

4:54:15 PM other<a>https://www.google.com/speech-api/f...r=2&maxAlternatives=4&client=chromium&interim
4:54:15 PM other<a>https://www.google.com/speech-api/f...EU21OpBXqWBgw&pair=25DD07023642FC9D&output=pb

 

It's also great as a video grabber

 

And maybe I'm missing something, but small bug:

On "ubiquitous rules", unclicking a prefab rule/asset makes no difference until "Parse and enforce Adblock..." is toggled. Only then can you "apply changes".

 

Looks like a bug. I just tried it on Chromium 33 and I did not see that behavior. What browser/version are you using? What specific preset list did you click? I will try to test as close as possible as the way you see the bug.

 

It has your back for all net requests routed through the webRequest API, but can't do anything for net requests bypassing webRequest API.

 

I tried them all. No preset checkbox, neither adding or removing, activates the apply changes button except "Parse and enforce Adblock+ complex filters (beta)."

Chromium: Version 36.0.1942.0 (263789)

Chrome Dev: Version 36.0.1933.0 (262849)

Just tried Chrome Version 32.0.1700.76 and it works fine on that.

 

i gave it another try this morning but when i go to some sites i get a big red facebook place-holder that blocks contents for about a minute, then disappear.

so i uninstalled it.
please let us know if you ever find a way to fix this.

 

Currently, Chromium 34 is still in beta, so Chromium 36 is probably considered even less reliable. I wish I could install one of these development version so that I can test preemptively the extension, but I am afraid to create a mess on my computer with too many different versions all playing in the same config folder.

 

Ok I did check with allow-all/block-exceptionally mode (enabled using steps described there), and the annoying overlapping iframes occur only if I enable "Parse and enforce Adblock complex filters". I see that Fanboy's lists, selected by default, contain filters to block Facebook, which ultimately causes the annoying blocked frames even if frames are whitelisted in the matrix

So for the time being, I am removing Fanboy's lists from the default selection of lists. If someone doesn't want to ping Facebook, it's easily and better done through the matrix, or even better, using custom ubiquitous rules to block Facebook from whatever scopes.

These change will be in for the next release. I will post here when it is available. In any case, Ghostery and HTTPSB are two different extensions -- though they overlap, so I can see why someone will still prefer Ghostery even as I try to make HTTPSB more friendly.

For the benefit of other readers who wish to understand the issue, here are screenshots of what happens on some sites when one block Facebook iframe but allow Facebook scripts:



Top is allow FB scripts/block FB frames, bottom is allow FB scripts/allow FB frames (with block FB scripts/block FB frames, the issue disappear as the FB button won't even try to render).

Of course, the root problem is that of an iframe which is by default ridiculously too large which purpose is to receive the small FB button.

 

tnx a lot for your work Ray!
i'll give it another try when it comes out.

 

After seeing httpsb was blocking over-aggressively on several sites, I found it helped a lot to disable a few of the blocked hosts checkboxes. This does sacrifice some blacklisted host blocking but, unfortunately, I'm finding too many sites require some of them to work properly. At least it does mean I'm spending far less time fine-tuning httpsb to get a site to work right.

 

My HTTP SB updated to 0.8.7.1 and must say this button for disabling /enabling matrix filtering for current scope is really handy when wanting to see some hard to whitelist videos for instance. It is used together with 'Auto create temporary site-level scope option' in my computer.

My questions are:
What happens to scripts etc stuff allowed site level after the matrix filtering is put back on? Are they deleted? If not, are those scripts and stuff allowed in other site level scopes? If they are, will Chrome -> History -> clearing all possible there, clear those allowances?

 

When the permission for scripts toggle from allowed to blocked, the page should reload automatically, which will cause javascript execution to be disabled, even if the script files are in the cache. If you really want the bloat to be cleaned up, there is the "Clear browser cache every x minutes" options which is also useful for this purpose, even though the primary purpose is to enhance privacy.

 

Thanks a lot for the new version with great improvements again! Just one question: The changelog says:

However, as far as I can see there is no such switch but rather a switch to disable matrix filtering. Or am I misunderstanding something?

 

You're right, the there is no switch to disable specifically only the ubiquitous rules. I should have changed the title to reflect the change in my approach to solve the problem of users sometimes wanting to bypass completely matrix filtering.

When I entered the bug I was really intending to add yet another button at the top of the matrix to specifically disable ubiquitous filtering. Then I went on to implement this, I actually had a prototype, etc. This is when I could see all the ugly side-effects popping up. This just wasn't working, and I couldn't see a sane way to address these side-effects without resulting in a lot of complicated code. Keeping the engine code sane and as straightforward as possible is at the top of my list.

I had to figure a new approach, and this is what I came up with. Eventually this struck me as being quite logical, given that the ABP filtering can also be disengaged similarly. And this address the real issue of a user wanting to disengage all matrix filtering, while mitigating doing such a drastic operation by limiting it to the current scope.

 

Thanks for clarifying. At first I would have preferred the original approach but after a second consideration I think your decision is more logical as ubiquitous rules can be whitelisted in the matrix for a specific scope anyhow if necessary (although this can be tedious at times ).

 

Thanks for this excellent new release, Raymond

 

Raymond, I've a question regarding the chromium-behind-the-scene scope. So far whenever I've opened the statistics tab in HTTPSB and clicked the HTTPSB symbol, the chromium-behind-the-scene scope opened where I've been able to whitelist/blacklist any cell to my liking. Now I've installed Arch Linux in a Virtualbox VM and installed Chrome with HTTPSB. It's behaviour is different now: If I open the statistics tab and click the HTTPSB symbol, the chromium-behind-the-scene scope opens where everything is whitelisted and it's impossible to blacklist any cell. Only if I change the scope to *.chromium-behind-the-scene (i.e. the domain-level scope) I'm able to edit the permissions as before. Is this the expected behaviour for new installs? If it is, I've probably misunderstood the changelog of v. 0.8.7.0.

 

You need to switch on matrix-filtering. As said in the change log, for new installs, matrix filtering for chromium-behind-the-scene scope is off, as I consider playing with that scope something more suitable for advanced users.

To explain the rationale of that decision, there was a case where an entry in the preset blocked hosts was interfering with the use of another extension, and I really do not want other people, users or authors, to suffer from my extension. Now if a user does turn on matrix filtering for the chromium-behind-the-scene scope, then I consider it is an implied acceptance they understand the potential consequences.

Edit: Actually, being able to select `*.chromium-behind-the-scene` should be considered a bug, as this makes no sense.

Edit: Now I am second guessing myself about the appearance of the matrix- ABP-filtering switches when off... These switches are rather important, and if in their off states, they should stand out more, thus reddish might be a better choice than dimmed..

 

Yes, of course, I had missed that somehow. Sorry

That's what I thought, too

Agreed, that would be more noticeable.

 

Strange, this user-agent in the spoof list seems to break Startpage:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0

When you search on a results page you just get redirected back the the front page.

 

Do you use Chromium or Chrome?

 

What do you mean by "search on a results page"? Do you means the "Search within results" at the bottom of the page?