Aug 29, 2008

Keepin' it short

I am wondering how should I write this blog. For example previous post about false sense of security was supposed to be a longer rant originally. In the end I shortened it considerably and focused on Perspectives. Why?

Well the main reason is, that I realized that there are a lot of essays/rants about perception of security. Maybe I could write a really good essay if I took some time to think it through. But if you are interested in privacy or security then you already know all these things. And if you are just another ordinary computer user who does not care if his email account gets cracked, my blog will not change that.

Actually Jeff Atwood wrote some time ago about unreachable type of software engineers (or for that matter any professionals). Paragraph that completely describes my feelings is this one:
The problem isn't the other 80%. The problem is that we're stuck inside our own insular little 20% world, and we forget that there's a very large group of programmers we have almost no influence over. Very little we do will make any difference outside our relatively small group. The problem, as I obviously failed to make clear in the post, is figuring out how to reach the unreachable. That's how you make lasting and permanent changes in the craft of software development. Not by catering to the elite-- these people take care of themselves-- but by reaching out to the majority of everyday programmers.

Writing for the masses is not easy, and I don't think I'm up to it. Yet. It makes me angry that not everyone loves his job or profession, but I cannot change that. So I will keep writing about my passions the way I see fit and hopefully one day, I will become good enough software engineer and writer in one person, that I will be able to influence the 80%.

Note: If you are wondering what's up with 80% - 20% thing, then I recommend article by Ben Collins-Sussman about two types of programmers

Share/Save/Bookmark
Aug 28, 2008

Lack of security is not a problem

False sense of security is. As Dan Kaminsky pointed out recently, there have been numerous BIG security problems with fundamental Internet services. All of them undermine basic principles on which Internet is based: routing or DNS.

Can we trust the other side? How can we know that we are "talking" to the same computer as few days ago? This question is usually answered by encryption of communication and authentication through SSL (https). Most websites use self-signed certificates, but these provide only encryption, not authentication. There are quite a few good examples of security pitfalls of self-signed certificates.

Recently I also managed to stumble on nice Firefox extension called Perspectives. Usually only your browser checks security certificate of https server you are connecting to. If attacker takes over path between you and destination server, trying to execute MITM attack, Perspectives would detect this and warn you. It would even warn you if the certificate changed recently. This makes even self-signed certificates somehow more secure. Without Perspectives you could be easily lured in a den of wolves. For more in-depth explanation on how Perspectives works, see original publication.

The basic principle still stands. You are most vulnerable, when you don't expect an attack. In other words:
Little paranoia never hurts
So next time you see a warning about invalid/outdated/self-signed certificate, don't accept it without thinking about consequences.

Share/Save/Bookmark
Aug 26, 2008

Strong passwords suck, but they don't have to

Amrit Williams wrote a nice piece on sucking passwords. But as Martin McKeay pointed out Amrit didn't provide any real solutions except maybe using passphrases. Passwords are gate to online existence of most people. Most people know that there are certain rules for creating strong passwords (at least I hope so). But only a handful of people use really secure passwords. Moreover you should have different passwords for every program/email account/social networking site/etc. Why? So that when one account becomes compromised (by whatever means), others will stay safe.

You can find a lot of rules for chosing good passwords all around Internet. There is only one problem with them. If we would like to really follow all the rules, most of us would end up with 20+ passwords, every one longer than 8 characters, most of them without any meaning. Good luck with remembering them. But hey! We are in computer age, we don't have to remember stuff anymore right? Why not use a decent password manager? Then you have to remember only one password (but it better be REALLY secure).

This approach creates one more problem for us though. Mobility of our passwords. You want to access website x.y.com? I hope you have your password manager with database at hand. Otherwise you're screwed. I see two solutions:
  • If you use some kind of UNIX-like system, and you have a public IP, you could use command-line password manager to access your passwords from anywhere.
  • Carry your password manager with your database around.
I like the second method more because you don't have to worry about firewalls, proxys and similar stuff.

