Thu, 11 Feb 2010

Google and University email

Should universities switch away from hosting their own email and join the Google bandwagon?

Adi Kamdar wrote to the Students for Free Culture discussion mailing list linking us to a Yale Daily News article discussing an "almost-definite" switch for Yale to Google Apps for Education.

Adi asked for thoughts, so here are mine.

Privacy

One interesting thing about the Gmail option is that, when deployed for all students, students have no choice but to let Google read their official email.

Some students might take part in activism that they want to shield from Google, a corporation with its own interests, or the attackers that attempt to break into Google's systems (see the recent attacks from crafty pro-Chinese-government hacktivists). Before a switch to Gmail, each student could choose if Google was the kind of company they wanted to share their email with. After a switch to Google Apps, the choice is made for them.

But this highlights a different issue: Before a switch to Google, students have no choice but to let university administrators read their official email. That's not necessarily optimal, either. Others have pointed out in this thread that this option comes with legal advantages with regard to privacy law. At least that's some consolation.

It's still true that students can encrypt their email and make it difficult for any eavesdropper to figure out the bodies of their emails. But that's no use for hiding the identities of the people with whom they communicate -- no email crypto I know hides email addresses.

Software freedom and open standards

This is juxtaposed against another difficult situation: Matt Senate wrote about the sucky Squirrelmail system that Berkeley uses (used?) for webmail. The fact that SquirrelMail is Free Software is small consolation for Matt. From his perspective, because it's a hosted web application, he has no more freedom than he would have with Gmail.

At least Berkeley's IMAP server followed standards! That's more than we can say for the Gmail IMAP server, which is famous for basically supporting just enough IMAP for Microsoft Outlook to work.

But standards compliance is small consolation. If the university email server "properly" supports IMAP, but isn't fast or doesn't provide the new extensions that make threading or search speedy, it's not much relief to know that you can use any client you want to slowly read your email.

Internet history

Truth be told, University-hosted Internet services are based on what you might call the original Internet perspective. The Internet began as a network of networks. A University was a network island unto itself, running its own email, news, and Ethernet services. When inter-network connection was available, you can email people at other institutions. When it wasn't, well -- the Internet is a useful tool, but it's down right now. "Don't worry," the admins might tell you, "you can still read your email with PINE."

It used to be that inter-network connectivity was icing on top of the "real" network a person used.

Today, inter-network connectivity is the whole point of a network connection. How embarrassing for each individual network! To test if our connections are working, we skip right over the local content and point our web browsers at a search engine.

Users today aren't satisfied to read their email from imap.institution.edu and read USENET news-- they thirst for real-time access resources available beyond the university. Students weren't interested in the J-Stream service I helped set up at Johns Hopkins; instead they mostly posted and watched videos at YouTube. They don't really care if the the student-oriented wiki is based on campus or instead halfway across the globe (say, in Japan).

The original Internet was based on autonomous networks and opt-in routing. But eventually, all the networks opted in. Users drive everything, and when they don't get what they want, they vote with their feet. Companies like Facebook and Google stand ready and armed to provide shockingly-efficient services to millions of users who choose them. You could say that with today's network, the autonomy shifted from the network to the users.

The nice thing about University-run services is that students can organize and ask for changes, as Fred pointed out. And for people like me, there's something nice about knowing the person who runs your email system.

But if your busy university staff doesn't have time to investigate an email server with fast full-text indexing, you might wish for change. Having the university tear down its internal services is a progression toward seeing its network as simply transit.

Imagine the loss of pride. It used to be that the university personally ran a system for helping users get what they wanted. As it becomes simply transit, the staff are just greasing the cogs of a larger, invisible machine that's easy for users take for granted.

Some netizens like me hold email as sacred, a beautiful institution based on standards and a decision to interoperate. When your university switches to Gmail, I'll be sadder, but maybe what you'll get is professors who can spend more time with students and less time configuring desktop software.

Trade offs

Every university has a choice: Pay hundreds of thousands to millions of dollars a year for dedicated staff to run an in-house email system, or let Google do it. Think for a moment of what good could come from those dollars when put to use in other ways for students.

Your school could start a switch to all-organic food. It could start paying more of its employees a living wage. Imagine the travel funding for student activities that can come from hundreds of thousands a year well-spent. It could run a massive used textbook clearinghouse to help students avoid pouring their dollars into the textbook industry.

And now cry with me. What I've asked you do is to consider sacrificing institutional autonomy for cold, hard cash. That's to say nothing of the ecological benefits or the productivity increases possible from having Google's paid experts run this part of the computing system.

Conclusion

Is an official Google email system much different than the reality most students I know live, which is configuring their student email address to forward to gmail.com?

For those of us who would be sadder with one more push toward centralizing email with Google -- for those who see it as the behemoth whose size threatens the decentralization that used to be the core of the Internet -- I ask you to think positive. "See the profit from your loss."

I have no conclusions for you, just niggling questions.

[] permanent link and comments

Sun, 07 Feb 2010

Cosmetic carbon copy: The opposite of blind carbon copy

