HTTP Switchboard for Chrome/Chromium:

thanks for clarifying, perfect! this makes a lot easier to fiddle with the rules

 

I like the new UI for the most part but how do I do per-site?

edit: Interesting! I like it. Figured it out.

 

i like the new interface introduced in 0.7.0.0,
especially the reload button built-in.

very nice!

only thing i wish for would be for HTTPSB to remember the state of the padlocks when you Import your rules.

also, the extension does not seem to update automatically every times.
i just uninstall, install again and re-import my rules.

 

moon, I assume that you have the "Process behind-the-scene HTTP requests." setting enabled, haven't you?

 

the box is unchecked.

i don't understand correctly if this feature is enabled or not when the box is checked/unchecked.
i find the HELP confusing about this particular feature...

 

That feature is enabled when the box is checked.

Regarding your update issue I don't know what to say ...

 

I definitely need to complete the features in there, I can see how annoying it must be to import all rules and having to click all padlocks. I consider a high priority bug to finished the features in the Rule manager. That will be the next release.

 

I am a bit confused by the new UI. How to selectively allow something permanently? Clicking on the lock after "greening"?

 

Correct, after clicking the cell to dark green, then hit the padlock.

 

Yes, the one padlock at the top now replaces all the little padlocks that were specific to each cell. Anything which is not locked will become locked, including the scope.

This was necessary to implement this new UI because I was trying to resolve how to implement temporary scopes: "temporary scope" made no sense if you could make the rules permanent within the temporary scope.

In retrospect, it makes more sense this way I find: when the user is satisfied with the whole state of the matrix, he just clicks once the padlock to make it persistent.

 

@gorhill: In several issues of your bug/issue list you're addressing various tracking mechanisms. Beyond those, sites like Panopticlick or ip-check reveal that even with javascript disabled lots of information like content types, encoding, fonts, browser window can still be used for tracking/fingerprinting purposes. Do you see any chance to protect against that? I think it can be partially done by manipulating accept headers.

 

I'm starting to entertain the idea of another extension which would provide more privacy-related options rather than try to cram too much in HTTPSB to the point where it tries to do too much but clumsily. I currently like the simplicity of the matrix with a few settings, and focusing on doing well what it is intended for.

