Fingerprints As Access Tokens

Everybody seems to have an opinion about the new TouchID fingerprint sensor on Apple’s iPhone 5S. I suppose I do, as well.

Critics object to the idea that a fingerprint sensor, no matter how good, should be used to safeguard critical data. Dustin Kirkland makes the case (via John Moltz) that biometric information is inherently bad as a substitute for a password, because it cannot be “independently chosen, changed, and rotated.”

I take his points seriously, and they seem well reasoned from a security point of view, but they are based upon the premise that passwords are the end-all be-all of security, when in fact common sense proves they are not. The oldest, most trusted, and most widely deployed method of authentication on the planet is in fact “biometric”: the human ability to recognize a familiar face. The fact that my appearance could technically be spoofed does not change the fact that arriving at the home of a childhood friend after 20 years of separation will still earn me an invitation to the dinner table, if not a bed for the night.

So fingerprints make lousy passwords. Who cares? Their use in practice need not replace other authentication schemes, it only needs to augment other schemes in a manner that increases overall security.

Most authentication systems in society are scaled appropriately for the context in which they are deployed. When I travel by airplane, I am asked to show a government ID to get through the security gate, but thereafter, a simple piece of printed paper will get me on a plane. The government takes it for granted that once I’m in the boarding area, the odds of somebody getting hold of my scrap of paper, or my getting hold of theirs, and neither one of us subsequently complaining, are marginally small. Furthermore, if the two of us mutually agree to swap tickets and travel to the other’s destination, we haven’t really caused any significant harm, except perhaps to the egos of the folks in charge at the TSA.

Boarding passes are little scraps of paper that make lousy identification cards. I can’t use them to reserve a hotel, file a police report, or obtain a marriage license. Yet in the right context, I can use one to travel from Boston to Shanghai without a single person batting an eye or thinking twice about verifying my identity.

In this sense the airline boarding pass is like an access token. On the web, an access token is something obtained by stronger authentication that permits continued access with weaker authentication. For example when I allow a Twitter client to connect to my Twitter account, I must first visit Twitter.com and possibly enter my full account credentials. After the access token has been vended however, it serves much like a boarding pass, allowing free access until and unless I or Twitter registers a complaint.

There’s another sort of abstract access token that has been available to users iOS devices since day one: your continuous use of the device. If you have in your possession an iOS device and you abstain from turning it off or letting it sit idle, you retain free access to the various data on the phone. From a security point of view, this token is even worse than a fingerprint: anybody, including the family cat, can sustain it if they are so inclined. Leave a phone on a table for 5 seconds, somebody else picks it up, they have your “activity token,” and they didn’t even need to scan your fingerprint.

I view the fingerprint sensor on the iPhone 5S and other devices as an opportunity for extending this kind of implicit authentication. It’s not a substitute for a password, but rather a convenient token for obtaining streamlined, continued access to protected resources. It’s the boarding pass that prevents you needing to take out your ID, and go through a body scanner or pat-down again, just to get on the damned plane.

We can argue about whether Apple has chosen the right boundaries for where a fingerprint should be traded for full authentication, but as a technology it stands to fill that gap between the frighteningly insecure “unlocked while active,” and frustratingly unusable “full authentication required when inactive.”

In short, I would like to see fingerprint authentication deployed in a way that pays respect both to the relative convenience and the relative insecurity of a fingerprint. If I can for example configure my phone to require a fingerprint unlock after 1 minute of inactivity, but to require a passcode unlock after 30 minutes of inactivity, my concerns about fingerprint security would be effectively put to rest. Could a malicious person steal a high quality impression of my thumb print, construct a prosthetic, fleshy representation of it, and use it to unlock my phone? Perhaps. But if they can’t do it within half an hour of stealing my phone, they better get to work on cracking the passcode.

A Mockery Of Whom?

Are Marissa Mayer and Yahoo!’s design team playing the fools, or playing us for fools? I honestly am not sure anymore.

When the company announced more than a month ago that they would debut a new logo, I was surprised to learn that before sharing it with us, they would subject themselves and us to 30 days of lackluster logos. It felt to me like a lapse in judgement to:

  1. Put off for even a day the fresh new logo that was prepared to move the company forward.
  2. Accept for even a day, let alone 30, the use of any logo that had not made the cut.

