about us


helping out


progress (feed)

hire us

contact us

app.net apps facebook twitter

A Ridiculous Proposal

Posted: October 26th, 2014 | Author: | Filed under: Technology | Tags: , , | No Comments »

Seventeen years ago, I wrote and released an email client, called Eucalyptus, for the Amiga. As part of the process of writing it, I had to become familiar with the RFCs pertaining to email formats and structure, sending and receiving protocols, security, etc. I also built into it support for PGP signing and encryption, because I believed that security, privacy, and authenticity were important with regard to email.

In my study of these RFCs, I became aware that the email system, while it has served us for quite a while, is fundamentally broken. How is it broken?

  • Email headers are forgeable. That means that we can’t really trust information in the message, such as the From header, or the series of Received headers, that those reliably represent the originator or path, respectively, of the message.
  • The SMTP protocol was not originally designed with authentication. It’s been subsequently bolted on, but the presence of credentials don’t ensure the identity of the sender.
  • The lack of inherent signatures and encryption have led to a system where privacy and security are an afterthought. The system was designed (one could argue, naïvely) where everything is transmitted in the clear. Hello, NSA.

Since writing Eucalyptus, I’ve often thought, mostly idly, about how I would fix the email system. It wasn’t until recently, when I was listening to the Core Intuition podcast (episode 158 or 159, I don’t remember which), that I started giving it some serious thought. 

A new system would have to address some important issues in order to be good and, hopefully, ubiquitous.


A step toward addressing the spam problem would be to enforce identity and the ability to validate that identity. What this means is that, as part of the account setup process, a keypair is generated for the user, and every outgoing message is signed, and every incoming message is validated.

Some might argue that, by using keys and signing every message, the system is implicitly requiring the use of real identities. That is actually not the case. A keypair could be generated that represents a pseudonymous identity, and the purpose it would serve is validating that messages signed by that identity actually came from that identity.


By building in, from the ground up, support for encryption, users are provided with the ability to transmit message content privately with little “barrier to entry”. The system, as it is, requires technical knowledge on the end-user’s part in order to setup keys for encryption and integrate encryption into their workflow. It also forces recipients to have a corresponding setup. By making it a foundational feature of the system, encryption of messages for the sake of privacy becomes a matter of flipping a switch (see also Usability below).


An essential component to a successful system is usability. Recently I tried to set up a local Tent node. I spent a couple hours struggling with obtuse errors from the “installer” (which turned out to be the cloning of a Git repository, a series of dependency installations, and then some terminal commands) before finally giving up, and I consider myself to be reasonably smart when it comes to that sort of thing.

In my opinion, the fundamental failure of Tent (as well as Diaspora and some others) is lack of usability. While their efforts are noble and laudable, the installation, configuration, and in some cases, simple use of those systems require far more technical knowledge of systems administration and software development than the average person should be required to have. Granted, the current email infrastructure requires as much knowledge (DNS records, configuration of the mail relay/host, account setup, spam filtering, etc.), but a lot of that is addressed by the presence of hosting services (Gmail, Fastmail, Outlook.com, ISPs, etc.) that take care of much of that. But the installation of a Diaspora pod, or a Tent node, or whatever, should be the matter of a single command execution, or copying an app into the Applications folder and then the entry of some basic information before the user is up and running.


The implementation of such a system is non-trivial, but is something that, in my opinion, is necessary if we are to move forward and achieve security and privacy, especially considering the current abuses demonstrated by our governments. The current system is insufficient for our needs. Other parts of the Internet infrastructure have been replaced with better things. The email system is long overdue for this change.

Education Assumptions

Posted: February 8th, 2014 | Author: | Filed under: Technology | Tags: | No Comments »

Originally posted: April 30, 2011

Anil Dash:

I didn’t go to college. It’s another facet of the flaw in drop-down identities that LinkedIn assumes someone in my social context had to have learned in a traditional way in order to participate in the career that I have.