I've been reading a bit today and it's possible for extensions to communicate between themselves (my understanding, I didn't try yet), so HTTPSB could tell another extension which focus on privacy that the user blacklisted cookies, and so the other extension takes over the task of managing cookies, along with all the rest of privacy related stuff. This way both extensions could focus on doing best their well-defined narrower purpose.

There is something about cramming too much in one extension that I don't like. Code would be easier to maintain too.

 

Yes, I was going to post on the bug report to be careful that you don't put too much into just the one extension.

Simplicity is one of the best parts of the extension - the matrix is, honestly, quite a smart approach. It is one thing to have some advanced settings that are relevant to the matrix/ the content already being filtered in the background, but I would be careful about growing the *purpose* of the extension rather than its capabilities in the predetermined goal.

Extensions can communicate with each other but it is asynchronous I believe.

 

I understand. However, if Hungry is right and communication between extensions is asynchronous - wouldn't that be a deal-breaker?

Regarding cramming too much in one extension: Yes, that's problematic. On the other hand, if those features were explicitly labelled as advanced options which are disabled by default, new users should not be necessarily overstrained. And if managing those advanced features - once enabled by the user - were transferred to, say, a context menu, the matrix would be unaffected.

Just my 2 cents ...

 

In trying out HTTP Switchboard, I now have several per-site permissions saved. How would one go about removing them completely from the Rule Manager, and in that regard, how would I back-up and restore those permissions again ?

 

All calls are asynchronous in Chrome API, except for a very few exceptions, so I know he is right. I don't see this as a problem. There is no need for passing information synchronously, the only thing another extension would need to know are the rules, then it acts upon them on its own.

 

In your version, to remove a scope you would need to go on a page where it will show in the matrix, then select global scope in the matrix and click save.

To back up/restore, for now you have to export all the rules in the "Rules manager" page, copy and save the resulting text somewhere. Then later you can paste this text in there and import.

I am currently working on the Rule manager page in order to make it possible to delete ruleset.

 

Ah, I see. Thank you gorhill. I must say, your perseverance towards making this the best scriptblocker ever, is really praiseworthy.
A delete button will be very welcome.

 

Import/export would be nice to have

 

It's already in the "Rule manager". However currently the user has to cut/paste to export/import, as it's not possible to save to file system.

Although I think I could "download" the exported data to the Download folder, and probably let the user select a file to read from to import. I need to read more on this.

 

A very interesting extension gorhill, congratulations. I have no instance of Chrome/Chromium to test with (on purpose, and at least for awhile longer) but I am curious about a few things. If you have a moment...

Are there any third party requests that can't be detected and blocked, perhaps due to API limitations? You're likely more familiar with these HTML5 and other mechanisms than I am so I'll just start broadly in this way.

To what degree are you covering redirect scenarios? For example:

a) The user navigates to [noparse]http://host1.example/index.html[/noparse] which is allowed to load images. An image element on that page is requested via [noparse]http://host1.example/img.png[/noparse], the response redirects to [noparse]http://host2.example/img.png[/noparse] which responds with the desired image.
b) The user navigates to [noparse]http://host1.example/index.html[/noparse] which is allowed to load images. An image element on that page is requested via [noparse]http://host1.example/img.png[/noparse], the response redirects to [noparse]http://host2.example/img.png[/noparse], that response redirects back to [noparse]http://host1.example/images/img.png[/noparse] which responds with the desired image.
c) The user navigates to [noparse]http://host1.example/[/noparse], the response redirects to [noparse]http://host2.example/[/noparse].
d) The user navigates to [noparse]http://host1.example/[/noparse], the response redirects to [noparse]http://host2.example/tracker.php[/noparse], that response redirects back to [noparse]http://host1.example/home.html[/noparse].

A user may want to block ALL requests to host2.example including those. Alternately, the user may want to be informed of and block those and other redirects to host2.example only when they are interacting with host1.example. Are there any notification and/or blocking limitations with respect to such redirect cases?

Can a domain (that a user manually configures, or one that is a malware domain you pull from lists) be entirely blocked such that the user can't load *anything* from the domain even if they attempt to do (via address bar for example)?

Can one restrict navigations away from a given domain? For example, set things up so that host3.example not only loads items only from host3.example but also the links found on host3.example will only be usable if their requests go to host3.example?

 

I am not sure what you mean by "third party requests". You mean when visiting a web page, a request made to another hostname than that of the main web page? If so, Chrome API's `onBeforeRequest()` is called for every element on the page which requires a net request, third-party or not.

Just as a preambule, Chrome API's `onBeforeRedirect()` can't block, so I don't use this listener.

Now for a) to d), I would have to confirm by testing, but here are my answer given my current understanding of Chrome API:

a) HTTPSB will be called (and given an opportunity to block) when the request to `host1.example` is made, not when the request is redirected to `host2.example`. But really I would need to test to confirm. I wouldn't be surprised if I am actually wrong on the second part (that would be good, right?)

b) Same as a).

a) and b) I was wrong. HTTPSB is called when there is a redirection: really bare test

c) I did test, using a link in this twitter post: So from `twitter.com` to `t.co` to `goo.gl` to `www.kulfoto.com`.

If I blacklist `t.co`, `t.co` was redirected to HTTPSB's "blocked" replacement frame. If I blacklist `goo.gl`, `goo.gl` was redirected to HTTPSB's "blocked" replacement frame. Etc. So top-level redirects are going through HTTPSB's `OnBeforeRequest()`, which then can allow/block according to the rules.

d) Same as c).

