HTTP Switchboard for Chrome/Chromium:

Feature Request:
Show the chromium behind the scene in the current tab. (without needing to go to the settings page).
You could show it as chromium-behind-the-scene://facebook.com (for example facebook).

 

What is ´Chromium behind the scene´ and does that apply also to Chrome?

 

Yes, it also applies to Chrome.
More information here https://github.com/gorhill/httpswitchboard/wiki/Behind-the-scene-requests

 

I don't know if this has been discussed before, but I had a thought.

I like the idea of whitelisting on a per site basis, so that you can allow facebook only on its own website and nowhere else. Yet there are some things I want to be available everywhere, hence I whitelist them globally (YouTube, Vimeo). When whitelisting on a per-site basis comes into play, the globally whitelisted items are blacklisted again. This is especially painful when I am dealing with YouTube videos on websites which are served through a pop up windows.

For this reason at the moment I am just whitelisting globally, I only have a site-level scope for the stuff I really don't want anywhere else than there.

Thus I am thinking if there could be a way for globally whitelisted items to be automatically recognized by websites for which I have a per site permission set up. What do you guys think about that?

 

There is an issue entered for this feature: https://github.com/gorhill/httpswitchboard/issues/115. This would go on the Unitquitous rules tab, there will be a text area dedicated for ubiquitous whitelist, just like there is one now for blacklist. This requires change at the core of the engine though, not sure when I will address this one.

 

I am now using HTTPSB together with AdGuard (chrome extension, English Filter and Social Filter only). From what I've read, AdGuard extension only hides ads as opposed to their main AdGuard (their flagship product). This makes it the perfect add-on for HTTSB, social filter hides all the social button that is not blocked or hidden by HTTPSB and English Filter hides the ads HTTPSB can't. I'll keep this until gorhill decides to add DOM processing (if only he adds that function )

 

And why do you think then that Adguard is better than Adblock?

 

I only need to hide ads not block them as HTTPSB will do the blocking.

 

Well, Adblock also hides ads which can't be blocked. And it blocks ads which are not blocked by HTTPSB as long as it doesn't support all types of complex Adblock filters yet. gorhill is working on that, though.

 

Yeah, I would personally favor AdBlock+ over AdGuard. I didn't investigate deeply, but by the look of it, AdGuard uses a key which might be used to identify uniquely a user when it requests its own server at adguard.org.

 

I planned on using AdBlock+ first but can't find an "Element Hiding" only filters.

 

Nevermind! I extracted all of Element Hiding rules in Easy List using grep and now I am using Adblock+ with Element Hiding Rules only. Removed AdGuard!

 

gorhill, is there a way you could distinguish manual image saves (i.e. "Save image as") without always needing to unblock the other tab?

 

At the point where HTTPSB blocks requests, there is no way to know whether a request was made as a result of "Save As..." (which is a browser function, extensions are not told about it).

I could possibly implement a heuristic where requests for what appears to be images (end with ".gif", ".png", etc.) of type "other" with no parent frame are deemed coming from a "Save As..." operation, but I don't like this approach because this is a guess, meaning it could be wrong in some unforeseen scenario.

I resist as much as possible that kind of hard-coded exceptions, because one of the extension's first responsibility is to not surprise the user about what request it lets through -- currently everything that is allowed is reflected in the matrix, except for requests to "https://raw2.github.com/gorhill/httpswitchboard/master" for when a user expressly click the update 3rd-party assets button.

Let's just say I am open to change my mind if this becomes a irritant for many users.

 

Hi Raymond,

I've encountered an issue with rules backup/restore. I can Export rules, encode recipe, Backup to file. However, if I do the reverse: Restore from file, Decode recipe, the recipe decodes in the left-hand pane, but the background turns pink, and I can't Import them. I discovered this when I tried to Restore the ruleset from Chrome in one pc to chrome in another pc. In fact I tried the following as well:

Export rules, background is normal, I then right-click in pane and choose Select all, Ctrl+X, Ctrl+V; the cut and paste procedure results in the same pink background and I can't do anything with them.

 

Gorhill, I noticed something strange. The same host is showing up in all my tabs. I wonder if this is extension related, here is a couple of screenshots:




Edit: It was from this Buffer extension, ugh frames ;(

 

I tried and couldn't reproduce. Unless there are privacy concerns, if you could give me the text here which causes the red background I will be able to see what causes the problem.

 

Hmm I guess this is a typical example demonstrating how ubiquitous whitelist rules are going to be useful.

 

I tried a slightly older ruleset backup and it works fine. I guess it must be a syntax issue that only rears itself when trying to Restore from file.

 

I still would like to know where the problem is, it is pretty serious if a user can't restore its rules because maybe some unforeseen case in the code.

 

I have no idea what causes the red background. However, the older ruleset that works isn't that much different than the slightly newer ruleset that causes the red background, and there are some privacy concerns so I'd rather not post here. I'm quite content with reverting to the older ruleset.

 

The syntax is very strict. Just an extra space can result in the content being marked as bad. This was done this way in order to avoid over-complicating the parser.

One way you could find out if you are curious about where is the problem, is to use a diff tool, given you say the older list is not that different than the other. This would help highlight where is the problem in the text.

 

A question about HTTPSB updates. I run Chrome in a Sandboxie box and with AppGuard locked down almost all the time.

Before I start the browsing session with those protections I run Chrome normally and use 'About Google Chrome' option to check if browser updates are available. Mine is 33.0.1750.54 m.

HTTPSB extension always stays at 0.8.4.8. What way to update it, since it seems there are newer versions available and that About check does not seem to update it?

 

You are right that About Google Chrome does not check for extension updates, but you can do it manually.

1. Run Chrome outside the Sandbox
2. Open chrome://extensions/
3. Enable Developer mode (top right)
4. A button Update extensions now should appear, click on it

That's what I would do if I had no direct access settings. Note, if direct access to the entire profile folder is set, extensions can be updated inside the sandbox. Of course there are other ways as well, like more fine grained direct access settings and so on.

 

Typical, right after I posted the above post, HTTP SB somehow updated. I might have made 'chromium-behind-the-scene' back to allow all. Updated in a sandboxied instance only. Will have to surf more unsandboxied and perhaps also to try your suggestion.

To me it is nice actually that SBIE prevents extension to update on the real install. And if I had AppGuard in locked down mode as I believe, then it does not prevent it, just as you told in AG thread. I would not make profile folder allowed for direct access in SBIE, not with my cracker kids around after my computer or just browser settings.