HTTP Switchboard for Chrome/Chromium:

Yes, that's what I meant. Sorry for not being clear.

I'll take a look on it later. Anyway, thanks for the answers.

 

Hi Raymond,

sorry to say, but this issue is still happening after the latest updates. The page won't go blank right away; it takes about 10 seconds or so after it loads.

*EDIT*

sorry, just an unrelated question to the above, Raymond:

what happens in the case where scripting is allowed on a website where the web server is not properly sanitizing the user's data, resulting in a persistent XSS vulnerability? So in the example of a bank website, if I've already allowed scripting for the online bank I deal with, and later some attacker discovers the bank's web server's application filtering is faulty and places a malicious script that allows the attacker to, let's say, steal my session cookie, would I be protected with httpsb or not? Thanks!

 

A contributor on github found a workaround for the problem (really nice, investigating these things on bloated page like that is time consuming). Enter the following filter in your custom blacklist entries in the Ubiquitous rules tab:

||www.tsn.ca/scripts/min/hub/foot/139748129.js​

Then click Apply changes. I tried it, it worked fine.

The bug still need to be investigated further though, as clearly it happens only if UA spoofing is turned on.

 

Thank you so much Raymond and also to my-password-is-password for helping me on this issue. *Sigh* unfortunately even with that filter it's still loading blank on me

 

Hopefully this will be fixed in the next revision (maybe today). my-password-is-password further investigated and found that there was something wrong in the UA spoofing (browser version number was not properly spoofed). I am pretty sure this will fix the problem.

 

Thanks again, Raymond, and sorry to be such a PITA with this nuisance issue. BTW, just an unrelated question for you: is there still protection using httpsb if, for instance, after scripting is allowed for one's online banking site, an attacker discovers a user data sanitizing issue in the bank's web server application and places a malicious js code on it that allows the attacker to steal the user's cookie session via a Persistent XSS attack? thanks!

 

I feel people with better in-depth knowledge are better placed to asnwer, but my understanding is that you are protected as long as HTTPSB is used in a block-all by default. So you allow your bank and whatever friendly servers your bank requires, but all requests to anything else are blocked. So an evil script could run (as it comes from your bank server), but the evil script won't be able to create connections.

 

I think you are correct. After refreshing my memory with some research, a malicious script used in a Persistent xss attack would most likely be formulated to re-direct the victim to an attacker's site, maybe a BeEF Exploit suite, would fail with httpsb in block-all by default mode because the script on the suite will not work. The non-persistent xss attacks are less concern because those are usually triggered via an email phishing attempt first. Thanks again!

*EDIT*

struck out part of sentence because I think I misunderstood there being a script on the attacker's side.

 

Raymond, thanks a lot for the new HTTPSB versions that support Element Hiding Rules - that's really fantastic news! I've finally ditched Adblock.

 

Raymond,

it looks like that infuriating tsn.ca page going blank is all fixed up now Thanks so much again for your's and my-password-is-password's help!

 

Per-site permissions are gone?

 

No, they aren't. (This site is outdated, indeed - I've already suggested to tag it accordingly.)

 

No. What made you think so?

Edit: I just saw Chrome 35 has landed, I got scared that something in HTTPSB broke with it. All seem to work fine.

 

I guess newchina08 was confused by that outdated site I was referring to. HTTPSB looks rather different now ...

Yep. Same here.

 

I got it, thank you!

By the way, when first installed, it's like
http://i.imgur.com/uWRUufT.png

But after I clicked 'Reset to factory'
http://i.imgur.com/K2ivmzS.png

Then became this
http://i.imgur.com/sXUfIK7.png

One '**' is in blacklist and the other is not, why?

 

I've kept an eye on this thread and tried the product a few times. Just couldn't get my head round it. I think because I'd used NoScript in FF many years ago and came at it from the wrong angle. I have been using it for a day or 2 now and finally got a chance to read through the wiki etc and the penny has finally dropped.

What a marvelous addition to Chrome this is. An hour or 2 going through the sites I visit most regularly to tweak the best mix for (very personal and too open for most I'm sure) settings for me.

I'm amazed at the rubbish that's served on almost every site you visit and how easy it is to get around sites I like without the jumble of scripts and junk assaulting you eyes.

It reminds of when I started using Malware Defender on an old x32. It taught me so much about what was happening in the background on my system. This is doing the same for me for websites I visit.

Anyway thought I'd post to let those like me who're unfamiliar with this type of thing know that it really isn't that scary. Even if you use on fairly open settings you can now drop you're adblocker (ABP lists and element hiding (beta) now included) and still get the addition of a robust baddies blacklist to protect you. Once you get familiar you can close more scripts/trackers etc off until you get a good balance of security/privacy and usability.

The only issue I have is with Facebook. Don't use it (and never will now I see what goes on behind the scenes) but the wife does. To get video to work and play her stupid games the settings need to be very open. It's quite scary seeing everything that's running. Not HTTPSB's fault but my god FB's just a big identity trap masquerading as a social network. Anyway, HTTPSB is still blocking stuff I wasn't before so much better than nothing.

Cheers

 

I couldn't agree more!

I don't use Facebook, either. However, you might try some recipes for your wife available here, here and here. Perhaps they satisfy your wife's needs while still blocking enough stuff.

 

Thanks, will give those a try.

Cheers

 

Actually this blacklist entry is not really needed, as it is redundant since HTTPSB is hardcoded to block everything ultimately, i.e. if all rules are removed, all requests will be evaluated as "blocked".

 

Ok, I'm behind on HTTPSB development.. I like the new Noscript-like feature with a preference of strict blocking and auto domain level scopes. Now everything is even easier to manage. I started from scratch again to see how easy it would be to get up and running quickly. Your extension needs lots more publicity because I am sure tons of people would love it!

 

Ah so that means you whitelist the script cell to enable scripts on a domain rather than whitelisting the whole domain, right?

Maybe this makes more sense for offering a NoScript-like approach... I went with strict-blocking disabled because I figured NoScript users are used to whitelist a domain name to enabled scripts... But I can see the advantage of your approach, you don't end up allowing scripts and frames. I think I will change the setup for NoScript to your idea.

Edit: Actually with strict-blocking disabled, a user can still allow only scripts without allowing frames. Duh, there is so many ways to use the matrix I keep overlooking ways to use it sometimes.

 

I detest cookies so I blocked all cookies except for those I whitelist or greylist. There are many ways to skin a cat in HTTPSB, <yoda>Lots of freedom with you extension, there is. </yoda>

EDIT: With your NoScript-style you can disregard the minutia of all the various hostnames on the domain like cdn.yodaspeak.com script.yodaspeak.com ads.yodaspeak.com. You can allow or block *.yodaspeak.com, which shows a nice short list of domains on the matrix

 

Very sad news.

I don't know what happened.

I sincerely hope that Raymond will reconsider his decision.

 

This is the only extension I have been using for some time.It is a great extension.I spent some time to learn and use it.Now it is not going to continue

 

Sad indeed.
I would like to know why if only to rule out any undesirable interference. If it is simply too much work then I completely understand.
I'm very much at the novice stage learning to use HTTPSB and was formulating some, hopefully relevant, questions. Perhaps there is no point now.
Raymond is clearly one of the good guys out there. He reminds me of Tzuk in many ways. This is/was an outstanding piece of work and I wish him well.