HTTP Switchboard for Chrome/Chromium:

@Dave,

there are lots of things you can do, such as allow all like Gorhill suggests or allow everything except, for example, scripts and plugins column, or whatever it is you want. The extent of granularity the user wants is virtually unlimited. If I'm not mistaken, Twitter is not considered a blacklisted site, but it can easily be made one.

BTW, for the wlky.com domain, it like as a minimum you need what's in the screen capture, although you could do without disqus...

 

Thanks, Wat0114. Like I said, I am not faulting the program. It has a LOT of control to it and is actually quite good. But your screenshot shows why these script controls can be so crazy to deal with. The scripts named don't give any hint as to what they are for, and it seems silly to play the old game of MineSweeper on these things and hope they are not only right, but also not malicious.

 

Sorry, I misunderstood you. I thought you meant the blocking-by-default was annoying and you would rather have the opposite.

Re. Disconnect, the UI sure gives you the impression that it's all taken care for by the extension. But we need to look beyond the impression. Here are the results for the particular URL you provided:

What Disconnect didn't block:

ec2-54-237-31-193.compute-1.amazonaws.com
ortc-prd.realtime.co
media-cdn.fishwrapper.com
ajax.googleapis.com
cdn.taboolasyndication.com
ll-assets.tmz.com
ll-media.tmz.com
www.tmz.com
images.webspectator.com
scripts.webspectator.com
services.webspectator.com
www.webspectator.com
img1.zergnet.com
img2.zergnet.com
img3.zergnet.com
www.zergnet.com
dfdbz2tdq3k01.cloudfront.net​

What HTTPSB in whitelist-all-by-default mode didn't block:

ec2-54-237-86-7.compute-1.amazonaws.com
ortc-prd.realtime.co
media-cdn.fishwrapper.com
ajax.googleapis.com
cdnbakmi.kaltura.com
ll-assets.tmz.com
ll-media.tmz.com
www.tmz.com
images.webspectator.com
scripts.webspectator.com
services.webspectator.com
img1.zergnet.com
img3.zergnet.com
img4.zergnet.com
www.zergnet.com
dfdbz2tdq3k01.cloudfront.net​

17 hostnames were not blocked by Disconnect. 16 hostnames were not blocked by HTTPSB (taboolasyndication.com is also in one of the preset blacklists).

That Disconnect doesn't show the users all the crap in details on a web page doesn't mean the crap is not there, it just mean it's not shown. Hiding the crap is not helpful to the user. That was one of my main goal with HTTPSB, to let the user know exactly what is happening on the web page. In details. And to give the users the tools to act on what is happening.

Even if a user is ok with whatever Disconnect or HTTPSB does not block, with HTTPSB he/she still has the full ability to further block whatever if he/she ever choose to do so, while with Disconnect a user is stuck with whatever the company choose to put in its blacklist. And you have nowhere near the control you have with HTTPSB. I blacklist cookie from everywhere by default, something I wouldn't be able to do with Disconnect. HTTPSB gives you the ability to make an informed choice by not hiding the crap and the tools to act on the crap without restrictions.

It might look I am trying to "sell" HTTPSB over Disconnect, I just want to be sure the users know what they are getting exactly. Disconnect UI is certainly slicker, but when it comes to security and privacy, the users need to look beyond the surface. As shown above, Disconnect wouldn't do a better job than HTTPSB in whitelist-all mode.

 

I know where you're coming from; I gave up a few times on NoScript in the past because of the extensive maintenance and what not. I suppose the way I see it is that the bigger the rule set grows, the easier it gets to manage it, but admittedly it's a lot of work and certainly lot's of guessing as you've mentioned. Sometimes I wonder: "why the he77 am I doing this??!!" I guess it comes down to a commitment to forge ahead and build a ruleset that will eventually become more easily manageable, especially if one doesn't surf to too many different sites on a routine basis. Somehow after a while things become, believe it or not, more intuitive; you actually get a "feel" for what's necessary and what is not necessary. It might seem strange but that's what really happens. It basically comes down to striking a balance between convenience and security and accepting it and dealing with it until things become easier to manage, because in the end, you'll have yourself a more secure and efficient web surfing experience.

 

Oh I don't believe you're trying to sell over or put down any other option. You mentioned taboolasyndication.com as being in the blacklist. When I loaded TMZ the way you mentioned earlier, that entry looked allowed to me, as it was light green instead of the pinkish color or bright red. Am I wrong in thinking light green means allowed, even if temporarily?

 

Perhaps you're not playing IT department for several, very vocal, members of a household. I kid you not, at least six times since I made my earlier post I have had to walk back to one system or another because "this site is broken!". I love them all dearly, but good grief.

 