But I sort of laughed it off, snidely and then crudely shared my thoughts on the matter, and waited out the 30 days.

Last night Yahoo! finally revealed the new logo, and the mildest reaction I can possibly muster is that it does not appear to be a professional design:

Yahoo's new logo, September 2013.

Because I myself am not a professional designer, I am tentative about making specific judgements, but my relatively untrained eye reacts to several problems with logo. The beveled characters make the logo appear dated and distractingly three dimensional. The scalloped edges lead the eye away from forming any unified shape. The lightness of the strokes, particularly in the bar of the A and H makes the whole thing feel fragile and not suited to scaling very large or very small.

A snarky summary of my criticisms would be to say that it looks like something somebody threw together in a weekend. Upon seeing the new logo I tweeted that I hoped it “was designed by committee, because I don’t want to imagine an individual taking the brunt of reactions.”

Marissa Mayer herself chimed in on the new logo, so now we know that both are true: it was designed by committee, and it was thrown together in a weekend:

So, one weekend this summer, I rolled up my sleeves and dove into the trenches with our logo design team: Bob Stohrer, Marc DeBartolomeis, Russ Khaydarov, and our intern Max Ma. We spent the majority of Saturday and Sunday designing the logo from start to finish, and we had a ton of fun weighing every minute detail.

Expletives are begging to let loose in my typing. You have to be kidding me.

This is not how any company, big or small, cherished or unknown should design a company identity. The more I read about Yahoo!’s process for this redesign, the less respect and confidence I have in them. As a minor Yahoo! shareholder and a long-time, sometimes grudging fan of the company, I am not sure where to go with these feelings.

It’s that point of gullible disbelief where one starts to look around for hidden cameras. Are we being punked? Is Marissa Mayer merely making a mockery of Yahoo! and its identity, or if she is snickering churlishly as she pulls off an elaborate prank, hi-fiving her co-conspirators as they witnesses the world react jaw-gapingly to their purported pride in these actions?

The Imperfect Craft

For much of my career I viewed software development as a craft: a constructive endeavor with fixed standards of excellence. I thought that over a lifetime, I could assiduously refine my skills, inching toward some level of subjective mastery until eventually myself and others would agree that I had become “a real expert.”

Unfortunately it doesn’t work that way with software. The technological context in which software is developed and used changes constantly and dramatically. So most of the stringent guidelines we impose upon ourselves in the name of craftsmanship are at risk of being obsoleted by some new advance in hardware, in programming languages, or in the baseline services of the operating systems we develop for.

Ask yourself, or a software developer of a certain age: what were the guidelines for crafting excellent software 5 years ago? 10 years ago? 20 years ago? The farther back one goes, the less relevant the answers will be to our modern craft. Memory management? Not a significant issue for most programmers today. Multitasking? Obliterated by modern operating systems with efficient context switches. Concurrent programming? Constantly reinvented in the wake of multi-core CPUs, GPUs, and higher-level programming language features.

I have spent a lot of my professional life honing “the skills of programming.” That is, the set of skills that seemed important at the start of my career. But I’ve seen what happens to people who cling to outdated standards of craftsmanship: they become self-righteous, bitter, and delusional. Guided only by the hallowed rules of yesteryear’s geniuses, they and their work become marginalized. Without a foothold in the modern technological context, programmers who should be great are rendered effectively incapable of developing their craft.

I’m sure this problem is not limited to software development, but given the world’s obsession with computers and related technology, the software landscape is changing much faster than many of us can easily keep up with. The world demands that this craft change. The technology for sculpting, firing, and glazing a ceramic bowl has also changed over the years, but not at the same mind-boggling rate as prototyping, programming, and testing a software application has.

What if you happen to enjoy old-school programming? There’s nothing inherently wrong with crafting “retro software.” In fact, I’m sure that dabbling in outdated techniques will serve to round out a modern programmer’s abilities. But while a classics scholar may be intrigued or even obsessed with ancient Greek or Latin, she knows that in order to remain relevant she must publish her papers in modern English. And if Esperanto were to become the lingua franca for her craft, that is the language she would have to use.

