This update fixes an issue with our last update 126.96.36.199 where the migration to Sqlite DB used to fail in cases where the call record name had Unicode characters in its name and it used to give an Initialization Failed error. With this update, the migration should go through smoothly.
Our goal always has been to provide a very simple easy to use Call Recording application. To that end we employed a very simple and sparse UI. It used to look like this.
A simple html window where all the records were listed with the options. Unfortunately this interface was also very restricted. We were looking for an easy and seamless way to integrate the desktop client with our web service.
So in the 188.8.131.52 update we completely removed this in built UI and instead embedded a small web server in our application. This enabled us to present the UI in a browser. And the result was this.
As you can see, this interface is far better than the previous one. Better listing, embedded flash player, search/sort/filter options and more responsive. We firmly believe that its a big step towards making our application and service better for our users.
The end effect is that you seem to be browsing a page on our web server but magically your local data turns up in the browser! Sounds scary right. How did my data end up being on your server? Did we steal it?
The short answer is no. The long answer is that we used XSS. XSS is a technique which which is widely used for phishing and other website related attacks. But has seen growing acceptability in the recent times. Several popular web API’s use it (eg. Twitter, Flickr, Google AdSense). When used for legitimate purposes it can be a very powerful tool.
But as Saul in his comment points out, it can also be used by hackers to inject malicious JS into our application and steal the local data from the computer. The point is valid and its good that someone raised it.
Yes. That is a possibility. And anticipating that we have taken several steps to prevent it from occurring. For starters, the http port of the client is dynamically generated. At each startup this port number changes. The web server also has inbuilt checks on the types of requests it responds to. It processes requests only from the localhost. The query string has strict checks. It does not open up the whole computer and does not serve any files. It is in fact a very limited implementation of a web server. The actual content of the call record, the mp3 content, is not fetched via XSS. The embedded flash player directly downloads it to its its cache. Going forward we also plan to put in SSL and encryption into it.
We have put in all the safeguards that we could think of to prevent such an attack. You are most welcome to have a look at the JS code. Its not minified at this point of time, so you can just browse through it. Please do have a look and let us know if we can improve on something.
On the question of us stealing your data, it should suffice to say that we are a legitimate business entity running a service for which we have paid users. We are fully committed to protecting your data and ensuring that nobody can gain unauthorized access to it.
Embedding a web server in a desktop application is not entirely a new concept. Google’s Desktop Search does that, although it uses static html pages. In the embedded systems programming world its fairly common technique. Using XSS along with it might be new. To be honest we don’t really know if there is a precedent. I am sure others have thought about it. But if we are the first to actually try it out, then allow us to take the credit for it. We think this is a very effective way of protecting the users data, while still delivering services from which add value to our customers. Our service is a hybrid between a desktop application and a web application. We want to provide our users with a seamless experience between the two. And this method allows us to do exactly that.
We hope this post clarifies any questions regarding our update. Feel free to post comments and discuss it here.
This is a major update of the client. The UI has been completely revamped and moved to the browser. Clicking on the history menu item or the configuration menu item now opens the default browser window. It adds quite a lot of options on searching/sorting/filtering of the call records. Here are few screenshots of it.
The recordings page shows all the records found on the local machine in the main area. Upto 10 records can be listed at a time and pages are shown for navigation. Clicking on the play button launches an inbuilt flash player which plays back the file. Clicking on the show details link reveals all the metadata of the call records (eg. date recorded, size, duration etc.). The rename and edit tags link can be used to edit the details. The upload link queues the files for upload (only if your client is associated). The delete link removes the record from your machine.
The sidebar shows the options for batch file operations, searching, sorting and filtering. Now multiple records can be selected at a time and either deleted or queued for upload. The records can also be sorted in ascending/descending order of time, size and duration. The default is newest. The search dialog can be used to locate a record by name or tags. The filter can be used to narrow down the listing by a specific criteria (the possible ones are duration, size, uploaded, date and recorded by).
The cool thing is that search, filter and sorting and be applied one after the other, in any order. So you can locate a call record by name ‘echo’ recorded on a ‘Sunday’ and ordered by ‘increasing duration’. 🙂
The configuration page is an exact replica of the the configuration dialog. It has five tabs, for general options, update settings, recording params, association and advanced. Each of these tabs show a subset of the settings in that particular group.
This is our first step in integrating the desktop client with our web application. Going forward it will be a seamless experience. All the services offered by our web application (sharing, transcribing etc.) will now be delivered through this particular interface.
Apart from the UI change, several bug fixes also went into this release. One of the major bug fix was the issue of connection getting lost between the client and Skype because of which the calls would not get recorded automatically. Now we have added a keep alive mechanism to keep the connection going.
Another major bug fix was the long startup time it used to take if you had a large number of call records stored. That used to happen because of the flat xml file database we used earlier. Now we have moved to sqlite database. So once all your files are migrated, the next startup will be very fast.
Please update now. And please send us your feedback on the UI changes.
Update: Here’s a detailed post on the technology behind the browser based UI. Have a look if you have questions regarding it.
A big thanks to Thej for mentioning Call Graph on his blog. Check out his podcast.
This podcast was recorded on Skype with Call Graph!
We added a small new feature today: now you can specify a different association password than your account password. By default both the passwords are same. But there might be cases where you want it to be different eg. when your account is being used by several people for uploading. This password cannot be used for logging into the account, only to associate your machines with your account. So you can share this password with all of your team and be assured that noone will be able to mess around with the uploaded records. Very useful if you want to track and monitor your team.
To change the association password, go to the settings page and specify a new password. And then associate your clients with the account once more. If any client uses the old password, then the uploads will start failing. Note that this will happen only if the association password is different from the account password. So if you do not change it then you are okay.
A brief note on passwords by the way. There was this news article sometime back; a rouge admin changing the password of a user because he did not like it. The bigger mistake here is that the passwords are stored in plain text which enables the admin to see what the passwords are. But in our system, its hashed. Even if we want to know what your password is, we cannot. We see only the string of characters which cannot be decoded back. So you can be sure that your passwords are safe with us. 🙂
Please let us know what you think of this feature. Comments/feedback are welcome.
The echo/lag issues with Call Graph has been resolved in version 184.108.40.206. Please download it here.
The changelog for version 220.127.116.11 is as follows.
A new option, pause recording was added to the popup menu. It gets enabled when a recording is in progress and can be used to temporarily pause the recording during any call. Its functionally equivalent to the pause recording on the toolbar. Thanks to Chris for suggesting this feature.
The toolbar is now displayed whenever the Call Graph system tray icon is clicked.
Upload and download progress functionality was added in this release. The percentages are now displayed on the tooltip of the Call Graph system tray icon as well as the toolbar status when its in progress.
A warning message is displayed if during exit, if a call record upload is in progress.
A bug which prevented records which had apostrophe’s in its name or path from being played was fixed. Thanks to Johnathan for reporting this issue.
Several more minor fixes and changes. Please update now.
Revamp of the History UI, faster startup if you have large number of call records. Stay tuned.
Thanks for using Call Graph once again and please keep the feedback coming in.