• Gadu-Gadu PRPL improvements by Tomasz Wasilczyk, mentored by Ethan Blanton
• Plugin website by Nikhil Bafna, mentored by Kevin Stange
• Usage stats collection by Sanket Agarwal, mentored by Eion Robb
• libpurple on Android by Michael Zangl, mentored by Mark Doliner

It’s always difficult to narrow down so many great applications into just a handful, and we want to thank everyone who applied. The coding period runs from May 21 through August 24. If you want to follow the progress of the four students, they’ll be providing periodic status updates to our devel mailing list throughout the summer.

Read Google’s official announcement here.

How much can you accomplish in a single summer? Quite a lot. To give you an idea, here’s a list of some of our heftier projects of past years:

• SSL certificate verification and management
• Voice and video chat for XMPP
• The Bonjour protocol plugin
• The MySpace protocol plugin
• The SIMPLE protocol plugin
• Finch (command-line based IM client based on libpurple)

Details

• Get inspired by our ideas list. But don’t limit yourself to those ideas—we love when students propose their own projects.
• The application period starts March 26 and ends April 6th (full timeline)
• Once the application period opens, apply here
• We’re guessing we’ll request slots for 3 students this year.
• If IM isn’t your thing but you still want to participate, check out the list of other great organizations

My tool attempts to do some really basic sanity checks and warns if it sees problems. If you think of something that it should check for but currently does not, please let me know! And please let me know if you notice any problems or have other suggestions.

Why not? The short answer is that I didn’t feel we had enough developers willing to mentor students for it to be worthwhile.

The long answer is a little more complicated. I feel very lucky that Pidgin has been able to participate in GSoC for the previous 6 years. GSoC is an amazing program and it gives me a warm feeling that Google has consistently funded it, and I hope they continue long into the future. I think I’m a better person for having mentored some students and for having been our organization administrator a few years.

Pidgin has certainly benefited. Heck, Finch itself was a GSoC student project. And the developer went on to be an integral part of our development team. Other benefits: Our UPnP implementation for peer to peer connections. SIP/SIMPLE/STUN. A D-Bus interface. Performance improvements. MSN, ICQ and Yahoo! maintenance. The MySpace protocol plugin. Our certificate manager.

But mentoring students does take time. Five hours per week per student is a reasonable approximation. Some students need less guidance. Some students are so productive they need more help, having their code reviewed, getting feedback on implementation ideas, etc. Reading through and ranking all the student applications takes time. There’s also a mid-term and final evaluation survey that must be filled out. The time required for all this isn’t particularly unreasonable, but many of us developers have very little time to start with.

I tried to get a verbal commitment from some developers this year on whether they’d be able to mentor and the response was pretty limited. In general people expect to be pretty busy this year, and it didn’t seem appropriate for us to commit to GSoC when we may not be able to give our students the level of attention they deserve.

And so it is with a sad heart that I decided not to submit our application this year. It seems likely we’ll apply again in 2012. Also, please don’t get the idea that we don’t want contributions—we love patches and new contributors!

If you’re typing information that you consider private (typing your SSN or typing a password, especially for webmail or your bank), use this checklist:

1. Go to the login page (the page that asks you to type your password), but don’t type anything yet!
2. Look at the address bar at the top of your web browser.
3. Inspect the web page address and make sure it’s correct. For example, if you’re logging into Bank of America’s website then the address should be https://www.bankofamerica.com/ and not https://www.bankofamerica.youcantrustus.com/ and not https://www.bankofamerica.com@3468664375/ (the difference between these is subtle, but extremely important)
4. There should either be blue or green text, and/or a blue or green background in the address bar. Sometimes your browser will even show you the name of the company who operates the website; this gives you an extra level of trust.
5. There should not be a red X, a broken lock, a black slash, a yellow caution triangle, etc.

That’s it. Beyond that you’re trusting that the owner of the website you’re using knows what they’re doing and is competent.

Introduction

I recently wondered how hard it is to perform a man-in-the-middle attack. The login forms for Facebook, Twitter, Pandora and countless others submit login credentials using HTTPS, however, the forms themselves are served using HTTP (by default, anyway—many web sites allow users to choose an HTTPS login form).

The theoretical danger with a man-in-the-middle attack is that a malicious user could alter the content of web pages as they’re sent down to your computer. Login forms could be changed to submit credentials insecurely, thereby exposing your username and password. But just how feasible is it?

Step 1 – Trick the Victim’s Computer Into Routing Traffic Through Your Computer