I didn’t go to college either.  I like to think that I don’t need this kind of validation, but it’s nice to know that there are people out there whom I respect and consider infinitely smarter than me, that have made their way without a formal post-high school education.


Posted: February 8th, 2014 | Author: | Filed under: Mac App Store | Tags: | No Comments »

Originally posted: April 21, 2011

Proelia 1.0.1 was rejected from the Mac App Store.

(No, this isn’t that kind of post.)

This is my first completed application in recent history, and after going through all of the other distribution and exposure channels, I figured I would submit the application to the MAS.  In the back of my head, I thought that it would be cool if I made through on the first run.  You know, a little personal victory.  Silly, yeah.  I even thought it was taking all the necessary precautions.  I read Craig Hockenberry’s post on preparing apps for the MAS, I knew about the issues with BWToolkit using private APIs, and built a specific version so I wouldn’t get nailed on that, and I read over the rules multiple times to make sure I got everything right.

I guess I didn’t.

The app was rejected on two points.  First, it turns out that I linked against and bundled the private-API-using version of BWToolkit instead of my own clean version.  Gah!  Second, Proelia is “apparently” in violation of rule 2.30, the “keep your hands to yourself and off my stinkin’ filesystem” rule.  It’s this rule, or more specifically, my reviewer’s enforcement of this rule that this post is about.

After overcoming the twinge of sadness from being rejected (and not achieving my personal goal of making it through the process on the first try; oh well), I sat down in front of Xcode, set some breakpoints, and tried to find out where I was transgressing with regard to the filesystem rule.

Now, specifically, the reviewer pointed out that Proelia was writing to /Library/Proelia.  So I checked on my system, and that’s certainly not the case.  As far as I can tell, it’s not even possible without escalated privileges:

$ ls -ld /Library/

drwxrwxr-t+ 63 root  admin  2142 Feb 10 07:46 /Library/

Proelia does store encounter information in the user’s Library directory, i.e., /Users/awesomedungeonmasteruser/Library/Proelia.  In fact, I was pretty certain that I was determining the directory in the proper way:

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES);

NSString *basePath = ([paths count] > 0) ? [paths objectAtIndex:0] :NSTemporaryDirectory();

NSString* fullPath = [basePath stringByAppendingPathComponent:@"Proelia"];

I might be wrong; it happens more than I’d like to admit.  So unless this code does something other than what I expect (and it seems to work just fine here, because the files are ending up in the right place), I think my reviewer screwed up.

Now, I’ve read some blog posts about other apps that were rejected for a variety of what the posters considered unjustified reasons, and I’ve followed plenty of discussion on Twitter amongst Mac developers regarding the submission guidelines, and their experiences with rejection, and so on and so forth, so the pitfalls and gotchas aren’t foreign to me.  And I’m not declaring my rejection “unfair” or “unjustified” or whatever.  I also noticed a few developers today discussing rejections similar to this.

What occurred to me (and others before me, I’m sure) is that the process has an aura of whimsy and capriciousness about it, and isn’t entirely trustworthy.

Here are some of the things I’ve learned about reviewers and the review process:

  • Reviewers have a set of tools at their disposal that help them to determine things that would be otherwise difficult or impossible, such as private API usage.
  • Application aesthetics are judged subjectively, because a human standard is applied instead of a machine standard.
  • Reviewers don’t apply standards consistently; i.e., one reviewer might allow a violation of a particular rule while another doesn’t.

In a lot of ways, submitting an app to either one of the App Stores is a crap shoot.

In my particular case, I think I got hit by an automated tool that “raised a potential red flag,” but he or she didn’t take the requisite actions to validate whether my app had actually violated the rule.  Maybe he or she was having a bad day, or got distracted, or was just a little too eager to reject something.  When you factor human beings into a process, all kinds of crazy things can happen.

