HTTP Switchboard for Chrome/Chromium:

In an effort to get a bit more control...

(note ,you may want to remove the google translate thing. It's just personally useful for me.)

The goal here is to remove the *full* allow rules of CSS/images. Instead, I've redlisted *Everything* but CSS/images, which are implicitly greylisted.

I then checked:

Now when I visit a page images/CSS are loaded only from the TLD. This will get pages to work 99% of the time in my experience while blocking any trackers that rely on either contents, or malware that attempts to exploit the browser/OS with those objects.

There is a slight usability hit on more complicated sites, such as Facebook and other massive sites. Some sites also load 3rd party CSS from something like cloudfront. But the majority should work with no trouble.

I figured some users would enjoy this.

tl;dr: you go from CSS/images allowed for everything to CSS/images allowed for only the first party domain.

Enjoy.

Note: The one caveat is that on sites you have visited the newly universal redlisted items (plugin, other, etc) won't change, but the 'auto whitelist' will. Ideally that autowhitelist would only apply to *new* sites. I may fill a bug out for this.

 

This happens because scopes were auto-created, and the rules from global scopes are imported (as a convenience) only at creation time -- rules from global scope are never copied to all narrower scopes after they are created. So a solution is to remove all temporary rules after the changes, which would cause all auto-created scopes to be removed, unless they were explicitly locked down.

Re. "CSS/images allowed for everything", just so there are no misunderstanding to other readers, it's not exactly "for everything", it's more accurately "for everything except ubiquitously blacklisted hostnames" -- which numbers near 60,000 out of the box in current version [edit: not counting optional ABP filtering].

 

What I meant is that the auto-whitelist applies to sites that have already had their scopes created. For example, I've created my ruleset for wilders already. So I would expect the autowhitelist feature to not apply to it.

edit: In fact, even if you explicitly 'unwhitelist' the site, once you reload it is whitelisted again. Not really ideal behavior.

And, yes, the blacklist certainly would still apply either way. For many users I'm sure that's nice, and it certainly is convenient for me as well, but I don't consider blacklisting a security measure. It's something to keep ads away.

 

http://www.incapsula.com/blog/world-largest-site-xss-ddos-zombies.html

And that's why I'm careful about whitelisting even images.

HTTPSB stops this in multiple places, the image, frame, and script. The only issue is that a website that plays videos will most likely need frames and scripts. The attack, however, needs those as well as images and probably XHR to the attack domain.

This is one of those attacks that shows the usefulness of a fine grained website profile.

 

My own conclusions after reading the article.

In this particular case, blocking images wouldn't prevent the javascript payload to be loaded with the page, as the js payload is an attribute in the `img` tag (I am shocked that a "top 50" website would allow that sort of thing to happen), and it appears the image file itself, which would be blocked in your case, was inconsequential: it was really the js payload which was noxious. [Edit: correction, you are right, blocking the image helped in this particular case, as the initial js payload was executed only through the "onload" event handler -- if indeed "onload" is not called when there is a failure to load the image.).

If a user had js enabled for that site (let's say likely for a top 50 website), the `iframe` created by that js to load the real js payload was quite certainly blocked by HTTPSB (in its default block-all/allow-exceptionally mode) as I doubt a user would have whitelisted an obscure domain name (nicknamed "c&cdomain.com" in the article) used as the `iframe` content for command&control purpose.

 

Yes, from my understanding of the vulnerability the image is required. The onload is going to require the image to, well, load.

 

A few questions gorhill from this quite noob in this stuff. Am I right that NoScript has no power in blocking cookies?

These questions came to me from watching your firefox extension cookie thread. I have had always Firefox in the setting that it 'Never remember history'. Well at least lately. The wilderssecurity changed the hosting site and I noticed that the optional Fluid style that i need to read this forum now was available also for Firefox without allowing any for wilderssecurity in NoScript.

If I go to Firefox and 'Use custom setting for history', there I can block cookies, but it is a global setting. What cookies will Firefox block with that 'Never remember history setting'?

 

Noob question: How can i delete a single site -level scope under the 'scoped rules' tab? I can mark it for deletion but what do I have to do next? Thanks!

 

No clue. I did try to select "Never remember history", upon which Firefox restarts, and upon which the setting is always back to "Use custom settings for history". I have no clue how this is supposed to work, but on my side I can't make the "Never remember history" option sticks.

 

"Commit all" button at the top will effectively delete all scopes/rules marked for deletion -- and persist all temporary scopes/rules.

 

Thank You!

 

Exactly, I think you need to allow all cookies to make that option stick. I might check it later though. So you and me are at the same blind of what 'Never remember history' means. One of the things I am using your HTTP SB instead FF at the moment.

 

Need Help Please. Have latest HTTPSB running on 3 computers running both chrome/chromium with no problems. However on 4th system i am unable to get any changes to the settings page to stick. I have removed chromium (and user data) several times. Each time I re install the same thing - unable to get HTTPSB settings to stick. Other extensions are able to save settings with no problems. So any ideas what might be borked and how to fix? Thanks

 

HTTPSB uses chrome.storage.local API to save settings. So it's failing there, if indeed by "settings" you mean what is in the Settings tab, the Scoped rules tab, or the selected ubiquitous lists in the Ubiquitous rules tab. First thing I would do if I had access to your computer is to look at the extension console. I don't know how familiar you are with chromium's development tools... In Chromium's Extensions page, there is a checkbox for Developer mode, which once enabled, allow to access the console for any extension, by clicking its "Inspect view: background.html" link. If something is failing, it's likely reported at the console.

By the way, I would like to know the version number. Also, did you import the settings through the "Restore from file..." feature?

 

I would check also if there is some sandboxing done on that 4th computer. Sandboxie for instance can be set use 'forced programs' option for say a browser and then from a normal desktop icon starts a sandboxed browsing instance.

 

More info. all version of HTTPSB from 0855 thru 0863 are affected. it appears to be a problem with this chromium install. something may be sandboxing it as jarmo suggested. i tried shutting off my security software (mbam & avast) but no success there either. will try another reinstall of chromium and HTTPSB with a clean profile. EDIT: just did a clean install of chromium & HTTPSB. "Enable strict blocking" & "Clear browser cache every 60 minutes." were already checked. But i am still not able to adjust any other settings on the page. on the ubiqitous rules page i am able to change assests if i use BOTH the parse checkbox and the apply changes button.

 

It's the difficulty of debugging remotely, I am not sure I exactly understand what you are describing. From what I understand, changing settings work on the Ubiquitous rules page (above description is the excepted way to change settings on that page), but not on the Settings page. If so, then my first move would be to look at the dev console for tab in which the Settings page is loaded. It is as if a js error is occurring on the page which prevent the proper chrome.runtime.sendMessage to be sent to the extension to notify of setting changes.

 

gorhill,

is there any way to have httpsb properly handle ip address ranges? For example, I'm seeing Netflix requires plugin whitelist for numerous ip addresses, many of which are in, for example, the 108.175.x.x range. It allows me to create a rule 108.175.0.0-108.175.255.255, and I can successfully import and commit it, but I'm still having to whitelist individual ip addresses in this network range.

 

No, HTTPSB doesn't support ranges (or regexes). The hostname is really a key in a lookup table, which is actually key for good performance.

How many IP addresses did you have to whitelist so far? There are 65,536 IP addresses for the range you show above, so that is quite impractical to whitelist all of them. I am wondering if there are specific sub-ranges depending on your geolocation. Anyways, trying to figure what would be a good solution to this without rewriting HTTPSB's core toward a less performant model.

Using finer-grain ABP filters could work, i.e. something like `||178.175.*.*/`, but HTTPSB doesn't currently support whitelist filters (I consider adding support for these since I cleared my misunderstanding that they were strictly for acceptable-ads purpose), but then, that would mean these ABP whitelist filters have precedence over HTTPSB's blacklisted hostnames -- something which I am not sure is a good idea.

So in short, range are not supported, and I am undecided at this time as to how to best solve the specific issue you raise.

 

I had been out of town for 2 weeks and am now confronted - as expected - with several new HTTPSB versions with great improvements. Thanks again, Raymond, for your excellent work! The stability and reliability of HTTPSB is really very good - it's definitely a very mature extension. And from my perspective there not many features missing.

Nevertheless, let me present my personal list of desirable features if you don't mind:

1. Complete support of ABP complex rules. But you're working on this anyhow so I guess we will have it before long. (Support of element hiding rules would be nice as it would make many sites look cleaner but I know that it requires to modify the DOM ...)
2. Once ABP rules support is complete (and we can get rid of Adblock) a rule editor will be important, IMO. We had discussed this before. You said that you tend to write a separate extension for that so that HTTPSB doesn't become too bloated. Well, I think if the rule editor is moved to a separate tab (which preferably only opens once the rule editor is executed) the extension would not become too bloated for HTTPSB newbies while more experienced users would probably be happy to have it all in one place - provided that memory footprint would not significantly increase.
3. The statistics page is very helpful, particularly that we can see which ABP rule is applied if we hover the mouse cursor over that special icon. However, it would be great to have that feature also in the matrix: If we hover the cursor over a cell HTTPSB should show what exactly is blocked (or allowed if that cell is already whitelisted). Thus, it would be much easier to decide if a specific cell should be whitelisted or not. I'm convinced that this would significantly improve the usability of HTTPSB.
4. Right now, HTTPSB can either block cookies or allow them. Unfortunately, many sites require that cookies (partly as session cookies, partly as normal cookies) are temporarily allowed in order to work properly. This case is not supported. If cookies are blocked those sites would not work, if cookies are allowed those sites could track you. My suggestion (made before elsewhere): Adding an option (in combination with a timer) like "Allow cookies and delete them x minutes after last time they have been used unless explicitly and permanently allowed in the matrix for specific sites." If the user choses that option, the cookie column should turn, say, yellow. Privacy impacts are minimal (particularly since cookies would be blocked for the domains in the integrated hosts files anyhow), and the user could still whitelist a cookie cell for a specific site if permanent cookies are required to store login credentials (or explicitly blacklist those cells for other sites). This would make extensions like Vanilla superfluous.

Just my 2 ... wait: 4 cents Perhaps some of those features are not feasible or too difficult to implement - I don't know. It's your baby after all

 

Okay, thanks!

So far under my Netflix Domain-level scope, there are 17 ip addresses whitelisted. Sometimes when I play a video, there are a couple more that need whitelisting.

No worries. I think things are still quite manageable, although perhaps something like CIDR could be used? Example: 178.175.38.0/24

 

@wat0114

For Netflix I simply allow XHR universally on that domain and then I disable it on a per-subdomain basis. While this is not *as* nice for security as a whitelist that is specific to their domains, it works, and an attacker hasn't gained a whole lot.

 

Duh! Silly me, I didn't even actually thought about that solution -- which is acceptable because of the ability to scope.

 

Thanks HM, but how do I get that to work in the situation shown in the screen capture where it's for a plugin?

 

Allow the whole `plugin` column? It looks like you don't need the `XHR` column, rather the `plugin` one. Now if on top of this you set Chrome in "Click to play" mode for plugin, than it's even better.

Edit: if ever this works, I will create a preset for Netflix (I don't have an account, I can't test what rules work).