I propose a new feature for email software: Cosmetic carbon copy. CCC works very similarly to today's carbon copy feature: If you put an address in the CCC: list, when the recipients open the message, they can see the address. The one difference is that with "cosmetic" carbon copy, the CCC:d address never recieves the message.

An example might illustrate the situation. Let's say someone (Alice) wants to invite Bob to a movie but doesn't want Charlie to come. She might send this email:

From: alice@example.com
To: bob@example.com
CCC: charlie@example.com
Subject: MOOOVIEEE!

Hey all my friends, join me for a movie tonight!

When Alice sends the email, Bob recives a copy. Bob thinks that Charlie received a copy, as he will be in the CC list. But Alice's mail software never sent Charlie a copy. So Alice can relax, knowing that Bob won't forward a copy to Charlie, since Bob thinks he already received it.

Alice and Bob will meet up without Charlie, and Alice will quietly sigh in relief.

How can this work?

Cosmetic carbon copy works on the same principle as blind carbon copy: the contents of the message are fundamentally independent from the recipients.

Saavy email users have used the "blind carbon copy" feature for years. When you place an address in the BCC list, that address will receive a copy of the email even though other recipients won't see the address listed. This allows for a form of privacy between the sender of the email and that hidden recipient.

This works because, like postal mail, email messages are delivered using an "envelope" that contains the actual recipients. When you compose a message in Alpine, Gmail, or Thunderbird, you are writing the contents of the envelope. When you hit send, the mail software looks for email addresses that should receive a copy. It creates one envelope per address, stuffs the letter inside, and sends the whole thing on its way through the Internet using a protocol called SMTP. When the recipient (Bob)'s email system receives it, the letter is pulled out of the envelope and placed in an inbox.

Which means the envelope is entirely invisible to Bob, the recipient. Most mail software puts information about the envelope in email headers. Since each email recipient gets a separate envelope, In the case of cosmetic carbon copy, Alice's letter claims that Charlie was on the CC: list. But Bob can never learn that Charlie's copy was never sent.

So to implement cosmetic carbon copy, Alice's mail program must understand this rule:

• For each address in the CCC list, copy the message to the CC: list in the email message.
• Create no new envelopes when sending the message.

Because of the last bullet point, this "carbon copying" is purely cosmetic rather than functional.

A possible privacy problem

You might wonder, what happens when Bob hits reply-all to say "Yes, I'm coming"? Then (oh no!) Charlie might see the invitation.

Not a problem: Most of my friends use Gmail, and Gmail users almost always hit Reply instead of Reply-All. Gmail used to have an experimental option called "Reply All by Default", but thankfully they removed that option.

A future version of this specification might suggest mangling the last "." in the BCC:d email addresses with the ONE DOT LEADER character, which looks like "." but isn't one. That way, even if Bob clicks "Reply all," Charlie's email address is subtly incorrect and will bounce.

Future work

The story I've told here is marginally simplified so it's understandable to a less-technical audience. Those who want a more technical version can request I submit an RFC. Perhaps in two months?

(File under "games to play with email.")

[] permanent link and comments

Fri, 01 Jan 2010

Detecting stale versions of WordPress

I run a personal server that hosts web space for a few friends. Probably the most popular thing to do with the space is to install WordPress and run a personal blog.

A few days ago, I discovered some attackers were abusing one of the sites. Once we upgraded the site to the latest version of WordPress, the attack went away. So I wrote a tool that, every night, emails me a report of the locations of old versions of WordPress. A sample email:

Current version of WordPress: 2.9

oldroommate has WordPress 2.5 in /home/oldroommate/web/oldroommate.com/

Eek! WordPress 2.5 is old!

How it works

Each time it runs, it looks at wordpress.org to see what the current version is. The code to do that is written in Python and uses lxml.html. It prints the current version in the report, and it uses it when analyzing WordPress installs.

To analyze WordPress installs, it executes locate readme.html, looking for WordPress's tell-tale documentation file. For every such readme.html, if it matches a simple regular expression suggesting it's a WordPress readme file, it performs the following analysis:

• It does some simple seding and greping looking for the version of WordPress described by that file.
• If the version detected is older (as calculated by dpkg --compare-versions), it creates a one-line report like the one above about oldroommate.

If it found any installs of old WordPress, it prints a report like the one blockquoted above to stdout.

How to use it

To get emails, I run it with cron. You can add a stanza like this to your crontab (edit it with crontab -e):

@daily cd find-out-of-date-wordpress; ./look.sh

Ta-da, nightly reports.

To get a copy

Do a git clone:

git clone git://git.asheesh.org/find-out-of-date-wordpress.git

or browse its gitweb.

Feedback

I'm quite interested to hear what others do to avoid old web apps being attacked. If there's another bit of software that monitors web apps for needing upgrades, I'd love to hear about it! Obviously if you have feedback on this tidbit I wrote, let me know.

(To me, apt-get doesn't seem to be the answer. Web apps (especially PHP ones) don't usually seem to support keeping the code in one place with multiple different configuration files. And users get excited about the latest and greatest and don't want to wait for me to upgrade, and I can't blame them.)

If some of you don't like the Python dependency or anything else, I do welcome patches!

[] permanent link and comments

Copyright © Asheesh Laroia. This work is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Open Hatch is my current project.