HTTP Switchboard for Chrome/Chromium:

HungryMan, I may not be of much help since I'm doing this from NoScript at the moment. But all I did was allow "cwtv.com" and I was watching full episodes without touching any other domains. I'm assuming you tried that in the domain option though. Perhaps if you allow everything on that domain, cookies, scripts, plugins and whatever it may ask for? There are a ton of other domains there such as media6degrees.com, google-analytics, realtidbits.com and some others. But I didn't have to allow any of them. I'm not sure why unless NoScript has something that was already in its whitelist on install, because I've yet to globally allow anything. Is there a code.jquery.com anywhere on the site? NoScript allows that by default, so it doesn't show in the scripts list when I go to CWTV.

 

I think the blacklist is causing issues with it. I've always had issues with that site though, I think it plays very poorly with ABP/ blocking extensions.

 

i could not get this one to work also.

i tried everything.

 

If I were home right now I could check the matrix. Unfortunately I'm in a semi stuck in 3 feet of snow and -20 degree weather. See I had ABP installed alongside Switchboard because I got to thinking about issues such as ads in videos, which I don't think Switchboard can stop. If it wasn't for that I would have probably used Switchboard by itself.

 

When it seems too complicated, create scope, whitelist "all", then there is probably just a few remaining steps to make it work. In this case, I use the request log to figure what it wanted:

http%3A%2F%2Fcwtv.com%0A%09whitelist%0A%
09%09*%20ad.doubleclick.net%0A%09%09*%20
warnerbros.112.2o7.net%0A%09%09*%20secur
e-us.imrworldwide.com%0A%09%09*%20s0.2md
n.net%0A%09%09*%20*%0A​

If it wasn't for the ability to scope, it wouldn't be very acceptable to whitelist ad.doubleclick.net etc., as this one is required to make the site work.

EDIT: We really need some kind of system, a wiki, or DB to make these recipes discoverable for people having similar issue. I need to come up with something in order to try to not lose too many users to ragequit.

EDIT: This one might be better, I tried a video for another show, and unless there was some serious network latency, it didn't work, and the request log was showing another doubleclick.net hostname blocked.... So:

http%3A%2F%2Fcwtv.com%0A%09whitelist%0A%
09%09*%20ad.doubleclick.net%0A%09%09*%20
g.doubleclick.net%0A%09%09*%20warnerbros
.112.2o7.net%0A%09%09*%20secure-us.imrwo
rldwide.com%0A%09%09*%20s0.2mdn.net%0A%0
9%09*%20*%0A%09graylist%0A%09%09*%20puba
ds.g.doubleclick.net%0A​

 

Well, the issue with that might be that rules could be all over the place, depending on the preference of whomever shares them. Also, that's a tall task unless folks just stick to the absolute biggest and most common websites. I haven't ragequit just yet. Now you have me wondering what NoScript was default allowing in order for me to not have a single issue with the site once I allowed the Cwtv domain. I know the options contains some Google entries in the whitelist, but I don't believe they are related to Doubleclick.

 

Just include link at the manage rules pointing to a rule at your github page?

 

You could always just have a rules file that you keep on GITHub. Anyone could make a pull request for a new rule and it would be distributed like the rest of the code.

I tried going with 'all' and with scope and just narrowing it down from there. I think the player really hated me on top of everything, so it wasn't easy to get working. I'll give that ruleset a try, thanks.

 

The page was choking when it couldn't get its .swf files (ads) from a few of the preset blocked hosts. I think these .swf files are pulled by the flashplayer, so in NoScript, if you allow the plugin in the first place, this plugin is allowed to pull whatever. My speculation, I didn't look at how NoScript works internally.

 

That makes sense when realizing that NoScript out of the box allows Flash, Java and the rest on whitelisted websites. With Switchboard, you can allow the domains all you want, but the plugins are still a no go unless you okay it. I like your way better, it just makes things a wee more complicated on sites like CWTV. So am I right to think that the ads that were causing such an issue wouldn't if ABP were coupled with Switchboard? In the case of HM, he had to allow the ad server to get the video to work, but ABP would still keep him from actually seeing the ad? Am I on the right track?

 

I am still confused about how HTTP Switchboard interacts with some of Chrome's own settings, especially the option "block third-party cookies and site data". Does it override this option? I just want to know because I'm curious.

From what I've understood, HTTP Switchboard doesn't stop third-party cookies and site data from getting on to your computer, it rather somehow disables communication between this third-party data on your computer and the website. Is that correct?

 

You might prefer another approach: Allow plugins globally in HTTPSB and select click-to-play in the Chrome settings. This makes life a bit easier.

 

No, it doesn't. On the other hand, If you block cookies in HTTPSB, all cookies are affected regardless if they are 1st or 3rd party cookies.

 

I think I will change the plugin type to not be blacklisted by default. I chose that a long time ago before I learned about the click-to-play feature (this is the way I use it). That will be one less hurdle to deal with for less geeky new users.

Re. "but ABP would still keep him from actually seeing the ad", I have no clue, I'm not sure how ABP blocks the ads (I know it has a webRequest handler like HTTPSB, but beyond that I don't know the details).

 

It allows/block communication based on the state of matrix, without caring one bit about Chromium settings. The only place where HTTPSB plays with Chromium settings is to create two rules to allow javascript from everywhere. So except for javascript, any other settings you have in Chromium will take effect as expected.

 

Raymond, I suggest that if you implement that, a warning/hint should be added that chosing click-to-play is highly recommended.

 

So what is the behavior if a user has, through Chrome/Chromium Content Settings, blocked javascript for site1.example? Perhaps before installing HTTPSB, or after?