This turned out to be much easier than I was expecting. I used a program called Ettercap¹, but there are other options. It has a GUI. I scanned my local network, picked out the IP of some poor sod (actually just another one of my computers), and chose the ARP poisoning option. Boom, all of poor sod’s internet traffic was being routed through my computer.

Step 2 – Serve the Victim An Altered Login Page

One way to accomplish this is to use DNS spoofing to make the victim think the attacker’s computer is “www.example.com”². Then run a web server on the attacker’s computer that serves content that looks like www.example.com, but behaves maliciously. Ettercap has a plugin that makes DNS spoofing easy. I played around with it and it works quite well. However, I didn’t want to bother with installing a web server on my computer or recreating www.example.com.

I wanted to do something a bit more elegant. I wanted to alter the web page on the fly, as it transferred through my computer on the way to the victim’s computer. Again, Ettercap makes this easy. It supports simple, text-based filters that allow you to search and replace any data on any port. I wrote a filter that 1) changes the login page of www.example.com so that the form is POSTed over HTTP and 2) saves the form submission to a text file³.

I cleared the web browser cache on the victim’s computer (to ensure I was using the altered login page), browsed to http://www.example.com/, logged in, checked the attacker’s computer, and indeed, my username and password were captured to a text file. Harrowing!

Firesheep

There’s been a fair amount of hubbub recently about Firesheep. It’s a point and click interface for session hijacking popular websites. It uses passive listening to capture network traffic from other computers on the network. It looks for session information for various websites, displays a list of discovered identities, and allows the user to impersonate a discovered identity by double-clicking on the victim’s name.

So that’s scary, but mostly just an annoyance. The potential for a criminal to benefit from Firesheep is limited—web sites that matter, like banks, tend to be more responsible and use HTTPS for all traffic. Want to know what really scares me?

Point and click Man-in-the-Middle

It’s easy for me to imagine a program that sits quietly on a network, performing man-in-the-middle attacks on users who visit websites for banks, investment firms, webmail. It could proxy all web pages, rewriting HTTPS links to HTTP. If the user wasn’t watching for the “HTTPS” indicator on their browser’s address bar, they’d be none the wiser. I don’t think it would take long for someone to collect credentials for a few hundred bank or email accounts.

Then what? I don’t know. Maybe ACH transfer money to a single account and withdraw? They’d track down the account owner. You’d have to run and hide. An entertaining prank might be to transfer a ton of money to a single account (not yours). They’d certainly have a hard time explaining that one.

I think it’s only a matter of time before this happens. Protect yourself: always look for the green or blue HTTPS indicators on your browser’s address bar anytime you’re doing something sensitive.

It’s possible to translate software using Amazon Mechanical Turk, but it’s not ideal.

What is Amazon Mechanical Turk?

It’s a web site run by Amazon (yes, the shopping company). Anyone can create an account and post some questions or a set of tasks. You agree to pay a certain amount for each completed task. Then someone else finds your task in the list, decides it’s worth their time, and does whatever is requested.

The tasks could be anything. Here’s an example that’s well-suited to Mechanical Turk: “Draw bounding boxes around objects in images — Draw a box around counter: table consisting of a horizontal surface over which business is transacted.” And then there is a picture of a kitchen and you’re supposed to draw an outline around the counter.

It’s a pretty cool concept.

What I Did

Late last year I decided that I wanted to try translating software (often described as “localizing”) using Mechanical Turk. I chose to translate Meebo’s Android IM application into Spanish. The application is written in a way that allows it to be localized: Individual chunks of text (usually called “strings”) exist in a single xml file. The source code of the application references this xml file whenever it needs to show a string to the user.

I posted each string to Mechanical Turk as a separate task. I offered $0.10 for short strings and $0.20 for longer strings. To attempt to increase the quality of the results I specified that shorter strings should be translated by 3 different people and longer strings should be translated by 5 different people. That way I could verify that everyone gave the same response, and pick and choose between different phrasing and word choice.

It worked, but I don’t have a high degree of confidence in the translation. I ended up having to use an online English-Spanish dictionary, Google Translate, and my own rusty knowledge of Spanish to decide between different versions of strings. I’m sure I didn’t do justice to my high school Spanish teachers, and I’m sure the result isn’t perfect.

Lessons Learned

• It’s easy to translate text poorly. It’s hard to translate text well. It’s an art. There are many subtle nuances in each word choice, and it’s very difficult to preserve those when translating to another language. And translating computer text is usually different than translating a book.
• Translators do a better job with context. For example, should the word “login” be translated as a noun or a verb? Should “sign in” mean that you’re connecting to another computer, or that you’re writing your name on a sign-in sheet at a bridal show?
• Having the same person translate all strings will provide better consistency between the strings.