My mistake, I meant more exactly `cdn.taboolasyndication.com`, which is the hostname from where a script is requested (successfully with Disconnect). `taboola.com` itself is not blacklisted, thus it will inherit the global whitelist-all status, and thus appears light green.

Yes light green means "allowed", but through inheritance. Dark green means explicitly "allow", because there is a rule directly whitelisting the cell.

Granted what might makes the matrix more overwhelming is the fact that ancestor hostnames up to domain names are also listed for convenience, so that the user can blacklist the whole domain instead of just the subdomain from where the request really originated. Collapsing the whole matrix to domain names helps a lot in this case.

 

Well this is exactly my situation. So I say to use whitelist-all by default, keep frame blacklisted at least, collapse the whole matrix, and it has been working.

Whitelist-all is not good practice for security conscious people, but at least here there is some security still going on, and the extension helps them realized how much crap/bloat there is out there on internet, and it works because now I have the proof to support what I say re. bloat/crap. I wasn't able to make a convincing case with NoScript.

Eventually with baby steps, they might just start to block something permanently once in a while, and eventually basic good security habits will start to become a reflex.

 

Absolutely.

Since you mentioned Noscript: One important difference is that Noscript does not explicitly allow/forbid XMLHttpRequests. Many sites require them to load properly. The problem is that those requests mostly show up in HTTPSB after you allow javascript for that site, i.e. two reloads are necessary while in Noscript one reload is usually sufficient (you whitelist a site and you're done). That's possibly something that might annoy some HTTPSB users.

 

Well if you whitelist the hostname or domain (equivalent of what NoScript offers), you won't need two reloads. I rarely use the very specific type@hostname cells, I stick to use the hostname/domain, and I would advise most user to use HTTPSB this way for convenience, but of course in the end it is up to them.

If new users think that they must click the cells with a number in it as the way to properly use the extension, I really need to get to work on documentation to emphasize that the intended default approach was to click the hostname/domain cells -- although I have been sort of emphasizing this in whatever doc I have that with a single click one can enable/disable a whole group of requests.

 

I guess most users do.

 

Perhaps the issue is more general than that? A script that you've just allowed can not only perform an XMLHttpRequest to a hostname not seen before, but also cause other operations that involve something not listed before. For example, that just enabled script could embed an image element pulled from a new domain name, create the first instance of cookie manipulation, etc. The new behaviors might not even be seen at load time. They might be triggered only when the user explicitly interacts with the page in a certain way. Furthermore, this issue need not even involve scripts. The page could change at any time, causing for example images to be pulled from a domain not listed and reviewed before.

You could fingerprint sites based on the hosts/operations you see and through past vs present comparisons attempt to detect changes which require review. I'm not sure how well that would work out in practice though.

 

I'm routinely experimenting, making minor adjustments in an attempt to strike a decent balance between security and convenience. What I have now on the top row request types is:

CSS, img, XHR, other = Whitelisted (dark green/padlocked)

cookie, plugin, script, frame = pale red greylisted

This way when I whitelist a hostname cell on the left, it will whitelist the row of all the request types for the hostname cell. I can then, if I feel the need to do so, make adjustments on one or more of the request types for the hostname cell, such as, for example, blacklisting the cookie and frame request types.

On domains that I consider to be "content heavy" and require one or more "dubious" sites, I will use the narrower Domain level scope in the toolbar, then allow whatever's necessary for acceptable content rendering. This way, anything dubious (knowd.com for example) required for it will at least not apply on a Global basis.

This is where I'm at now, although things could change, depending on what further experimenting I do and if it results in something that I prefer over what I currently have

 

I've given up, sorry Gorhill. The more secure sites we have to visit, the worse this is all getting. I can't even get into the family ISP email without first allowing the main domain, then allowing one HTTPS domain and then for some stupid reason have to do it a third time before the site works. I've tried by global domain down to site specific and it's just a giant pain. Allow all as a workaround just seems to defeat the purpose of having a script blocker to begin with. Even with the other cells being allowed by inheritance, I had to go through all that. Maybe I'm just stupid and am not getting it. I've read through the documents and the now obsolete quick tours. There is something else I am not understanding or missing. When using Firefox and NoScript, pages load just fine. You can't do anything much with them of course, depending on the site. But they load. With Switchboard, absolutely nothing loads, not even the supposedly default allowed images unless one starts tweaking it. Literally all I will see is text and broken image icons, that's it. Why?

 

That's... odd. Seems very easy to use, I've had none of those issues. I think you're confused about how scope works?

Images should be loading too, since they're globally allowed. On site specific areas they won't.

 

Then there has to be something I'm missing. I'm not really visiting any site that complicated, and I'm not a 5 year old so I can read his documentation and understand what he is saying. In fact, his documentation is probably the most newbie friendly I've seen for these types of security extensions. I want to give it a chance, I'm just getting frustrated. As far as scope goes, I thought I got it, I really did.

 

There could always be a bug.

Can you give a full rundown of what you're doing and what behavior you'd be expecting on a specific website?

 

I can try to, yes. I got rid of the extension in a face to desk moment after the final time of being nagged to fix a site. Okay, let's say I go here: http://www.timewarnercable.com/en/residential-home.html. Now, before I ever touched Switchboard, that site would be text only and broken image icons everywhere. So, I go up into settings and then use that little black bar in the left top corner and choose one of the options. There is the "*host or domain" option and then an option without the "*". Choosing either one will green the cells for that domain, good to go you think. Well, click on the check email link and the site switches to HTTPS as expected. No issue, do the same thing over again...then again because even though the cells are green, I'm not getting in on the second switch over to green. It makes me repeat the process three time sin total for full, uninterrupted access. Why?

**Edit** Alternatively, I can just click the domain cell and ignore the top toolbar and it will go green. But I will still have to go through all of that in the end.

 

I would need to see the state of the matrix and the page URL to be of any help. You could share your ruleset for others to help, or if you have privacy concern about sharing them, PM them to me unless you also mind me going through this stuff (I wont take offense). But mainly what I am saying is we can't help pinpoint where there is a problem without seeing the state of the matrix. HTTP Switchboard is no different than NoScript other than the UI and the inheritance (which many NoScript users wish they had). So it should not be more difficult than with NoScript.

 

What are the colors of the Request type cells: cookie, css, img, plugin, script, XHR, frame & other at the tops of the columns upon first visiting the sites?

 

Give me just a little bit here and I'll PM you some screenshots and the URLs of the TWC site. I need to find a place to upload them (I don't do this often enough to know where).