In a way that is like having two blocking extensions/tools installed, where you would allow either one to block the operation. It should work without one tool tampering with the other's rules. Are you really just doing this so that your extension will see the requests for scripts and be able to present the hostnames to the user? Would you see the requests for scripts if the other tool were, instead of Chrome/Chromium's built in javascript blocker, Adblock Plus or some other proper extension?

 

Either way, your block JS rules are ignored once HTTPSB is installed. It's "Allow" takes preference over your "block". Likewise, if you block all JS in Chrome's native settings via "Do not allow any site to run JavaScript", they are now allowed to run.

 

HTTPSB disregards whatever is in the exception list: Why does HTTP Switchboard ignore my existing settings first time I install it?

I linked to the explanation of why I am doing this: Why does HTTPSB allow all javascript in Chromium settings?!?

"However the Content Security Policy directive works by assuming that when the directive is not present, javascript is allowed to run by default. Hence to enforce this definition, HTTPSB has to be sure that all javascript is allowed to run by default and to bypass any existing rules by the users which could interfere with the expected behavior of Content Security Policy directive usage."​

My understanding is no, other extensions do not see requests which have been cancelled by one of the extension, but they are notified of the cancellation. From Chrome API:

"If an extension cancels a request, all extensions are notified by an onErrorOccurred event"​

 

0.7.4.2

* More work done on translation by volunteers:
Deutsch (issue #123) von tlu1024
Français (issue #69) par tailHey

* "Plugin" column in the matrix is no longer blacklisted by default for first install.
It is strongly recommended that new users enable "Click to play" for plugins in their Chromium-based browser settings.

*Fixed https://github.com/gorhill/httpswitchboard/issues/125

 

I love how quickly things get fixed and how tweaks get made to keep security in focus yet make the lives of users easier. Great extension, great dev.

 

I read that, several times in fact, but I find the wording confusing and don't understand why you would need or want to change Chrome's javascript allow/deny settings.

If there are no CSP directives that restrict javascript X from being loaded/run, then javascript X will be allowed past *the CSP checks*. That doesn't mean javascript X will necessarily be allowed to load/run though, because the browser itself and any other extension that cares to can block javascript X. Right?

The way I'm thinking, HTTPSB only has to decide whether to cancel a request for a particular Javascript... if and when it sees one. Not enforce whether a "allowed to pass by HTTPSB" Javascript will actually be allowed by Chrome itself. Even if Javascript were disabled in Chrome, HTTPSB should work OK. It just wouldn't show some hosts that would show up if Javascript were allowed.

Unless you are trying to take control away from Chrome and its Javascript blocker. However, given your answer about extension interactions, it doesn't sound as though you can reliably control whether Javascript is allowed or denied. At the very least, other extensions will have a nope vote.

I'm genuinely curious to know if I'm overlooking something and/or better understand why you need to change Chrome's javascript settings. Hopefully, you can see where you need to comment. If not, perhaps you could describe the bad thing that would happen if you left Chrome's javascript settings alone.

Thanks.

 

Yes, HTTPSB does that for external javascript. But did you miss the part about inline javascript? Inline javascript is embedded javascript in the main page of a site. You fetch the page, you fetch everything in it, including inline javascript.

a = Chromium setting regarding javascript

0 => javascript disabled in Chromium settings
1 => javascript enabled in Chromium settings
​

b = HTTPSB setting regarding javascript

0 => javascript disabled in HTTPSB settings
1 => javascript enabled in HTTPSB settings​

a b
0 0 => ok
0 1 => not ok, HTTPSB can't enable javascript
1 0 => ok, HTTPSB can disable javascript using CSP
1 1 => ok

This means we need to find a way to get rid of case number 2:

a b
0 0 => ok
0 1 => not ok, HTTPSB can't enable javascript
1 0 => HTTPSB can disable javascript using CSP
1 1 => ok

This means we need to get rid of a=0 to give full control of inline javascript execution to HTTPSB: Hence the two rules which enable javascript from everywhere in Chrome settings. Now HTTPSB can give full control to its users without any requirement re. Chrome settings.

No bad things would happen. If the user had javascript blocked, HTTPSB would have no way to reliably allow inline javascript (thus it would stay blocked). If the user had javascript allowed, HTTPSB would have complete control to reliably block inline javascript (HTTPSB would be able to block inline javascript).

 

Yep even on IE11 with ABP+ TPL it won't play

 

Less so than that comment of mine would suggest, but I haven't thought much about the inline javascript scenario because I thought it wouldn't affect the answer to my question.

I was trying to determine if you must force-enable Chrome javascript settings in order to block something that the user wanted to block. The "if javascript is blocked by Chrome settings or CSP or HTTPSB [or other extension] then it must be blocked, otherwise it should be allowed" type of cooperation between permission control elements. The case you crossed out as not OK actually seems OK from that POV. Unless I still don't understand some "HTTPSB handling of inline javascript" issue.

It sounds as though you are merely choosing to override Chrome settings that restrict javascript simply because that will allow users more control over javascript (enabling) through the HTTPSB user interface ALONE.

If all that matches with reality and what you were describing, we're on the same page.

FWIW, my main interest and question here had to do with how CSP was being handled. When I first heard about CSP I was concerned that spec contributors and/or browser developers might decide to give CSP (and website operators) too much control over the user's browser. As in the ability to force-enable something that the user was trying to disable/block. Thus the "why you do that" questions. I wasn't trying to pick at you and your decision. It is nice to be able to ask such questions and have such a discussion. Thank you.