HTTP Switchboard for Chrome/Chromium:

Well NoScript doesn't disallow cookies/css/etc. in the first place. But anyway, a single click is also what it takes with HTTPSB: click on the domain name of the page and all types of request which are not blacklisted will be allowed for that domain: cookies, script, etc.

 

Well, this might be a stupid question, but let's take Wilders for instance. If I look at the matrix right now, I have "wildersecurity.com" and "www.wilderssecurity.com". Am I assuming correctly that if I choose "wilderssecurity", I am allowing for the entire domain and shouldn't have to touch "www.wilderssecurity" because of inheritance? So I could expect the site to work flawlessly unless there were 3rd parties involved that served up content on the page also required for the website?

Also, when you say whitelist all for the sake of simplicity, do you meaning choosing the option in the settings labeled "Auto whitelist page domain"?

 

Yes, anything whitelisted in wilderssecurity.com is also whitelisted in www.wilderssecurity.com

 

Okay, thank you. So basically I'm just doing what I always have with NoScript, trial and error, with just a prettier UI. On a site such as Wilders it will be straightforward and dead simple, on sites such as TMZ and Gawker-owned, things will get complicated. I'm still trying to figure out the toolbar at the top left and wondering if the padlock to its right is actually locking settings down.

 

No, don't auto whitelist if you can avoid it, there is a bug anyway going on with this one. With whitelist all I meant literally, click to whitelist the "all" cell if you want to work in reverse mode (whitelist all/block exceptionally).

You got it right, whitelist domain "wilderssecurity.com" and all subdomains will be automatically whitelisted, and also all types except those blacklisted (which you can change to your taste of course).

wildersecurity.com is one of those very rare place on internet which do not rely on any third party whatsoever, but you get it, if it did, you would need to allow them separately if ever you found that they are necessary.

From the comment in the chrome store, I get that people had to practice a bit, but after getting used to it, it looks like they liked it a lot. I believe it's because there is a clean logic to the matrix, and once you see it, all become easy.

 

I think I am getting it finally. While this whitelist all isn't so sound of a security practice, it is helping cut down on the decision making when it comes to what I should be allowing..this extension must have a good AI. Now, if I recall, you stated that if an entry was deep red it was blacklisted by you. What happens again if we need to allow scripts for such an entry? I have an example: ads.foxnews.com. Several images related to articles were not showing up until I allowed 3 scripts in that cell..which promptly turned to 5, but whatever I guess. The hostname sounds like an ad server, but it loaded only relevant images. So, my question is am I protected from whatever bad stuff this blacklisted cell has by allowing the scripts cell? It is these hostnames that are the most confusing. I get a bit nervous allowing purposely blacklisted hostnames to do anything.

 

Had to create too many global rules for filtering behind the scenes requests. Once there's a scope just for that I'll use it again. Seems like it'll be a very neat feature.

 

I've gone back to NoScript, ABP and Disconnect on the family systems for now. I got them semi-comfortable using it before, and if I'm going to experiment with Switchboard, I want to do it on my own without dealing with the hassles they encounter as well. I'm not sure what you mean by behind the scenes.

 

Dark red means there is a blacklist rule directly associated with the entry (not inherited). It could be from the preset lists or it could be from the user.

Whenever you allow requests to go through, no, you won't be protected from whatever bad stuff you receive as a response from these requests from anywhere. "php.net" got hacked last fall, and what I would have considered a trustable site was serving malware to visitors.

It's true for any request, whether it comes from an untrusted or trusted source. It comes down to your definition of "bad stuff" and your own assessment of the likelihood you receive this bad stuff as a response.

Whether you choose to whitelist "script @ ads.foxnews.com" in order to make the site works depends entirely on your tolerance to ad-pushing scripts (which I have no idea what it does aside making images appear). I can't decide for you. There are various reasons for an entry to appear in one of these blacklists: ads, malware, nuisance, tracker, etc.