**Edit**

Here are some screenshots. The first one relates to http://www.timewarnercable.com/en/residential-home.html http://postimg.org/image/gzqlty92t/

This is what I see when I go to check email at https://webmail.twc.com/. http://postimg.org/image/jhp20kbm5/

I told HungryMan earlier that when I went to the main site with Switchboard installed, all I saw was text and broken image icons. Obviously it was not the case this time. I am not sure why though? Perhaps a conflict with Disconnect or AdBlock? Maybe just a weird bug?

 

Because from what I've seen the hostname of the page URL changed to a complete new hostname. NoScript would have had the same behavior there.

That's what I did first move, to whitelist the domain name and the images appeared. Obviously the images are put there by some javascript code. NoScript would have resulted in the same problem of having the images no showing, so I don't understand when you say NoScript doesn't have this problem.

Using scopes out of the box might be too much if you want to familiarize yourself with the UI. I do it only for sites which I trust and which I visit multiple time daily. Otherwise I stick to temporary permissions (using domain cells only most of the time) in global scope.

But I get that this is for your email, so you clearly were on the right path. That your email provider switches between hostname is an annoyance when first creating the rules, but once they are created and persisted, you won't ever be annoyed again with having to whitelist for this part, this will be all transparent browsing your email.

The part I don't get is that you say NoScript doesn't have this problem, which I can't make sense of, because both addons do the same thing: they block scripts, so it should give you the same hard time you have with HTTPSB.

 

Here time warner, scoped:

http%3A%2F%2Fwww.timewarnercable.com%0A%
09whitelist%0A%09%09image%20*%0A%09%09st
ylesheet%20*%0A%09%09*%20timewarnercable
.com%0A%09blacklist%0A%09%09*%20*%0A​

Than webmail, scoped:

https%3A%2F%2Fwebmail.twc.com%0A%09white
list%0A%09%09stylesheet%20*%0A%09%09imag
e%20*%0A%09%09*%20twc.com%0A%09blacklist
%0A%09%09*%20*%0A​

Import both recipes above in the "recipe" textarea in the Rule manager, decode, import, than commit (to persist these rules). You are almost there I would believe.

 

Nah, I suspect you might have had a scoped all blocked matrix in effect. There is an item on my todo list to copy the global rules when the scope is first created. Currently when a new narrow scope is created, all is blacklisted. I suspect it's what might have happened here. HTTPSB, Disconnect and Ghostery all work fine together, the Chrome API allows multiple simultaneous blockers.

 

With NoScript, I believe when you allow a domain, it allows all the cookies, CSS and all that. So, although you have less control, out of the box it is easier. So yes, you might have to click three scripts to get the site working, but you won't have to click some of the other stuff that you might have decided should stay red. It's hard to explain I guess. Thank you for the rules, they work well.