So Skype is evil because it’s proprietary?

It’s not hard to find rumors about spyware being deployed with the Skype VOIP software. What is hard to find amongst those rumors are concrete facts. Most of the rumors seems to be unsubstantiated, and some other are based on interpretation on the EULA of Skype. I won’t bother with the later case since legalese is not a language I speak.

This blog is one of the few blog around that take seem to take the matter seriously and brings forward something looking like a real proof that Skype may be stepping over the boundary of user privacy.

For the people who don’t read french, I will summarize the article. The author’s hypothesis is that when a new profile is registered through the Skype desktop client, the software accesses bookmarks stored in the user’s Mozilla Firefox profile. Since it’s not immediately obvious why Skype needs to be doing that, he concludes that the Skype software must be sending that information home for data warehousing, or some other shady practices.

For proof he shows his data that he obtained using the strace command on Linux. strace is a lovely, lovely utility I’ve learned to master in the last few years. It is an utility which shows the system calls that are used by a Linux application. strace is not hard to use but its output can be very voluminous and difficult to decipher. This is not the case here.

…Naaah

The data he obtained looked inoffensive to my eyes just 2 seconds after examining it (I won’t claim I’m the first that saw that: several commenter have pointed it to him).

The blogger singles out several calls to stat64(), which is a system call returns information about a file like its size and last modifications or last access date.

[pid 23964] stat64("home/phil/.mozilla/firefox/bstiq480.default/bookmarkbackups/bookmarks-2008-12-17.json", {st_mode=S_IFREG|0600, st_size=41718, ...}) = 0
[pid 23964] stat64("/home/phil/.mozilla/firefox/bstiq480.default/bookmarkbackups/bookmarks-2008-12-20.json";, {st_mode=S_IFREG|0600, st_size=42052, ...}) = 0

An higher level view of the data shows that Skype actually calls stat64() on all files on the the Mozilla profile of the user, and call open() on the directories he finds, then call getdents() to obtain the list of entries in that directory and so on…. Like any software recursively scanning the filesystem would do. The scan in the profile is stopped at the moment the software finds the user preference file.

This is easily explainable: Skype tries to install a FireFox plugin. It seems the Windows version has an option in the installer to disable that plugin but I have not found the same option in the Skype package.

So, Skype does search inside the user’s Firefox profile, but the only thing he does with the result it obtains is the installation of a plugin for the user’s convenience. It’s not even useful to search the place where it might be sending data since there is no data to send other that what it gathered through its registration wizard.

The final nail can be driven in the coffin on this theory by simple listing all the files opened by Skype during registration. None of the files contain personal information. You can see list of opened files I have extracted from the strace output at the end of this post.

Not evil on an evil operating system either…

Those results have been independently confirmed on Windows by DrFrakenstein, a twitterful, but blogless Code Ninja. He used Process Monitor and confirmed me roughly the same behavior but targeted at Internet Explorer.

So, probably not evil…

I can’t conclude this post by saying that Skype doesn’t include spyware. I simply spent one hour examining very limited data on the activity of the software during registration. Yet, I’m confident enough about my result to keep recommending its use to my family. Use Free alternatives such as Ekiga if you give high important to software freedom. It’s a opinion I respect. Just make sure you have something better that crappy strace analysis before dissing good but proprietary software.

See for yourself…

Here are the data I have obtained by running strace during Skype account creation server.

• Skype strace output
• Skype opened files

Since I love some good shell-one-liner action, here is the command that extracts the list of opened files from the strace data.

grep open skype.trace | perl -ne '/\"(.*)\"/ && print $1."\n";' | sort | uniq

On life right now

Oh boy, I’m dead tired.

Christmas vacations are closing in. Tomorrow my girlfriend, my daughter and I are going to see our parents and grand-parents which live a little east from where I live. It’s a three hour drive, a short trip, but we plan to stay 10 days. Parents will know that this require to pack-in a lot of stuff, mostly for the baby.

I find it ironic that a 12 pound baby requires to carry as much stuff as two grown adults. And that’s just “life support”. We don’t carry much extra things around.

Luckily my girlfriend is better than me at organizing, otherwise we would end up with pretty much everything missing.

It’s unlikely you will see technical post here until I get back.

Projects

I have not had time to think much about the idea I was to write about some posts ago. My goal is to keep this blog on a technical blog, so I will try to summarize that idea here instead of waiting to have time for a bigger post.

I have started playing around with the little known ptrace syscall on Linux. My idea is to code a programmable variant of strace.

strace is a tool that allows you to see what system calls a program do on the Linux kernel. System calls are the functions in the kernel that can be used by the user program to do things. You might already know that it’s not the GNU Libc that write on the disk. The kernel does. The libc, and other libraries, uses system calls to tell the kernel to write on the disk. That means if you know what system calls a program use, you get a pretty good idea what it is doing.

That’s strace, in short. I could write a whole article with example and such but I’m sure there are better writes that already did so go it Google.

Since I’ve started coding under Linux, I’ve always found strace to be one of the most useful development tool available. It’s actually useful beyond programming tasks. I have used it more than often to get more useful error message from malfunctioning programs.

What annoys me with strace though, is that it’s sometimes very painful to extricate information from the thousands of calls done by a program. There is a lot of noise in a strace output.

With a programmable strace, I would like to be able to intercept just the information what I want, and do the interpretation of the data programmatically.

The most striking example of what I think is to track file descriptor leak. There are few system calls out there that return file descriptors. File descriptors are a limited resources to the process, and if they run out, the process will probably cease working.

Determining that file descriptor leak happen is easy. All you have to do is count the number of files in /proc/pid/fd.

Finding what is leaked, what it was used for and in what circumstance the file descriptor is leaked might be more complex. That is usually something I manage to accomplish with strace.

It would be faster to write a small program in an high-level language that could trap the system calls that return file descriptors and log what happens.

That’s the idea that made me think about that project. That and the fact that it would be fun to code that.

What I need to investigate further is if I can do more than simply spy the program. If you can change return values of system calls, you can submit programs to a lot of strange error conditions. It would be easy to simulate a full hard-drive, for example, without needing to patch the GNU Libc. All that would be needed is a short program telling what to return when a child program calls the write system call.

That text is probably confusing as hell to users, and non-developers. Don’t worry. If I find the idea implementable and useful, and if the projects takes off, I will certainly blog about it again.