Recently I found out about PortableApps. It's a set of open source applications designed to be run from USB thumb drive without leaving anything behind after you close them. No registry changes, no temporary files etc. One of applications offered is KeePass Password Safe. It uses AES encryption to securely encrypt database of passwords. This Windows-only set of applications provides means to have strong, unique passwords that you can carry around with you. So what are you waiting for? Make them unique!

Note: I tend to use gpass password manager (Unix-only, but I usually have access to my machine) and I remember most important passwords by heart. I'll probably migrate to some other multiplatform solution soon (maybe PasswordSafe?)

Note2: Apparently there is similar (or even better) software for MacOS X (1Password) I haven't tried it though.

Share/Save/Bookmark
Aug 23, 2008

Developer isolation

I recently stumbled upon blog post about TraceMonkey (thanks to Sisken). TraceMonkey is codename for new improvments to SpiderMonkey (Firefox Javascript engine). Results are very impressive, with speedups ranging from 2x to more than 20x. I love Firefox and I'm looking forward to every new version bringing more exciting features. But what struck me most in the post was this statement:
I fully expect to see more, massive, projects being written in JavaScript. Projects that expect the performance gains that we're starting to see. Applications that are number-heavy (like image manipulation) or object-heavy (like relational object structures).
Now don't get me wrong. I get excited about new features just as much as every other geek :). I see a problem here though. Firefox is biting more of market share pie every month. But however we put it, it's still at most at 30% in some parts of Europe (US is dominated even more by IE). So how can Firefox create incentive for developers to create web applications for ONE specific browser? Sure, few years from now Javascript performance will be much better in other browsers too. What until then? You think that "Sorry, this site was designed for Firefox 3.1 or higher" is any better then "Sorry, this site was designed for Internet Explorer 5.0 or higher"?

You may ask "What about in-house applications, for one company?". In-house applications are already dominated by IE and ActiveX. That's not gonna change overnight. Or maybe I'm wrong.

GDevs (Geeky Developers) are rightly proud of their creations. The problem is when they fail to see the surrounding world. Now almost famous blog post from Ben Collins-Sussman about two types of programmers contains this pearl:

Shocking statement #1: Most of the software industry is made up of 80% programmers. Yes, most of the world is small Windows development shops, or small firms hiring internal programmers. Most companies have a few 20% folks, and they’re usually the ones lobbying against pointy-haired bosses to change policies, or upgrade tools, or to use a sane version-control system.

Shocking statement #2: Most alpha-geeks forget about shocking statement #1. People who work on open source software, participate in passionate cryptography arguments on Slashdot, and download the latest GIT releases are extremely likely to lose sight of the fact that “the 80%” exists at all. They get all excited about the latest Linux distro or AJAX toolkit or distributed SCM system, spend all weekend on it, blog about it… and then are confounded about why they can’t get their office to start using it.

Fortunately for OpenSource community, people like John Resig, Andreas Gal, Mike Shaver, and Brendan Eich are in the 20% crowd. Let's just hope they won't lose sight of the rest of us :)
Share/Save/Bookmark
Aug 19, 2008

How to change author of git commit?


I recently needed to rewrite history of commits in a private
Git repository, because I wanted to change my email address in every commit. Note that you should not try following tip in a repository that anyone has pulled from. Normally Git doesn't allow you to do this kind of thing, since changing authorship is...well bad (usually also against the law).

Let's assume that email address changed from dev@comp1.com to dev@comp2.com. To create copy of repository $PROJECT_DIR to new repository $NEW_REPO with changed emails we can do following:

$ cd $PROJECT_DIR # change to project repository

$ git fast-export --all > /tmp/project.git # export repository to temporary file

$ sed 's/^author\(.*\)<dev@comp1.com>/author\1<dev@comp2.com>/' /tmp/project.git # replace emails on every line starting with 'author'

$ cd $NEW_REPO # change to empty directory

$ git init # initialize git

$ git fast-import < /tmp/project.git # import modified repository

Third step is potentially dangerous, because you have to make sure that you don't edit contents of any file aside from metadata. If you change content of files, git fast-import will complain because sha1 hash will not be correct.

Be sure to read git fast-import and git fast-export man pages for additional information. It took me a while playing with git-rebase and similar stuff to realize that they do not offer such feature, so if this tip helps anyone else I'll be glad.
Share/Save/Bookmark

