Komodia's Redirector user experience guide
When deploying a product for end user, it requires special attention to the small details because users wants things that may look wierd to us, but since everyone wants to have a maximum conversation rate those concerns need to be addressed. In this page I'll go over the way the Komodia's Redirector words in regards to user experience and how it can be modified.
- 1 Installing
- 2 Uninstalling
- 3 Reboot
- 4 Install then uninstall
- 5 Updating
- 6 Rules update flow
- 7 Rules update
- 8 Connection status when switching rules
- 9 Auto start vs Manual start
- 10 Browser caching
- 11 Interaction with 3rd party products
When installing all running application will not be intercepted, it's always advised to reboot after an install.
When uninstalling some running applications may no longer have networking, it's always advised to reboot after an uninstall.
When installing the SDK, it will not affected any running application until they are closed and re-opened, or the computer is rebooted.
A way to overcome this is to force the user to close all network apps you plan to intercept before you install the SDK.
Install then uninstall
This behavior will cause network lost, never install after an uninstall without a reboot in between.
To update the LSP you use the install method, the Komodia's Advanced LSP Installer will identify it's an update scenario and will update the LSP without any need for reboot.
Before updating the service it must be stopped, if there's any intercepted connections they will be terminated.
Rules update flow
When a process starts the Winsock LSP is receiving the rules from the Redirector.
After the interception rules was updated it will not be automatically sent to all running applications (ofcourse all new instances will receive the rule update)
The rules will be updated inside the already running applications by two ways:
- The application will hit its refresh timeout and will automatically query for the new rules (this occurs by default every one minute)
- You will tell the Redirector to send an update to all Winsock LSPs and all the rules will be send instantly (to send an update you call the method CDataController::BroadcastChange with parameter of 1).
Connection status when switching rules
Updating the rules will not affect existing connections: a browser is connected to Google's website and there's no rule to intercept port 80 or the browser so the connection is made directly, after you set a rule to either intercept port 80 or the browser (and assuming the rule was updated inside the browser) all new connections will be intercepted, but the already existing connection is not, if will stay alive and the browser will use it to get data from Google until it is closed by the server or the browser, this behaviour is observed by refreshing a website after the rules was updates, but the "new" connections are not intercepted, because they are not new.
The same scenario works in reverse, intercepted connection remain intercepted even after the rule to intercept them was deleted.
Change from non intercepted to intercepted
To forcefully close non intercepted connections you can call CDataController::BroadcastChange with parameter of 2 (instead of the original call with parameter of 1), this tells the Winsock LSP to update the rules and close the connections (only connections that should be intercepted because of the new rules):
- HTTP Connections - The Winsock LSP detects if a connection is HTTP, if it is, the next HTTP request on a non intercepted connection will be redirected into the Redirector using a 302 HTTP reply (a running HTTP download will not be redirected until the download is finished)
- Non HTTP Connections - Will be terminated on next send or receive.
Change from intercepted to non intercepted
When disabling the Redirector it will redirect all HTTP connection to non intercepted state. It will close all non HTTP connections (this is a compile time flag which needs to be requested).
Auto start vs Manual start
The Redirector comes in two modes:
- Auto start - The Winsock LSP component automatically starts the Redirector service if it's shutdown.
- Manual start - The Winsock LSP component does not start the Redirector service if it's shutdown, in addition no redirection is taking place if the Redirector is shutdown.
The setting is defined at compile time, so if you have a version that does Auto start or manual start and you want the other option you need to request it, due for technical reason it's not possible to set this at run time.
The Winsock LSP will also query the Redirector for the most recent set of rules every one minute regardless of the state the Redirector is in (if it's shutdown, this will auto start it), this value can be changed by changing the flag: "lsprefresh", the flag is denoted in miliseconds.
This is the default setting for the Redirector.
The Winsock LSP will also query the Redirector for the most recent set of rules every one minute but only if the Redirector is in a running state, this value can be changed by changing the flag: "lsprefresh", the flag is denoted in miliseconds.
Auto update on restart
Further more there's a compile time setting which causes the Winsock LSP to refresh the rules each time the Redirector is started.
When the browser has old cache inside or even new cache (if you don't disable caching) it means that some content may go unfiltered or unredirected because the browser will use the local content rather then the server content, this can be a problem when trying to check IP notifying sites (to test anonymizers) or when trying to do content check.
If one of these scenarios may pose a problem we recommend that you:
- Delete all the cache for all browsers when you first install your product.
- Tell the Redirector to disable caching, you can see how here: Komodia's Redirector installation guide#Enable_clearing_cache
Interaction with 3rd party products
The SDK should not be detected by any wide spread Anti-virus, this can be checked with this site: Online virus testing sites
Some security products block installation attempts regardless of the product you try to install, for example:
- Block attempts to register a service
- Block attempts to register a LSP
- Block outgoing connections
Nothing can be done to circumvent these types of protections, and it's a matter of user education. Some firewalls are in paranoid mode that even when you try to surf with a legit browser on a clean machine, it will request for permission.
The SDK is not a security product, spywares will damage many aspects of the user experience. We don't provide any compatability with spywares.
3rd party LSP
Please read this guide on LSP conflicts
Basically you have number of options:
1. Don't install when another LSP is installed. 2. Forcebly remove another LSP. 3. Work with an existing LSP. We highly recommend to test such installation with the specific LSP type before doing this at the user's computer.