In software, the lingua franca is changing all the time, whether by adoption of new programming languages, through nuanced idiomatic changes in the ways that we use languages, or because of evolving operating-system level facilities. We don’t have the luxury of assuming that the tools and techniques of our parents, or even our younger selves, are sufficient to move the profession forward.

As a modern software developer, I derive as much joy from remaining relevant as I do from the thrill of identifying and solving the particular problems in my work. To remain relevant, I have to reject my previous assumption that I would spend a lifetime refining my craft. Instead, I will spend a lifetime adapting the techniques of yesterday’s craft to the sometimes radically different challenges of today. I may never become “a real expert,” as I hoped I might be. But by diligently throwing out the old rules and embracing the new ones, I hope to come close.

Assembled In USA

Apple has reportedly begun promoting the new Mac Pro, of all products, in US movie theaters. John Gruber linked to the story, commenting on the apparent disparity between mass movie-going audiences and a pro-market computer:

Impressive marketing move for a product that is by all means truly “pro”.

One objective of the teaser is to remind everyday American movie-goers that Apple continues to innovate in computer hardware. The teaser emphasizes Apple’s ability to design beautiful hardware and to push the envelope of how a computer looks and feels. It serves to remind the public that Apple is both capable and cool.

But I expect the other goal with this spot is to appeal to American pride. Why promote an expensive, niche-market computer like the Mac Pro to everyday Joes and Janes across the country? Because on top of being an innovative, beautiful, envelope-pushing piece of hardware, it will be made right here in the USA.

I haven’t seen a verbatim copy of the trailer as shown in theaters. Apparently it ends with a headline indicating the Mac Pro will be available “Fall 2013.” I will be surprised if it doesn’t also subtly allude to its American manufacture. A small percentage of folks who see the ad will leave the theater committed to purchasing a Mac Pro this Fall. A far greater percentage will leave the theater convinced that the Chinese-manufactured iPhone or iPad they’re considering for Christmas is part of a great American tradition. And they’ll be right.

Update: Reports from folks on Twitter indicate that the movie-trailer features no such mention of the Mac Pro’s US assembly. That strikes me as a shame and a missed opportunity particularly considered the hyper-focused US market for the ads. Another compelling theory from Drew Pickard suggests that running ads for the Mac Pro in movie theaters is a good way to make sure every movie-making professional is aware of the computer, and will consider purchasing them for their production teams.

Mercurial Plugin For Xcode

Raphael Sebbe (@rsebbe) put together a nifty plugin for Xcode (version 4 or 5!) that coerces Xcode into substantially supporting Mercurial, in addition to its native support for Git and Subversion.

The plugin builds upon an existing script that essentially acts as a Git-facade around Mercurial. Swapping the script in for Git is sufficient to cause Xcode to think it’s dealing with Git, when in fact it’s dealing with Mercurial. Pretty clever. The plugin takes this a step further by appyling some runtime patches on Xcode to improve the handling of Mercurial repositories.

Although Raphael calls it a plugin, and it does extend Xcode, it’s important to recognize that Xcode doesn’t provide an official plugin mechanism. Not even for revision control solutions. This makes the achievement even more admirable, but should also inspire you to proceed with caution if you choose to try the plugin out.

As explained in the project documentation, the plugin is still experimental and doesn’t support all of Xcode’s Git-based features. Still, it’s a nice start, and I appreciate the spirit of rallying Mercurial fans to fill the void that Apple has left in choosing not to officially support Mercurial.

Bitsplitting Podcast Hiatus

Earlier this year, I announced the Bitsplitting podcast, explaining that I hoped to establish a new kind of “tech podcast” that is more of the genre perfected by Terry Gross of NPR’s Fresh Air:

I’ll differentiate my show from some others by focusing more on the personal background of my guests, and on trying to discern a philosophical arc to their life and career choices.

Ten episodes later, I am proud to claim that I’ve achieved that. Thanks to an incredible list of thoughtful, well-spoken guests who agreed to join me on the show, I have something fabulous to show for the hard work that went into making this happen.

And now I need a break.

Planning, recording, editing, promoting, and funding the Bitsplitting podcast is both more difficult and more rewarding than I expected. I started off very anxious about the challenge of producing a show that meets my standards, and I have for better and for worse remained very anxious about many aspects of the show. Sticking to a schedule and pep-talking myself into believing that I am doing a good job (I do, most days!), is a lot more tiring, physically and emotionally, than I expected. Not to mention I have lots of other projects on my plate.