Given the name I would speculate "ads.foxnews.com" got put on these lists because it serves ads. But I can't make any affirmation that whatever a site serve is not bad stuff, only a thorough investigation would allow that kind of conclusion, and it would apply to only a specific point in time. You will have to decide for yourself. I like that you went with allowing only the scripts for "ads.foxnews.com", this way you prevent potential bad stuff from the "cookie ads.foxnews.com", "XHR ads.foxnews.com", etc.

But if it's what is required for you to make a site work the way you want it to work, than you don't have much choice. If the site worked with NoScript/Disconnect/etc., it's just because the requests you allowed with HTTPSB were allowed with the other extensions, so no need to be more nervous with allowing the same requests with HTTPSB.

 

In regards to ads.foxnews.com, all that it wanted were scripts. So I don't really know what all it loaded besides the images. Truthfully I don't even remember what XHR is, but I'd probably leave that stuff alone knowing me. One complaint I have with domain whitelisting is that when you allow that, instead of just the domain stuff I was getting a LOT of Facebook/Facebook Connect being greened along with other unwanted stuff. That really sucked, but I can't blame you for not blacklisting it. As we discussed earlier on, user preference has a part in it.

 

Are you saying that if you whitelist, say, the nytimes.com domain, facebook.net is also whitelisted? That's impossible unless you've whitelisted facebook with the global scope before.

EDIT: Since you seem to prefer Noscript - please note that you would run into the same problem if you allow facebook in Noscript as it is much less flexible than HTTPSB. If you allow facebook in Noscript it's also allowed on all other websites as there are no domain or site specific scopes in Noscript. The only way to finetune permissions in Noscript is by adding specific rules in ABE which is very uncomfortable.

 

I agree. HTTP Switchboard is for me NoScript + RequestPolicy

 

facebook.com is not blacklisted out of the box, but it is not whitelisted either. So for it to be whitelisted, it means the user did it expressly. Maybe you mean some images from facebook.com where greened?

I personally blacklist anything having facebook whenever I encounter it (only two clicks required if counting the padlock = gone forever), but given the sheer number of people using facebook.com, this means a lot of people would not be pleased with the extension's choices.

By the way, reading the above again, I just want to be sure there is no misunderstanding: when there is no number displayed in a cell, this means there was zero request from that particular cell. So even though sometimes it's green a lot, that doesn't means there were requests.

 

But in practice, if I'm not mistaken, because of the way that most of the attacks work, using whitelisting for scripts does protect against compromised legitimate sites. It's very rare that the attackers host the payload or the exploit kit in the 'clean' hacked site.

Instead, they try to redirect you to a page controlled by them where they host the exploit. As that page will never be witelisted it will not be able to execute scripts or plugins. Please, correct me if I'm wrong.

 

Is there a mistake here: "using whitelisting for scripts does protect against compromised legitimate sites"? EDIT: Ok I think I get it, you are saying "having to whitelist scripts".

In the case of php.net, the malware was served in an <iframe>, so whatever addon blocks <iframe> woould have protected the users. The FBI malware on TOR was also using an <iframe>. NoScript would have protected users who enabled "disabled embedded iframe". HTTPSB blocks iframe out of the box.

Then after the <iframe> comes other steps: java plugin or whatever else is an exploit.

Yesterday, a user reported how his ISP is inserting tracking code in every page he pulls from the web. Now this is more difficult, apparently the injected HTML by the ISP contains inline script tags. Which means most users would be infected by that injected code because we all allow at least scripts originating from a web page we trust. This one is bad and unless you block script all the time from everywhere, one would have been infected (I call this infected because it's malware in my opinion -- it's is not less malware because it comes from the ISP).

Anecdote: The php.net news is what motivated me to introduce strict blocking, before this, clicking a hostname cell resulted in all types for that hostname to be whitelisted even when a type itself was blacklisted.

 

If a normally blacklisted or dubious site is required, why not just use the Scope selector from the toolbar and change it to a narrower domain-level or site-level scope? This way the blacklisted/dubious site is allowed only for that narrower selected domain or site. It's not an ideal situation having to allow something that's normally blocked globally, but if the user really needs to view the site properly, then at least this is an option to do so.

 

