I have been a Twitter user for nearly one year now. It has been an generally pleasant experience. Microblogging is now part of my array my information tools, which also include: RSS (through Google Reader), Email, IRC. A more complete post about own I see Twitter as useful is something I need to do eventually.

I have recently made my Twitter page protected due to the rampant increase in the prevalence of spamming on Twitter. Doing this has bought me peace of mind, but it is pretty unfortunate that Twitter privacy is an all-or-nothing option. If you want keep spammers away from your profile, you need to set your profile to protected and you have no other options. A protected account has the following restriction:

1. People that want to follow you need to be approved
2. Your tweets don’t appear on search.twitter.com
3. “@replies” to user not following you will not be seen
4. You cannot share direct links to your tweet with others

For Twitter outsiders, it is interesting to know that, on Twitter, spammers are not like the obscure, badly worded email that sometimes slip through your email spam filter. A mom an pop plumbing shop hunting potential clients using keywords on Twitter search is also considered to be spamming, admittedly to a lesser level. Some people will call this marketing but it’s a pretty thin line between that a really spamming, especially if the shop is located in the central US where it’s unlikely I’ll ever end up travelling.

The third limitation is what has annoyed me the most about protecting my profile. I follow several people that have good reasons not to follow me and yet I would like to sometimes directly address those persons. For this purpose, I had to create another unprotected account. This is not unpractical as long as your Twitter client supports multiple Twitter account.

It seems to me that those problems would not happen if the privacy options were more fine-grained. I don’t need the full protection of a protected profile, but there are some features of it I can’t live without. Here is how I would split the privacy options.

Visibility

This would determine if only followers can see your tweets. If the user decides that his tweets are private then its of course the should not be searchable.

Followability

It should be possible to screen people that want to follow you on Twitter. Most people I have seen using a protected profile will accept being followed by just any human being, and just the fact of making the profile protected puts it out of reach of majority of spammers.

I understand why this is a feature reserved to protected accounts: if your tweets are public and searchable, then whoever really wants to follow you can do it manually without adding you to their followers list. So, without making the profile private, this option is next to useless to protect keep your profile away from spammers.

Still, there is nothing keeping Twitter from making this feature available independently of private profile. Weeding out your Followers page of the many spammers that stitches to any unprotected profile is something know to all Twitter users and it’s not a fun task if you ever forget it for a few months.

Searchability

Some users might not want their profile to be found on search.twitter.com. I simply don’t need that level of privacy, but it’s not unconceivable that some particular users of Twitter would want to be of the public view.

@replies to you

This would determine if you want to messages directly addressed to you from users you don’t follow. Since Twitter already has a Block feature which does that on an user per user basis, this would be like automatically blocking all users.

This could be useful for star Twitter users with little tons of followers that want to limit who can address them. Most of those people probably don’t read all those tweets anyway, so why give people the illusion they can talk to them?

This of course would be of no use to me since there is just not enough people sending me tweets.

@replies to others

This would determine if want your @replies to be automatically public. This would allow you to communicate with people You want.

This is of particular interest with low-rank Twitter user like me who just want to send messages to Twitter microcelebrities that have few enough fan to read what they say to them and that sometimes might even reply.

Findability

Since we are into adding privacy levels, why not put that in too? Some users might not want to be found using the Twitter “Search User” feature. A privacy setting could be added to disable that.

I’m proposing this just because I thought of it… The Twitter Search User page is pretty crappy and already ensure a base level of privacy which suits me fine.

Explicitely public tweets?

I think most of the problems I have with Twitter privacy settings would be solved if tweets could be made public on an individual basis. It would then be possible to address directly people that don’t follow you and take part in your favorite meme without leaving the comfy cloak of your protected account.

I must say that I have not checked what other microblogging platforms, like Jaiku and identi.ca have to offer. I admit that what I’m suggesting in this post might already exists somewhere else.

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.