My bike has had a flat tire for longer than I’d care to admit, so I’ve been commuting recently by foot and by bus. This leaves me with plenty of time to think, but mostly just thoughts about walking and/or taking the bus.

If you’ve spent time waiting for erratically-timed buses, you know this question well: Will I get there faster if I continue waiting or if I start walking? You can look to recent literature in recreational mathematics for some general guidance on this dilemma [1] [2]. But while waiting may pay off for the lazy mathematician, I like to get some exercise in the process. So here’s a twist on the problem: How far can I walk without missing the next bus? I’ll propose three practical solutions:

1. Walk backwards, so you can spot the bus as soon as it becomes visible. When you do, make a run for the closest stop (preferably in the direction of your destination.)
2. Move to a city that displays bus arrival predictions at bus stops. Run to the first such display, check out the next arrival prediction, and do some quick mental math as you start to walk.
3. Live somewhere that offers open access to city datasets including real-time bus location and prediction feeds. Write the following iPhone application, and then email me when it’s ready.

App description – Given your current location (determined by GPS), your walking speed (based on past commutes), and your destination and bus route (stored in preferences or assumed based on time-of-day), it calculates two commute options and displays each with an estimated time of arrival. The first option minimizes your commute duration while maximizing the portion traveled by foot, and the second option minimizes your foot-only commute time. For example:

Your best commute options today are:
* ETA 8:55am – Walk to Church St, then get on #48. (0.5mi exercise)
* ETA 9:05am – Walk directly. (2.5mi exercise, saves $2.00)

Any takers? Seems like it would be a great candidate for the DataSF App Showcase.

I’m looking forward to see what else is in the book!

Web-based applications are becoming increasingly popular, offering a variety of compelling advantages over desktop-based applications, both to developers and to users. These applications are platform-independent, accessible from any Internet-connected computer, offer offsite data storage, and often provide integrated tools for collaboration and sharing. One major tradeoff, however, is a loss of privacy. As users adopt web-based applications, their personal data (e.g. emails, address books, calendars, to-do lists, etc.) slowly migrates from the privacy of their computer to instead live on various web-app provider’s servers scattered across the Internet. While some of these web applications allow a user to flag certain data as “private”, this is a very limited notion of privacy, referring only to whether the web-application provider will share user data with other parties (such as other users.) The implicit message here is that the user’s data is always accessible (i.e. not private) to the company or individuals providing the web-application. This is a step back from the level of privacy afforded by desktop-based applications and should be recognized as such. But this doesn’t mean that we need to give up on privacy (or give up on web applications.) We just need to think more creatively.

After reading Peter Wayner’s book, Translucent Databases, on Jon Udell’s recommendation (see Achieving translucency), I saw that “translucent” database designs (?) could directly address this issue. Unfortunately, many (most?) web-application databases are not being designed translucently (more by Udell here and here). But if your web-application’s database wasn’t designed for translucency, is this a lost cause? I’m going to argue that it isn’t, and will show how you, the user of web applications, can initiate database translucency yourself, and thereby protect the privacy of your hosted personal data whenever you desire.

What do I mean by user-initiated database translucency? Think of it as BYOC: Bring Your Own Crypto. The idea here is for you, the user, to encrypt your personal data before it finds its way onto the web application server. As long as the encrypted data is considered valid by the application (e.g. doesn’t violate string-length or legal-character limitations), the application will continue to work as it did before, but the personal data will remain private. Then, when you’re later interested to view some of this data, the decryption and viewing can be done offline. If you do this right, your data will remain usable to you in the context of the web application without ever being visible (unencrypted) to the web application provider.

I’ll describe one approach to implementing this idea, which you can download and test out. Many others approaches are possible, and I’ll throw out a few ideas to get things started. If you implement one, please email me and post a comment below.

Page Axe (http://code.aribadernatal.com/PageAxe/) is a Mac OS X (i.e. “offline”) application that I wrote to demonstrate this idea. Upon running for the first time, Page Axe generates and saves a randomly-generated 256-byte key (via openssl rand -base64 -out /path/to/key 256). After that, any text typed into the Page Axe text box is encrypted with this key using the AES-CBC cipher algorithm (via openssl enc -aes-256-cbc -a -salt -pass file:/path/to/key). This encrypted text is copied to the clipboard, ready to be pasted into a text field in your web application. Page Axe also allows for viewing of this encrypted data. Copy and paste the encrypted text from the web application to Page Axe, and the text is decrypted (via openssl enc -d -aes-256-cbc -a -pass file:/path/to/key) and displayed for you to read again. At it’s core, it’s simply moving text between trusted desktop-land and untrusted browser-land in a way that guarantees that data privacy is maintained.

Here are a few screenshots of the Page Axe application in action:

Simple interface for encrypting and decrypting text.

Encrypted text is pasted into a web application.

The encrypted text can then be decrypted offline. Select a block of text from the web application that includes encrypted private data, and Page Axe will locate, decrypt, and display the private data in the context of the entire text block using Growl.

Alternative UI hooks are possible, such as this Quicksilver trigger for text decryption.

Page Axe is only one implementation of this concept of user-initiated privacy for web applications, written as a full-blown desktop application. Alternatively, one might alternatively figure out how to implement this as a Firefox Add-On, a bookmarklet, a platform-independent Java application stored on a portable USB (flash) drive, or perhaps something else. As long as the user’s private data is never accessible through the DOM to the “untrusted” web application, you’ve got a valid implementation.

I think one fascinating possibility here would be to incorporate this technique into applications designed to automatically sync offline and online data. Consider, for example, Spanning Sync, an application designed to provide two-way syncing between Apple’s iCal desktop application and Google’s web-based Calendar application. Imagine a new “Keep data private” checkbox, which causes offline data to be encrypted before being uploaded to Google’s servers and causes online data to be decrypted again after being downloaded. (For access to Google’s web application data on-the-go, a mobile implementation like Page Axe would provide access.) This example shows how data translucency can be initiated post-hoc via the web application’s published API! Many interesting possibilities exist here.

In summary, the move towards web-based applications comes at the expense of our privacy, but with the techniques outlined here, you can reclaim the privacy of your data any time you like!

Berry is lighter fare than my Coevisualizer research software framework: Its original purpose was to let me run certain small scripts on my home computer from my very low-tech cell phone. From here, Berry (originally Hackberry) eventually grew a full syntax for requests, a nice GUI, an SDK, a security model, and many new ways to connect. In addition to the original SMS communication channel, six more input channels and nine more output channels were later added (e.g. IM messaging, Skype, Quicksilver.) Talk about feature creep.

The general idea here is not new or unique. You can find software aiming to reach the same goal in many places, from startups (e.g. Soonr), shareware developers (e.g. Share), and even open source projects (Telekenesis). Now that I’m posting screenshots of Berry, we can add a “vaporware” category to this list.

Here are a few screenshots. I’ll try to add some annotations later…

An enabled Receiver will listen for Berry-formatted requests, and will ask Berry to process them.

An enabled Action can be performed by specifying it in any Berry request.

An enabled Responder can be used to send back the results of a Berry request.

Notice that I haven’t updated the code in a year and a half.

The internal/development interface is packed with a few example Berry requests.

More about Coevisualizer (including download)