The Blog That Goes Ping

I added an app to the Ruby Shoebox.

A while back I happened across this article on programming.reddit.com — “Moving the ‘C’ in ‘MVC’” — about web applications whose logic is implemented primarily on the client-side, in javascript, as opposed to the server-side. Interesting stuff, the sort of thing that’d bubbled around my head at one time or another.

That article mentioned clipperz.com and their concept of a “zero knowledge web app.” The idea here is to implement client-side cryptography in javascript and store nothing on the serverside except wads of encrypted data. Data that is encrypted on the client, that is. So it never passes over the wire in the clear, and it’s never decrypted on the other side of the wire.

That’s pretty cool. In fact, clipperz.com hosts their own best shot at a zero-knowledge web app, a password manager. A web-based password manager seems insanely insecure, but not so if you implement it as a zero-knowledge web app. It’s basically like keeping a local HTML with all your passwords and javascript which allows you to click on those passwords and have it launch the appropriate page and log in to the service in question (Google, Facebook, whatever) — except that instead of keeping it locally you’re keeping an encrypted version of it on clipperz.com’s servers.

As far as usage goes, it’s pretty simple, but unusual. In a normal web app, you log in once, after which you are recognized by cookies until some timeout period. That’s because you’re logging in to an app running on the server, and cookies help maintain the illusion of a persistent connection. In clipperz, the app is running in your browser. So if you close the page and come back to it, you have to log in again. But you can leave that page open forever and it never times out, because there’s a real connection between you and the app (an open browser window) so there’s no need for the whole cookie deal.

Adding logins to the app is an unusual process but easy once you get used to it. When you’re on the login page to the service in question (myspace, yahoo, whatever) with your username and password typed in the blanks, you can click on a bookmarklet you’ve previously saved from clipperz, and it will extract a chunk of JSON data from the page you’re on, representing the login form, your username, and password. You cut and paste that into your running clipperz session in another tab or window, and it takes that JSON chunk and adds that to its data store, and now you have a clickable link on your clipperz page which will log you in to that service.

Knowing I’ve got an instant one-click login to a service makes it easier for me to make a habit of logging out of a service when I’m not using it.

It’s also easy to maintain more than one login to the same service using clipperz. Each is just one click away.

Clipperz has a sometimes-friendly, sometimes not-so-friendly competitor named “PassPack,” whose authors consider Clipperz.com’s zero-knowledge thing “fallacious” in some way, though reading through it I’m still not sure exactly what they think is wrong with Clipperz’s way of doing things. I guess the idea is that any privacy and security that Clipperz provides for you that PassPack doesn’t is just silly and you shouldn’t worry your pretty little head about it, for such worrying is a “fallacy.” I don’t know. It sounds like PassPack might be easier to use, and harder to understand what they’re doing. With clipperz you just have a username and passphrase; with PassPack you have a username and password and an additional crypto key. (UPDATE: see comments below, from Tara from PassPack for clarification of what they were getting at.)

In any case, PassPack and Clipperz have each posted a list of the pros and cons with their respective services. Overall I have to say that having actually used Clipperz for a while I don’t see anything about PassPack that encourages me to explore it as an alternative.

Anyway, my review of Clipperz after a couple weeks of use — thumbs up! It’s unusual but worth getting to know.

XQuartz, the cutting edge version of Apple’s X11.app, supports pressure-sensitive tablets as of the latest version, 2.3.0. Or so says the page — I have not personally confirmed this yet.

This could finally put to rest my Linux twitchiness if it turns out to work!

UPDATE: I can confirm, through the xinput commandline tool, that it does now get pressure and location data. However, as noted here by Jeremy Huddleston, GTK and therefore the Gimp and Inkscape are not receiving that data, for reasons which are unclear. Furthermore, with this New Hotness working, you can’t use the tablet the way you used to be able to — as a mouse. Because tablet taps don’t register as mouse clicks.

So a threshold has been crossed, but this whole wacom/XQuartz thing is still not ready for prime time.

And it’s a total hassle to uninstall XQuartz once you installed it (you have to blow X11 away completely and reinstall from your OS X install DVD.)