Better Options

• If you can afford it, pay a professional software translation team. Professionals know what verb tenses to use for buttons versus menu titles versus dialog titles, etc. You’ll have better consistency if you have just one or two people translate an entire language.
• Have your users translate for you. If you’re a popular open source project this will work well. The translators may or may not be as talented as a professional who translates software for a living, but if they’re users of the software then they’ll be self-motivated to translate it, and will hopefully maintain the translation into the future.
• Have your translators create a glossary of words commonly used in your application (“username,” “e-mail,” “buddy”) and translate this glossary first. That way current and future translators can reference this glossary and maintain consistency across their translations.

Originally the project set out to create a $100 laptop (that may have even been the original name of the project?). They did manage to create a functional laptop with quite impressive educational software, but the cost for the laptop remains $200. Recently the founder of the project, Nicholas Negroponte, announced plans for a $75 tablet computer with a 9″ touch screen. The touch screen would also be a dual-mode display, which can function like the Amazon Kindle and use little power in well-lit environments, or can be backlit like traditional LCD screens. Not only that, Negroponte hopes that the screen will be constructed of some sort of ultra-durable plastic rather than glass.

My question: Is this guy crazy? Granted OLPC paved the way for our current netbook market. But I don’t think the touch screen he describes has been done before. That’s a lot of features to pack into an inexpensive device… I don’t know, I don’t think it’s going to happen. Not at $75, anyway.

This reminds me of a few years ago when Negroponte made an effort to use Windows on the XO instead of Linux. Many of the developers behind the project disagreed with him. There is a great summary of the events (and the OLPC and Sugar projects) here. Negroponte may be a driving force behind the project, but he doesn’t seem to be 100% grounded in reality.

One of the stronger use cases in my mind is:

1. You’re logged into Facebook, but you never use Twitter
2. You read a news article on newsobserver.com
3. The News & Observer website could intelligently decide to show you a “share this on Facebook” button (because you use Facebook), and could decide not to show you a “Tweet This” button (because you don’t use Twitter)

The specification allows more flexibility than that. Website operators decide what information to share, and users are able to opt-out entirely.

More information:

• Meebo XAuth demo page (click “Visit Demo Page” for Google and log in–notice how meebo.com now knows that you have a Google account)
• Official XAuth website
• Long explanation video from Meebo’s CEO
• Meebo blog announcement
• Meebo press release

Press:

• Wired article
• Mashable article
• TechCrunch article
• VentureBeat article
• Google Code blog post
• Google Social web blog post
• Yahoo! Developer Network blog post

As IM protocols go, OSCAR is actually quite decent. Flexible, extensible, reasonably concise. Could maybe be simpler.

Background

AOL’s history with public access to their IM network has had its ups and downs.

• In 1998 a few AOL employees released a GPLv2-licensed IM program called ‘TiK.’
• Sometime in 1999 this project was abandoned by the AOL employees. Some non-AOL employees created a TiK project on SourceForge and continued development.
• Things were good.
• In 2001 AOL made changes to their protocol in an attempt to block unofficial clients. Some people believe these changes were made to block Jabber<–>AIM transports, and that Pidgin (named ‘Gaim’ at the time) got caught in the crossfire. Pidgin developers were able to keep the program working for the most part, and AOL relaxed their efforts to block unofficial clients.
• Things were good again.
• In 2008 AOL announced Open AIM. Open AIM was a lot of things: A set of SDKs for interfacing with AIM and the AIM servers. Documentation for the OSCAR protocol. A forum for users to ask questions.
• Things were great… for a time.

Recent Changes

Sometime in January, February or March of this year AOL decided to shut down the Open AIM program. No more SDKs, no more protocol documentation, and no more developer outreach.

More specifically, the OSCAR documentation provided by AOL described a method of authentication (using a “startOSCARSession” API request) that required the use of a developer application key. The current Open AIM website implies that new keys cannot be created.

Now What?

Does this mean the use of startOSCARSession is deprecated? If so, what auth scheme should we use, instead? Should we go back to BUCP, the authentication scheme used by AIM 5.9? Should we try to reverse engineer the authentication scheme used by current version of AIM? Should we go back to masquerading as the official AIM client and stop politely identifying ourselves as ‘Pidgin’?

To quote the great Yoda, “the shroud of the dark side has fallen.”