By taking a break and adopting an irregular “series” schedule for the show, where I am not committed to the never-ending pressure of pushing out the next show, I hope that it will give listeners a chance to catch up and enjoy the work that has been done, and give me a chance to think about how the show should evolve going forward.

Thank you very much to all the listeners and sponsors who supported the show from its infancy through its still-young, but gratifyingly successful state today.

Bitsplitting With Jason Snell

Episode #10 of the Bitsplitting podcast features my friend Jason Snell of IDG and The Incomparable podcast.

Jason’s role as editor of Macworld made him familiar to me as a Mac enthusiast and indie software developer. After I acquired MarsEdit in 2007, I had the opportunity to chat a bit with Jason about his own use of the app. Over the years since then, I’ve had the fortune to meet with Jason during WWDC and occasionally when he visits the Boston area for his work.

Thanks for joining me on Bitsplitting, Jason!

Bitsplitting With Jean MacDonald

Episode #9 of the Bitsplitting podcast features my friend Jean MacDonald, who recently founded App Camp For Girls. Jean and I know each other through our respective efforts to boost our small Mac and iOS-based software companies. She is a partner at Smile Software where she focuses on marketing, PR, and customer satisfaction, among other things.

Over the years I have had the pleasure of catching up with Jean at various conferences and, when the stars align, in the Karaoke bars. I have always been impressed by Jean’s indomitable spirit in both her personal and professional endeavors. Thanks, Jean, for joining me on the show.

Bitsplitting With Marco Arment

Episode #8 of the Bitsplitting podcast features my friend Marco Arment. We got to know each other at first on a professional level when he was the lead developer at Tumblr. When I was working on initial Tumblr support for MarsEdit, Marco helped by adding a number of enhancements to the Tumblr API.

Since then Marco has left Tumblr, founded Instapaper, sold Instapaper, founded The Magazine, and sold The Magazine. That’s among other things, and not necessarily in that order. I’ve had the good fortune of getting to know Marco better as a friend and colleague as we each pursue our indie software development, blogging, and podcasting ambitions. Thanks for joining me on the show, Marco!

Bitsplitting With Buzz Andersen

I’ve just published Episode #7 of the Bitsplitting podcast, featuring my friend Buzz Andersen. Buzz and I got to know each other online after I somewhat embarrassingly called him out for, get this, declining to participate in the Cocoa Radio interview podcast.

In the intervening years we have gotten to know each other better through our frequent run-ins at WWDC, and from, for a short while, both living the New York City area. In chatting with Buzz I learned more about his childhood growing up in Denver, the things he values in cooking and mixology, and many other nuanced aspects of Buzz’s approach to life and work. Thanks for coming on the show, Buzz!

What’s That Color?

For a long time I’ve been interested in Adobe’s Kuler, dedicated to the art and science of choosing aesthetically pleasing color combinations. Or unpleasing color combinations, if that’s your thing.

Today, Adobe released an iOS app for capturing and tinkering with color palettes. The palettes can then be automatically saved for retrieval through the Kuler web site, or shared via email or Twitter.

Playing around in my office, I pointed Kuler at the Milton Glaser “View from Greve” print on my wall (graciously gifted by Glenn Fleishman). Obviously, Mr. Glaser deserves most of the credit for choosing this color scheme, but Kuler earns some points for picking up on some of the key elements:

User interface of the Adobe Kuler iOS app.

If you don’t like the colors Kuler latches on to, you can move the camera slightly to provoke it to rejigger its choices. Or, tap the screen to freeze the camera, then move the sample points on the image to precisely the color of interest.

Another tool I’ve used in the past is Color Identifier, which has a more streamlined utility for capturing solitary colors while further attempting to give a name and HTML-style hex color string to the captured value.

UI of the Color Identifier app.

I love this class of iOS app because it follows through on the promise of using a combination of technologies to grant superpowers to users. A camera or a computer by itself is of limited value for quickly cataloging something as precise as a set of colors from the environment, but a camera and computer united by clever software, all in the palm of your hand, is an exciting tool indeed.