Actually, the larger reason I use this extension is for frame control. Everything else is just extra for me, which is great.

@Wat,

That's what I do for Facebook. I don't want Facebook loading anywhere else, so I create a scope where it can only load on https://facebook.com

 

Thanks for confirming, HM.

I came across hxxp://www.colts.com/ that absolutely requires Google Analytics and quantserve in order to view the videos. Well, in this case I refuse to allow that - I'll bend some, but not that much - so I just avoid it all together

 

A good proposal, IMHO

 

I'm aware of the limitations of NoScript, yes. That is why I was keen to work with Switchboard. However, I'm afraid as impossible as it seems, that Facebook issue was actually what was happening. By clicking the "All" button, the domain, subdomains and various 3rd parties including Facebook were greened. I had never and try never to allow Facebook in any way unless forced, and didn't globally allow it beforehand. So I am not sure what was going on. I do recall though that images were indeed listed as green for Facebook, as was at least one script at that time.

 

"By clicking the 'All' button". (you didn't mention that in your previous post).

"All" means all, except for the blacklisted items. So if facebook wasn't expressly blacklisted, it will obviously be considered as being part of "All", hence it would become whitelisted.

The extension can't read the user's mind, so if a user click whitelist "All", the extension will indeed allow all. You just have to click on "facebook.com" to blacklist the whole "facebook.com" domain, then click the padlock to make this permanent.

 

There, try this:

http%3A%2F%2F*.foxnews.com%0A%09whitelis
t%0A%09%09*%20players.edgesuite.net%0A%0
9%09*%20global.fncstatic.com%0A%09%09*%2
0foxnewsplayer-a.akamaihd.net%0A%09%09su
b_frame%20video.foxnews.com%0A%09%09*%20
foxnews.com%0A%09%09image%20*%0A%09%09st
ylesheet%20*%0A%09blacklist%0A%09%09cook
ie%20*%0A%09%09sub_frame%20*%0A%09%09*%2
0*%0A%09graylist%0A%09%09*%20ads.foxnews
.com%0A​

I could make the video player works. Tell me if all is allright, I didn't allow cookies, but overall I use a domain scope to lean more on the permissive side rather than the restrictive side.

Edit: I added a few more rules for domains which name suggested they are owned by fox news:

http%3A%2F%2F*.foxnews.com%0A%09whitelis
t%0A%09%09*%20foxnews.demdex.net%0A%09%0
9*%20foxnews-f.akamaihd.net%0A%09%09*%20
players.edgesuite.net%0A%09%09*%20global
.fncstatic.com%0A%09%09*%20foxnewsplayer
-a.akamaihd.net%0A%09%09sub_frame%20vide
o.foxnews.com%0A%09%09*%20foxnews.com%0A
%09%09image%20*%0A%09%09stylesheet%20*%0
A%09blacklist%0A%09%09cookie%20*%0A%09%0
9sub_frame%20*%0A%09%09*%20*%0A%09grayli
st%0A%09%09*%20ads.foxnews.com%0A​

Edit: And here, to blacklist many facebook-related stuff:

*%0A%09blacklist%0A%09%09*%20facebook.co
m%0A%09%09*%20facebook.net%0A%09%09*%20f
bcdn.net%0A%09%09*%20fbstatic-a.akamaihd
.net%0A​

As usual, when you decode/import the above in the Rule manager, click Commit all to make these rules permanent.

 

Ugh...yeah, didn't quite think that one through before I opened my mouth. Some days Gorhill my brain just doesn't fire up quite right. I'd like to add a link I think may be helpful to those who might look at the toolbar and go "huh?". http://www.insanitybit.com/2013/12/23/httpswitchboard-security-privacy-extension-chrome/ HM lays out the options and clearly explains which option applies global, domain or site rules. Figuring out the toolbar at first was the hardest part, and my family was randomly clicking up there and applying rules all over the place.

 

Yep, that looks pretty much spot on to what it looks like when all is allowed there. Thanks for that.

 

Anyone able to get a working ruleset for cwtv.com? I absolutely can not manage to get things to play without just disabling the extension.