What also occurred to me about the process is how little it can be influenced or corrected from the outside.  Some behaviors change, and rules are modified, but it seems much more like it’s Apple having to discover their mistakes themselves rather than accepting input or feedback from the developer community.  As a parent, this strikes me as very similar to a 3-year-old’s “I can do it myself!” tantrum.  This is disturbing and discouraging, especially when I think I’m dealing with adults who are supposed to be professionals.

Alas, I’m going to fix my errors, and resubmit.  Roll the dice.

Work/life Balance

Posted: February 8th, 2014 | Author: | Filed under: Uncategorized | No Comments »

Originally posted: April 15, 2011

Brittany Tarvin:

A company at which employees must fit their sick days and personal time into a set number of days in a year does not have a work/life balance. A company at which employees must request time off and hope that they are permitted to go on vacation during the time they have selected, does not have a work/life balance.

This is some of the reasoning behind why I have decided to press forward as much as I can with my indie Mac software business.

Simple Things

Posted: February 8th, 2014 | Author: | Filed under: Uncategorized | No Comments »

Originally posted: April 15, 2011

Michael Tsai, on JetBrains’ new appCode IDE for the Mac:

It does clearly best Xcode 4 in one area, though: it can sort the file list alphabetically.

Why does it seems like improvements to some software result in simple (nearly essential) features getting cut?  I lost count of the number of times I’ve been frustrated because I can’t just sort the file list.

Who’s your blogger?

Posted: February 8th, 2014 | Author: | Filed under: Uncategorized | Tags: | No Comments »

Originally posted: April 14, 2011

As part of the exercise of setting up this website to support my fledgling-indie Mac software company, I followed the advice of several other indie developers I follow on Twitter: setup a blog.

So I did.

And then let is sit for a while, because I came up with a number of excuses not to write anything.  As a result of reading another blog (Justin Williams’ carpeaqua), I stumbled upon an article on the A Smart Bear blog that gave me the kick in the pants to write a second post:

But you still don’t blog, and for good reason, right? Blogging is work, and ten other things are more important. Writing is hard and takes longer than you think it ought.

And even if the blog works, the experts say you won’t be able to measure its effect, and it will probably take years to come to fruition. Years? Fooey. You need a sale today. You need a job by next Thursday. Who has time for “years?”

…but that’s like saying you’re not going learn to play an instrument because it takes practice.

…but that’s like saying you’re not going to start a company because at first it’s difficult and the payout — if there is one — is too far away to be tangible.

Not much in life that’s worthwhile is easy, especially at the beginning. That’s not an excuse to not do it.

So, I’m going to try again.  Wish me luck.

Greetings From the Road

Posted: February 8th, 2014 | Author: | Filed under: Uncategorized | No Comments »

Originally posted: March 17, 2011

For the majority of the last 10 years, I’ve had the pleasure of working with and for a brilliant man.  He was a gifted technologist, a savvy business man, and an extremely talented musician.  He was always encouraging me to strive for what I loved doing, and even placed that message in a song, encouraging the listener to not resign themselves to working a dead-end nine-to-fiver and pursue what he or she loves and desires the most.

I’ve finally begun taking that message to heart, and put words and thoughts into action.  Pilgrimage Software is that dream of mine.  It’s not quite where I want it to be; in fact, it’s a long way off.  But it’s the first of many steps.

But it wasn’t just my co-worker’s encouragement that got me going.  I have to give credit to Merlin Mann, who asked “what couldn’t you ship?!”; Dan Benjamin and his wonderful array of podcasts on the 5by5 network, without whom I probably wouldn’t have heard of Merlin; Daniel Jalkut and Manton Reece, whose senses of humor and encouraging words on the Core Intuition podcast help out immensely; and the insightful posts of Seth Godin and Amir Khella.

I’ve only got one product, and it’s not even available as of this writing (it’s in beta-testing), but I’ve got a lot of ideas, and I’m going to act on them.

I hope you enjoy the software, and hopefully there will be interesting things to read here as well.