All posts by Peter Mangiafico

How to protect yourself on open WiFi networks

If you have a portable device, like an iPhone, iPad, or laptop, you’ve probably used it at a free and open wifi spot. You’ve also probably used it to visit Facebook, Twitter, Evernote, or to read your email. Most of the time, you’ve probably been on non-encrypted pages – pages that don’t use the SSL protocol (and don’t display the traditional “lock” icon in the address bar, and use “http” instead of “https” in the URL). You probably don’t think about this too much, or if you do, you may think that since the login page was secure, your account is secure, even when on open and free wifi. Unfortunately, none of this is true for most sites. And the reason is pretty simple.

Once you log into a website, like Facebook for example, your web browser stores a piece of information: a unique token.  It uses this token each time you view another page to let Facebook know it’s you.  The problem is that when you request another page from Facebook, if the page is not encrypted, neither is your token.  Anyone who borrows your token becomes you for that session, without knowing your username and password.  This is especially easy to do when you are on open wifi network, and there is in fact easy to use software called Firesheep for this exact purpose – no hacker credentials required.

There are two solutions:

1. The first is for free wifi spots to require passwords to use their networks. This encrypts all traffic on their networks and prevents tools like Firesheep from working.  This still doesn’t protect you on shared networks that don’t encrypt data, but it’s a start.

2. A better solution is for websites like Facebook to encrypt all of their pages, not just the login page.  This encrypts your token along with all of the content and prevents anyone from borrowing it.  Fortunately some websites, including Facebook and Twitter, are now providing an options to do this (which of course, should just be the default).  For Twitter, look for the setting called “Always use HTTPS” (more details here).  For Facebook, look for the setting called “Secure Browsing” (more details here).  For the sake of privacy, let’s hope this becomes standard practice.

 

Organizational Entropy

Entropy is a measure of the energy in a system that is not available to do useful work, and the second law of thermodynamics states that the entropy in a closed system always increases.  Basically, in any system, the cruft builds up over time until it’s all you’ve got left.  This is a physics concept, but it can be easily applied to organizations, governments, companies, and just about any other collection of individuals (i.e. a “closed system”). Some examples:

  • Paying taxes requires accountants, lawyers, software applications, and a large number of government employees to maintain and enforce the rules.
  • Maintaining an existing software project can often take more programmers than building a new one. If you are a coder, how many times have you seen comments like this in a codebase: “// TODO: clean this up!”.
  • Companies have big binders filled with regulations and entire departments to manage and interpret them, while they work they do becomes less innovative over time.
  • Installing a game on your iPhone requires you to “read” 30 pages of terms and conditions first.

And so on.

So how does one battle the symptoms of organizational entropy?  The same way you battle any type of entropy: by increasing the amount of useful energy in a system through the removal of the junk .  You make a habit of regularly examining what you do and why you do it.  Don’t take anything for granted: “because that’s the way it’s done” is never a valid answer.  Question the motives and you may discover that the original reason for a rule, a regulation, or a piece of code no longer exists, and you need to change it, or even better, remove it.

Re-examine the tax code and clean it up every few years.  Take away the software and accountants and make members of Congress do their own taxes by hand.  Spend 20% of your coding time going back over modules and cleaning them up a piece at a time.  Put the HR managers or lawyers into a room, and have them read the handbook and defend each section’s existence.  Clean your garage and throw out stuff you haven’t used in the last year.  Not only does that reduce entropy, it even gives you extra space for that new bike.

My experience at the Google Summer of Code Mentor Summit

I attended the Google Summer of Code 2010 Mentor Summit this last weekend in Mountain View, and it was really fascinating and inspiring.  It was my first mentor summit, representing the Biodiversity Informatics Group of the Marine Biological Lab in Woods Hole, MA with my colleague Dima Mozzherin, and it was also my first ‘unconference’.  For those that haven’t been to an unconference, it is basically a meeting where the talks are not scheduled in advanced, but are instead determined by the attendees themselves.  The entire conference schedule is determined in one frenzied hour during the opening session, and it works remarkably well (at least for a meeting that had less than 300 people… a multi-thousand person conference might not work as well).  The mechanism for setting the schedule was decidedly low-tech: sharpies, sticky notes and dot stickers to vote for a session, along with a big board showing available rooms, so sessions can be load balanced.  To me this demonstrates the great thing about engineers: use the best tech for the job, even if it is paper and pen.  Anyway, the end result is a list of sessions that by definition attendees are interested in, all nicely balanced between rooms.

The quality of the meeting was really outstanding – it was like attending a top-notch IT conference, with a variety of expertise represented, ranging from software engineers, to software managers, and experts on IP and licensing.  The variety of sessions was equally wide and allowed us to explore a series of topics, including open-source social networking software, IPR issues, advanced trolling (!), and sessions on the Google Summer of Code program itself.  Some talks were obviously prepared in advanced, and some were more discussion like.  In each case, folks used the excellent Etherpad software to take real-time collaborative notes (often using a site called TypeWith.me that runs the open source code), which are all available on the conference wiki.

I held a session called “Liberate Your Data!” where we talked about ideas and strategies for bringing together data collected in diverse projects and formats into a single location (basically the goal of the Encyclopedia of Life).  We discussed strategies including creating plug-ins for Excel, using semantic markup technologies and the challenges of creating tools that work across domains, when the data ontologies and formats often vary widely between disciplines.

The meeting was held on the Google campus, which was quite nice.  I really like the idea of thinking of a workplace as a ‘campus’ instead of an office complex, since this promotes the notion of learning as well as doing.  Google fed us the whole weekend, and the food was pretty damn tasty.

One of the things I noted was that, like many IT and software get togethers, it was fairly male dominated.  I am not sure how to improve this situation.  The same imbalance also exists in various science fields, such as physics, while is quite equally balanced in others, such as biology.  It would be interesting to study what the root causes are.

Another thing I noted is the fact that engineers sometimes tend to be focused on elegant engineering or technical solutions to problems, while end-users are almost always focused on their experience with a system.  Most users don’t care if the code running their cell phone or computer is open source or closed source, they just want it to work all of the time and be easy to use.  For me, the iPhone is the prime example.  Not only is the OS not open-source, you can’t even (easily) install any application you want without it being approved by a single company.  It’s a very closed platform, and yet it is extremely popular (even many folks at the conference had one).  And the reason of course is that it is a great user experience.  I think it is important for any software developer to think about their end user and the user experience in general if the goal is to have a project that is widely used.

Anyway, the summit was not only a great way to meet new people, but was also a great way to learn about other open source projects, and Google should be commended for investing in programs such as this.  I’m looking forward to future years already.