UPDATE 2: “Total hassle” doesn’t begin to describe it. Despite having reinstalled from the DVD per instructions, X11 doesn’t work at all anymore. I’m not sure what I can do to restore it short of a total OS reinstall from the DVD, restoring my stuff from my Time Machine backup. Ouch.

UPDATE 3: IT GETS WORSE:

I did the reinstall. X11 stopped working. Apparently a bug in Apple’s 10.5.3/4 combo update hoses X11 completely. Guess what the recommended fix is?

Install xquartz from macosforge. WHICH IS WHAT STARTED THE DAMN PROBLEM.

I’m going to try an earlier version of Xquartz (2.2.3) in the hopes that I get the fix without hosing my tablet in X11 again.

UPDATE 4 / CONCLUSION:

Just confirming that installing the next-to-last release of Xquartz (2.2.3) brought things back to normal. Geez, and I think of Linux as being full of bullshit technical hoops to jump through!

John M McIntosh announced on the squeak-dev mailing list that “I’m pleased to say that I’m one of the 1.5% of the iPhone developer population that has been accepted to officially build applications for distribution via Apple’s iPhone Application Store.”

He’s prepared a 93-day plan to build a new fully documented Objective C based source tree to host the Squeak VM on the iPhone and in addition as a 64bit VM on OS-X. He’s already collaborating with Impara who are looking at adapting the Squeak UI to the iPhone’s multi-touch paradigm and platform widgets, and is looking for further support (and funding) for this work.

John is also looking to offer support for Squeak developers hoping to make their applications available through the iPhone Store, although he notes that Apple has a number of restrictions limiting the types of applications that can be made available in this way.

[From Squeak on the iPhone! « The Weekly Squeak]

I love Smalltalk, specifically Squeak. I don’t actually use it for much, I have just enough experience playing around with it to see what is so sweet about it, but not enough to be really effective with it. Smalltalk on the iPhone? Now that’s cool.

I have a folder full of old mail in Apple’s Mail application. It’s gigantic. About 70,000 messages. Most of them are duplicates, because it’s the result of finding old folder of mail upon old folder of mail and merging them together into one great hoard. The actual number of real distinct messages is probably a smallish fraction of 70,000.

What’s worse, some of the 70,000 are blank. In an inept attempt at writing a Python script to clean up a similar uber-mail-folder in the past, I somehow took a lot of old mail and destroyed the body of the emails, leaving the headers intact. So my gigantic folder includes many duplicates, but some of the duplicates aren’t real duplicates because they have missing bodies.

I want to somehow eliminate all the duplicate messages, and there are scripts to do that in Apple Mail. The only one that I would have trusted not to accidentally kill a real message and keep the one without a body, chokes and fails on a folder that large. (It also choked and failed on a smaller folder. Maybe something changed in Leopard that breaks that script.)

So I wanted to go through and destroy all the messages which have blank bodies — they’re no use to me and they make it dangerous to get rid of duplicate messages. I tried exporting everything to a mbox-format file, and use some of Python’s nice mailbox-manipulation libraries, but the file was insanely large, and Python on my macbook staggered under its weight. (Besides, my use of Python caused this problem, a while back…)

So eventually I turned to AppleScript. (I first tried using rb-appscript, but it turns out I don’t need any special Rubyness for this, and it’s easier to learn from examples of AppleScript on the web if I don’t have to translate them into Ruby before I use them.)

I wrote a script in Apple’s Script Editor called “Winnower.” It takes messages in a folder called “doing” and sorts them into two folders, “blank” and “done,” depending on whether there’s any content in the body or attachments on the mail. I put a few thousand messages at a time into the “doing” folder and then run the script. (The full weight of the 70,000+ message folder was too much for this script too.)

It looks like this:

tell application “Mail”

set doingbox to mailbox “doing”

set blankbox to mailbox “blank”

set donebox to mailbox “done”

set doingmessages to messages of doingbox

repeat with thisMessage in doingmessages

ignoring white space

if mail attachments of thisMessage is {} and content of thisMessage is equal to “” then

move thisMessage to blankbox

else

move thisMessage to donebox

end if

end ignoring

end repeat

end tell