Picasa Album Downloader roadmap

In my first post about Picasa Album Downloader java applet I promised more in-depth technical information about the project.

Project idea came when few of my less computer savvy friends wanted to download all photos from my Picasa Web Album. So far there have been few different ways to do that:
  • install Picasa and use it,
  • install some other software to download photos,
  • go photo-by-photo and download them one-by-one.
None of those methods is very user friendly. Why isn't there a "Download album as zip archive" link on Picasa? I have a few theories, but that's probably for another blog post :)

Question is: How to enable users to download Picasa albums easily? Apparently I was not the only one with the idea of creating web service to create zip file for users to download. Fortunately Google provides APIs for most of its services in few languages. More precisely you can access Picasa easily using:
  • .NET
  • Java
  • PHP
  • Python
Since I started learning Python step-by-step few months ago, I thought about using it for the job. Then I realized that I will need hosting for the web service. There are not too many free python hosting services. Those that are free usually have some restrictions.

Even Google provides hosting services using its own App Engine, with support for Python in particular. I created simple prototype python script that was able to download selected album from given user to the chosen output directory. It ran just fine when I was testing it, but stopped working when run inside dev_appserver.py. Reason? Hotlinking.

Picasa Web Album checks referer header and if it doesn't match one of Google domains, Picasa blocks access to the images. Since App Engine dosn't allow clearing of referer header, this effectively blocks using full scale images from Picasa in App Engine. So python is out. What else is there?

I don't have much experience with .NET, and I also don't think that it would be suitable for web application that is supposed to be free. I already had some experience with PHP and for project like this one, it would probably do the job just fine. There was a problem though...Google Data APIs needs at least PHP 5.14 to work, but hosting services I had at my disposal had lower versions installed.

Status? Python, .NET, PHP, Java. And here we are. The result is a Java applet that enables users to download full Picasa album without installing any software. There is also a project page at Google Code. First version took about 1 day to code. I released it under GPLv3, so if you want to contribute, you are welcome to do so. If you find any bugs or have ideas how to make the applet better, let me know.

Share/Save/Bookmark
Aug 14, 2008

Picasa Album Download

Picasa web albums is a great service. As far as I can tell it has very few disadvantages over competing websites. Although I have never used Flickr or similar services so I am not really one to judge.

There is one thing with Picasa web albums that quite a few people have asked me:
Can I download whole album from Picasa at once, without having to click through all the photos one-by-one?
Well I used to tell people to install Picasa to their computer, but less tech-savvy users had problems with this approach. Some companies also have restrictions on installing software in their networks. No wonder with numbers of trojans, malware and similar things on the Internet these days. Getting rid of them can take forever...

I found quite a few projects dealing with downloading from picasa. All of them required installing some application (or at least download one). Perfect solution? Web service.

As an aspiring Software engineer (pun intended) I set up on a quest to solve this problem once and for all. Goal:
  • Download complete Picasa Web Album into computer without having to install anything first
  • Multiplatform (Windows, Linux, MacOS X,...) support. Ideally only browser-requiring solution.
Simple right? Well yes and no. I will publish technical details and solutions I tried in some other post (edit: I already did). Now. without further ado, I present to you:


Share/Save/Bookmark

Lorem ipsum?

I created this blog some time ago, but so far I did not create any posts. Why? Well I am reading a lot of blogs and the best ones are usually those that have certain criterias:
  • interesting content,
  • interesting form,
  • lot of interlinking to other sources of information,
and most importantly: they are updated regularly.

Can I do all of those things? Well, we'll see... If nothing else this will be nice to read in 20 or so years (If I manage to keep it up for at least a few months :) ) I will try to update this blog twice a week and we'll see how that goes.

Topics that I will most probably write about include:
I will most probably get a lot of ideas from other blogs that I read. If you just want to get an idea what I am interested in you can always look at my shared google reader feeds.

So long and thanks for all the fish.

P.S Oh yeah...one more thing. English is not my primary language so there may be occasional "hiccups". Sorry

Share/Save/Bookmark