That sounds like a scoped ruleset. You can create a set of rules which will apply only to a specific domain or hostname. So yes, a user could blacklist top-level redirects to a specific domain (or hostname) when browsing a web page from a specific domain (or hostname). But redirects are not reported in the matrix, only hostnames/type for when `onBeforeRequest()` was called.

Yes, if a hostname is blacklisted, every attempted requests will be cancelled. Still, if user whitelist `image` from a blacklisted hostname, the requests for image will be allowed (that would be a weird rule but it is possible using the matrix).

Yes for the first part, no for the second part. So you can restrict requests to only a very specific hostname using scoped ruleset, but the extension do not touch the DOM at all, so I do not temper with the links.

 

Yes. Unless your checks include protocol and port number like some origin checks do.

Browser bugs/limitations have impeded filtering extensions in the past, so I figured I'd ask. If there were some case where onBeforeRequest wasn't called... perhaps something more obscure like a CORS preflight request, a WebSocket handshake request, whatever... it could theoretically go unnoticed for awhile. FWIW, a quick search turned up this but I'm not certain it is applicable:

chrome.webRequest.onBeforeRequest doesn't intercept WebSocket requests
https://code.google.com/p/chromium/issues/detail?id=129353.

Do you have any visibility into plugin network traffic? Can, for example, you see HTTP requests made by the built-in flash player?

Sounds like you are in pretty good shape then. What about top-level request redirects, though. User clicks on a link and they are headed to [noparse]http://site1.example/whatever[/noparse]. Which redirects them to [noparse]http://site2.example/whatever2[/noparse]. Which redirects them to [noparse]http://site3.example/whatever3[/noparse]. Which redirects them to [noparse]http://site1.example/home.html[/noparse]. The user wanted and expected to interact with site1.example, but got redirected... possibly with privacy harmful data passing... to site2.example and site3.example. When HTTPSB sees the request to site3.example, is it making an origin comparison between the site3.example request and the first site1.example request?

What you said above made me think that your onBeforeRequest handler would see all the hosts contacted as a result of redirects. In any case, the point of my commenting was to draw some attention (including user attention) to the issue of redirects. If there is some limitation that prevents users from seeing hosts contacted through redirects and/or creating certain kinds of rules for them, perhaps there is an opportunity for improvement(?).

For requests that are allowed to go through, can you determine the exact IP Address that the browser was using to contact the host? Can an extension do reverse DNS lookups? There may be some issues with this, but just to throw out an idea: one issue users face is that they don't know (without research) whether they should allow foo.site.example when visiting [noparse]www.site.example[/noparse]. In numerous cases, foo.site.example is actually a host operated by an advertising/tracking company. Comparing the IP Addresses and/or reverse DNS records of [noparse]www.site.example[/noparse] and foo.site.example can give some clues. Is there an opportunity to display such helpful information, perhaps when hovering the mouse over a hostname in order to save UI space?

FWIW, I didn't mean tampering with the links. Basically, I meant comparing the origin of the page you are leaving to the origin of the page you are about to visit and blocking the request per rule. I've seen some contexts where that would be helpful. For example, I recall a financial site that would... from post-login pages served via HTTPS... include non-HTTPS links to a different subdomain host and also some data passing links to an entirely different domain operated by a third-party. Top level requests to the hostnames in those later links would be fine in a different context, but not "from" [noparse]https://members.bank.example/whatever[/noparse].

 

Interesting. When working on Github, I often see net traffic that looks like:
Type "other": https://github.com/_sockets/NTg...

I had assumed these were related to websockets.

I think I do, when I stream a flash-based Youtube, there is a constant traffic of [noparse]<object>[/noparse] requests with plenty of data in them.

 

Maybe they are and that wasn't/isn't applicable. FWIW: http://www.websocket.org/echo.html.

Well the thought was that if you could inspect the flash requests you could notify about and block cross domain flash accesses. Subsequently I remembered the crossdomain.xml thing. I'd have to read up on the subject to know, but perhaps you fully address cross domain flash communications as you block the cross domain requests for crossdomain.xml?