Hari's Corner

Everybody who uses any kind of web application has come across some kind of login situation or the other. Whether you are accessing an e-mail account or a social networking site, a discussion forum or any other personalized web service you usually log in with a unique user name and password.

Generally web developers are very keen on encrypting passwords and other sensitive information on the server itself, so that any compromise on the database does not lead to a leak of such data. But what developers cannot guard against is attacks against the HTTP protocol itself, which transmits everything as plain text, even an encrypted hash. So a security conscious web developer who encrypts every bit of information his application collects from the end user will still not be 100% safe against crackers.

The problem is that even if you encrypt passwords at the server side and make sure that the client side also encrypts the same password before submitting it to the back end script (using client side scripting, for instance), the hash itself can be stolen because HTTP transfers the hash as plain text.

Consider the sequence of events in such a case to allow for better understanding of how this problem is acute, especially with user authentication using passwords:

1. Server expects password in encrypted form sent over HTTP.
2. A genuine client does the encryption using JavaScript and then submits the password
3. Somebody steals this "hash" by listening to the HTTP packets over the network.
4. This cracker realizes that the password is a hash by studying its contents. By disabling JavaScript on his client-side, the cracker easily bypasses the security measure and uses the hash itself as the password. The server, expecting that, allows the login.
5. The user gets compromised even if the hash cannot be decrypted because the server expects the hash.

Even if the client does not encrypt, the problem remains. Basically it is the problem of the protocol itself, not the web application. So it cannot be solved by the web programmer himself. That much is obvious to everybody.

So as far as I am concerned, I think that HTTP will slowly fade away and HTTPS will become more and more in use in the near future even for websites that don't necessary deal with monetary transactions.

There's a very simple trick to run X apps as root. We know the usual problem when you try to run an X application from a root terminal; we get a message similar to the one below:

[application]: cannot connect to X server :0.0

So instead of jumping all kinds of hoops, just run the application by calling kdesu (if you're running KDE), gksu or sux (if you're running GNOME/GTK) from a non-root terminal (for instance, to run the KDE package manager as root):

$kdesu kpackage

This is a very simple trick and does not require any hacking into your X or shell configuration files, and worth remembering if you ever need to run any X window application as root when you are logged in as a normal user.

At present, we are plagued by bad/very slow internet connectivity all over India and some parts of Asia. At least, I believe this to be the case. I cannot even offer you a link to the relevant news item online as I am stumped without google access.

As of now, I have no (or extremely slow) access to several websites, but strangely (luckily) I have access to this blog and literaryforums.org.

Hopefully the problem, whatever it is, will be fixed soon. Slow internet connectivity is something I'm not used to of late, but I still remember the days of dial-up networking, and the frustrations of occasional disconnections.

Well, if you want to set up a simple video editing and post-production studio with Linux for non-professional use, here's a list of all you need.

Mencoder/MPlayer - probably the best known FOSS media suite, this is your best bet when it comes to post-processing/converting/enhancing and playing back your video files and putting them together. With Mencoder, you can not only convert between formats, you can also apply filters to videos to enhance visual quality. You might also consider using my Mencoder GUI, BiaMove to make things a tad easier.

DeVeDe - Create Video CDs and Video DVDs effortlessly from video files of any format with this simple GUI tool. You can also create simple DVD menus using this program and store the results in a BIN/CUE or ISO file.

Kdenlive - an advanced non-linear video editing front-end for KDE which might make it easier to put together a full-length movie from a series of video clips. You can even make a video slide show from still graphic images using this tool.

K3b - To burn your video CDs/DVDs to a disk to play on your home system or share with friends.

Hopefully this blog will gain a new direction in 2009. It seems as though I have lost a lot of steam during 2008 which showed up in the number of entries through the latter half of the year. I really haven't been much online in the last few months either and I apologize to my friends for not responding with my usual promptness to their mails/comments/communication recently.

In the meantime, whether you're a friend, a regular reader, an occasional reader or just an accidental visitor to this blog, I wish you a very happy and prosperous new year.

It's been a while since I've written a meaty article of this nature, but the thought has been in my mind for a while - ignoring all the legal and technical aspects of licensing and end-user benefits, is Open Source as it exists today really about improving software through quality feedback and user-contributed code? I know that the terms "Free Software" and "Open Source" have a wealth of history behind them. I also don't want to discuss the political philosophies of these movements. What I do want to discuss is whether the supposed software development model of the Open Source community is truly open to the cycle of development from the user community at large.

I've seen quite a few big FOSS projects that have simply stagnated over the years. I really haven't seen many major innovations. Yes - version numbers keep moving up and we do see a steady stream of minor updates, but as far as features are concerned, many FOSS projects seem to hit a plateau far too early in their development cycle. When a project gets a steady base of users after the initial period of development, it almost seems as though the programmers are committed only to fixed ideas and tend to become conservative and extremely cautious about innovating. They start worrying about upsetting their existing users if they make major changes.

Another side of the story is that the end users themselves tend to share this conservative thinking. I've also noticed that many of the big FOSS projects seem to have only a small base of users who are really interested in participating in the development process (by way of submitting bug reports, feature requests and testing out beta versions etc.)

This has more to do with the social phenomenon of group-think rather than actual technical issues. Once a FOSS project gains a "fan club" of core users, this core group seems to dominate the idea feedback loop which filters its way through to the project team. And in any case, most end users are either too lazy or too timid to provide feedback, let alone contribute code. Also this core fan club tends to silence any criticism or negative reactions pretty quickly in mailing lists and online forums. Whether the actual developers themselves form this core club or a small group of initial users take it upon themselves to defend their faith is open to question, but it's evident that most FOSS projects of reasonable size have these cliques who dominate the thinking pattern and lead to stagnation. Stability is one thing - but is stability the only goal of FOSS?

It's one thing to have a community of users - it's another to have active participation in the actual process of improving the software from one version to the next. It's also another thing to have the capability to fork a project from its roots and take it to another level - for most people this is simply unfeasible and unrealistic. It might be argued that the ultimate goal of FOSS is not innovation but simply freedom. But I would say that the freedom of the end-user is simply a myth if that end user cannot participate in a meaningful, practical way in the process of improvement.

In contrast, I've seen the smaller FOSS projects really explore obscure areas of programming. It would be interesting to study many of the smaller projects and analyze their levels of code quality. The larger projects tend to survive by their community power and popularity, but small projects depend solely on the sustained enthusiasm of its developers. And as small projects are often just a single programmer's leisure-time hobby, such projects tend to be limited in terms of scope and feature-richness. But within these small parameters, individual developers have the maximum freedom to innovate, be receptive to ideas and allow themselves to code for the joy of coding, without worrying too much about hurting their egos. Working on small ideas one at a time also seems to be a great way to produce results.

I've found the same to be true myself. Once I start over-generalizing ideas and look too far ahead, I start hitting road-blocks and meaningless abstractions. But when I focus purely on what I want to achieve at the moment and also think in terms of ideas, I write code faster, I focus on ideas and I get a better idea of what the result will be.

Maybe there is an optimal size for an FOSS project in terms of code-base, number of programmers and number of core users. Below that level, a project would simply not sustain itself in the long run. Far too many hobby projects are simply abandoned before completion. Above that level, the project would be probably become a victim of its own popularity and tend to stagnate for the reasons I've stated above. It is an interesting idea and probably worth exploring by those academically inclined.