dsandler.org

Wired: New Fingerprint Tech Could Mean Never Losing Your Keys Again. Or, put another way: “New Fingerprint Tech Could Mean Never Being Able To Change Your Locks Again.”

Fingerprint recognition came into wide use in forensic investigations in the early 20th century. Ever since, sci-fi writers and scientists have dreamed of using the unique skin contours on our fingertips to tell our machines we really are who we say we are. The problem is that the number of errors has just been too high.

The article breathlessly continues, extolling the new technology, but judders awkwardly to a halt at the privacy discussion. You can almost hear the sneering tone as they describe the tinfoil-hat Butlerian-jihading naysayers:

No story about biometrics is complete without mentioning privacy concerns. As they say in business, if you can measure it, you can manage it. And not everyone wants to be managed, especially if the government or a big corporation has the calipers.

This is a part of the right argument, but presented in the wrong way. It’s not that “not everyone wants to be managed.” I’m not trying to stay off “the grid” or anything—I use credit cards, I like advertising, I have a blog—but an increase in the use of biometrics for authentication still scares the pants off me.

The real problem is always this: how would you revoke that token if it were compromised? Passwords can be changed; door locks can be re-keyed. What about your fingerprints?

(US residents: Think about how damaging it is to have your Social Security number stolen. This is much, much worse.)

Bruce Schneier: Real-World Passwords.

We used to quip that “password” is the most common password. Now it’s “password1.” Who said users haven’t learned anything about security?

Fig. 1. Taken from Yahoo!’s documentation. (Recommended, my ass.)

OK, I have to take a break from writing my paper to complain about the new “Fully Featured” Yahoo! Groups email style, which was just turned on by default for everyone. Oh, but it’s got features, you say. Bah! My nice little plain-text emails have all been replaced by ugly, web-bugged, bulky HTML.

I had originally feared that you needed a Yahoo! ID to opt out of this monstrosity, but apparently you can switch back to “traditional” (read: plain text) emails by firing off a message to groupname-traditional@yahoogroups.com.

Last week at the Usenix Security Symposium, I gave an invited talk, with the same title as this post. The gist of the talk was that the debate about DRM (copy protection) technologies, which has been stalemated for years now, will soon enter a new phase. I’ll spend this post, and one or two more, explaining this.

Though his post isn’t exactly a recap of the talk Professor Felten delivered, it’s an excellent survey of the points and ideas he presented in that talk, which I was fortunate enough to hear in Vancouver a couple of weeks ago. At the end of the talk, I got up and asked what now seems like an embarrassingly dumb question:

Of course, the correct (read: witty) riposte here would have been, simply, “I’m new here.” Failing that, I mumbled something or other into the microphone, and Felten continued by explaining that, yes, you might think that a great meeting of the minds will take place in the halls of government, debating the issue on the merits, whereas what will actually happen is all the people who like {patents, DRM, flag-burning, kitten-killing, whatever} will stand on one side of the room, all their opponents will stand on the other side, and each side will be counted to determine who wins.

Someone out there has developed a crawler that attacks Trac wiki pages. Once it’s found a Trac installation, it posts an update to the WikiStart and TracIni pages. The new version appends a number of links, hidden from view using Trac’s syntax to allow arbitrary HTML:

{{{
#!html
<u style="display:none">
...nasty links...
</u>
}}}

I’ve been hit over at the FeedTree trac a few times; it’s infrequent enough that periodic checking of the timeline view is sufficient to spot and clean out the crud.

(I guess you know your software has “made it” when someone else writes a piece of software specifically to attack it.)

John Gruber drops, in his accessible, accurate style, some knowledge about The Safari Shell Script Execution Exploit (for reference, here’s the Internet Storm Center’s take on the vulnerability). The exploit, in essence, is a combination of a dangerous Finder feature and a lack of user feedback about that feature. One of Gruber’s suggestions to Apple is to explicitly tip off the user when a JPEG file is configured to “Open With” some other application:

Apple should consider addressing this in the Finder, by, say, adding some sort of visual treatment around application icons, which would provide some measure of warning for malware apps posing as documents — if there were some sort of halo around applications and you saw such a halo around a malware app posing as a JPEG, you’d have a visual indication that it’s not really a JPEG.

My initial reaction is that a halo doesn’t tell you what’s wrong with the file, just that something’s wrong. It’s the UI equivalent of a string around your finger: only useful if you remember (or ever knew) what the string was for. And don’t forget that, sometimes, the user has deliberately chosen a non-default “custom opener” application for one of her files; we don’t want to put “DANGER! DANGER!” stripes on that icon. The indicator should be meaningful enough to indicate a surprising (and possibly dangerous) state of affairs, while not implicitly damning a state the user is aware of.

In other words, we need to tie a string on the user’s finger, but we must also attach a tag at the end of that string. Apple’s icon design guidelines give us a clue as to what the tag might be:

Traditionally, a document icon looks like a piece of paper with its top-right corner folded down. As previously suggested, Aqua document icons should make it obvious which application they are associated with. Preview documents, for example, include a graphic of the media (the pictures) used in the application icon. For simplicity and to avoid confusing the document with the application itself, the viewing tool is not repeated in the document icon.

In the case of docs with custom openers, the potential deviation between the document and the application is exactly what we want to highlight. Apple’s HIG, which advises against sticking the app in the document icon, works in our favor here, because we can unambiguously signal that Something Is Different About This Document by our inclusion of the app icon as its own badge. Here we go:

In this quick and dirty mockup, I make explicit use of Apple’s strong warnings against including the application’s icon at all, as well as adding a badge as an overlay rather than an integrated design element. Normal icons should have neither of these features, which is why this design works so well: it screams, this is not a normal icon. It has the icon of an application (perhaps an unexpected one!) applied as a badge; furthermore, that badge is a floating overlay, further underscoring the fact that the presence of a custom opener is exceptional and not intrinsic to the document type.

Discuss.

This is just to say: I’m travelling (for work) for the next few days. Reachable by email, naturally.