Mythology about security…

Ed Felton tweeted a few days ago: “Often hear that the reason today’s Internet is not more secure is that the early designers failed to imagine that security could ever matter. That is a myth.”

This is indeed a myth.  Much of the current morass can be laid at the feet of the United States government, due to its export regulations around cryptography.

I will testify against the myth.  Bob Scheifler and I started the X Window System in 1984 at MIT, which is a network transparent window system: that is, applications can reside on computers anywhere in the network and use the X display server. As keyboard events may be transmitted over the network, it was clear to us from the get-go that it was a security issue. It is in use to this day on Linux systems all over the world (remote X11 access is no longer allowed: the ssh protocol is used to tunnel the X protocol securely for remote use). By sometime in 1985 or 1986 we were distributing X under the MIT License, which was developed originally for use of the MIT X Window System distribution (I’d have to go dig into my records to get the exact date).

I shared an office with Steve Miller at MIT Project Athena, who was (the first?) programmer working on Kerberos authentication service, which is used by Microsoft’s Active Directory service. Needless to say, we at MIT were concerned about security from the advent of TCP/IP.

We asked MIT whether we could incorporate Kerberos (and other encryption) into the X Window System. According to the advice at the time (and MIT’s lawyers were expert in export control, and later involved in PGP), if we had even incorporated strong crypto for authentication into our sources, this would have put the distribution under export control, and that that would have defeated X’s easy distribution. The best we could do was to leave enough hooks into the wire protocol that kerberos support could be added as a source level “patch” (even calls to functions to use strong authentication/encryption by providing an external library would have made it covered under export control). Such a patch for X existed, but could never be redistributed: by the time that export controls were relaxed, the patch had become mostly moot, as ssh had become available, which, along with the advent of the World Wide Web, was “good enough”, though far from an ideal solution.

Long before the term Open Source software was invented, open source and free software was essential to the Internet for essential services. The choice for all of us  working on that software was stark: we could either distribute the product of our work, or enter a legal morass, and getting it wrong could end up in court, as Phil Zimmerman did somewhat later with PGP.

Anyone claiming security was a “failure of imagination” does not know the people or the history and should not be taken seriously. Security mattered not just to us, but everyone working on the Internet. There are three software legacies from Project Athena: Kerberos, the X Window System, and instant messaging. We certainly paid much more than lip service to Internet security!

Government export controls crippled Internet security and the design of Internet protocols from the very beginning: we continue to pay the price to this day.  Getting security right is really, really hard, and current efforts towards “back doors”, or other access is misguided. We haven’t even recovered from the previous rounds of government regulations, which has caused excessive complexity in an already difficult problem and many serious security problems. Let us not repeat this mistake…

 

 

Apple Patents Portrait-Landscape Flipping: the patent system is broken…

I noticed with interest Slashdot’s article last week on Apple Patenting Portrait-Landscape flipping based on control of one or more accelerometers in Slashdot last week.  As I work at Bell Labs these days, I don’t read patents, so I’ll just go on the summary I read there.

Here’s some prior art from June 2001.  In that period, at Compaq/HP’s Cambridge Research Laboratory, we had ported Linux to the iPAQ handheld (with touch screen & expansion capability). Colleagues of mine, including Jamey Hicks, Andy Christian, Frank Bomba, Ben Curis had built an expansion pack for the iPAQ, called the BackPAQ (just like Apple has an I fetish, Compaq had a paq fetish and liked “i”s as well), with accelerometer, camera, and additional expansion capability including additional battery, for our (and other’s) research as part of “Project Mercury”; it was obvious that such devices would become standard in short order, but no device at the time had them integral. Quite a few BackPAQ’s were built and distributed to researchers around the world (small number of hundreds, if I remember correctly). We wrote some papers, distributed a bunch of BackPAQ’s to like minded researchers around the world, and demonstrated the code at the Usenix conference and elsewhere, and published all the code on handhelds.org (which seems down at the moment). The probability of Apple employees having seen this device and it rotating the screen is an absolute certainty; not only did we show the BackPAQ off at numerous conferences, but we built significant numbers used at universities.

It was blindingly obvious to us that hooking up the accelerometer to be able to rotate the screen would be “a good idea”.  Keith Packard and I wrote the xrandr X Window System extension specifically to support screen rotation, for the iPAQ handheld using his TinyX driver (the X extension then became a standard part of the X Window System releases in X.org).  I wrote (in an hour or two) the first version of the xaccel daemon that took the accelerometer data and controlled the screen rotation.  I first packaged it (in ipgk format, for the iPAQ Familiar Linux distribution) on June 11, 2001 to enable the code’s distribution. Ironically, I like what I remember of xaccel’s behaviour better than what I now see on the iPhone and the iPad I own.

Since I can’t go reading Apple’s patent itself, I’ll just note:

• This is a handheld device, with 802.11 wireless (later versions of the iPAQ became phones).
• It has a touch screen
• It has an accelerometer in the BackPaq
• It used the data from the accelerometer with simple heuristics to control the orientation (portrait or landscape) of the screen (in this case, running the X Window System

Now, maybe you’d like to quibble and claim the idea of putting an accelerometer in a hand-held device is non-obvious.  I think it was pretty obvious, myself, and doing that goes to the group working on Project Mercury. I don’t remember any patent being filed there. And having done so, it seemed obvious to hook it up to the screen. I know we did not file any patents. Are either of these ideas worth a patent? Personally, I think both ideas are pretty obvious, the first idea more original than the second.

But I’m sure the first handheld device with touch screen, with accelerometer, rotating the screen under control of that accelerometer was in my hand running my code below, sometime in the year 2000 or 2001 (I haven’t tried to excavate the exact date),  and that it was widely published on the Internet and used by hundreds of people.

Since handhelds.org seems down at the moment, I spent 5 minutes digging around for the code itself elsewhere.  It’s short enough I include it below (looks like the copyright notice got cut and pasted from the xrandr code); it was called xaccel.c, strangely.

Update 1:

Comments make it clear I fired before aiming carefully: the patent at question apparently is on multitouch gestural overrides to accelerometer screen flipping, apparently. If so, my apologies to Apple.

We have three problems here:

1. prior art, which may not apply to my example certainly we did not have a multi-touch screen to play with and did not explore that area.
2. Obviousness may be in the eye of the beholder, but certainly I’ve seen ideas which were non-obvious. The current broken patent system is encouraging filing of patents just for protection of every trivial idea, and to use as weapons against competitors, whether there is merit in them or not.
3. the treble damages problem, which is why I did not go read the patent in the first place, and stifles actual innovation (independent of whether you thing software patents are a good or bad idea, being unable to know what is going on elsewhere defeats part of the original bargain of why patents were granted in the first place.

And I still like my algorithm better than what I experience on the iPad, which often flips the screen when I don’t want it to flip and begs out for overriding.

Update 2

Jaharks of CMU in a comment below notes that the Itsy folks did gesture based screen rotation on the Itsy.  Quite a few Itsy‘s (the spiritual predecessor to the iPAQ, and to my knowledge the first handheld device to run Linux, and the inspiration/cause of our handhelds.org work) were built and distributed to universities, along with the source code.

So they don’t pass unnoticed…

Those of you who run the X11 owe a debt to Smokey Wallace, who died recently of cancer, though you may never have known him. Without him, it is not clear that X11 would have ever existed: he and I drafted a memo that proposed developing X11 in Digital’s WSL and making the result freely available, as X11 would require more resources than we had available at MIT.  This was one of the seminal moments in free and open source software, though few know of it.

Also John Huchra died; he was also one of the “good guys”.

Another fork, at last….

My thoughts go out to the LibreOffice people at this moment in their efforts; it is a fragile time, and I wish them all the success in the world, and hope that Oracle learns from its recent mistakes. This seems unlikely, however.

Oracle has not yet learned the deep truth evident in Star Wars (or from observing Sun over the last decade):

“Leia: The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.”

The ultimate freedom of free software is not those most commonly observed: it is the freedom to fork the code, project and community in extreme circumstances.  This is the ultimate check on abuse of power of a copyright holder of free software: if the software matters, it will eventually be forked.

The process of doing such a fork is long and arduous.  I have lived the ultimate irony of having to fork the X Window System back to being a community project some years ago, while being one of its original creators.

If Oracle does not learn from history, maybe it’s James Gosling’s turn next, with Java.  Now that would be interesting….

Time to Lead….

The free desktop has been in “catchup” mode: catching up to first Windows and now nipping at the heels of the Mac.  Our path has been obvious to date. In some areas, our technology and applications lead; in others we still lag. From here on, progress becomes much less clear, though I’ll bet on the moving herd and natural selection of free software over directed closed commercial development any day.

How now to move from such a reactive strategy to true leadership in all areas? How do you set strategy, when our very culture is that of serendipity, discovery, sharing of ideas, and creation? where a single vision cannot rule?

I recently attended the UIST conference, and discovered there was essentially no overlap between the research community and our own. The conference (in free software terms) was expensive and much was uninteresting to me personally (though most would be interesting to someone in the free desktop community). But a couple of gems at UIST were there that made the trip worth while. For me, it was OctoPocus. For you, it will likely be something else.

For another concrete example, the Facades work built on Metisse is not well known in our community. I highly recommend watching the videos you find at those web sites. Facades, published several years ago, combines at-spi and composite to do things that aren’t possible anywhere else. You too, could edit the gimp in real time to have the UI you want! Peter Korn only became aware of Facades last week, after I had stumbled across it while investigating other work. My jaw dropped.  Peter’s jaw dropped. Please add your jaw to the collection on the floor. We could have deployed this by now! But we did not know it existed!

Dan Olsen notes in “Evaluating User Interface Systems Research“:

“This search for fatal flaws is devastating for systems research. It is virtually impossible for a small team of researchers to recreate all of the capabilities of existing systems or to completely examine all of the eventualities of new concepts. The farther such a team reaches into new territory the more compromises will be required and the more supporting ideas must be left unresolved.  If a new systems approach is attempted, the omissions of some important feature is guaranteed. The existence of a fatal flaw is a given. If the evaluation of the work is focused on “what does it not do” no research system will ever pass. Flaw analysis will frequently be a barrier to new systems research.”

As a result, UI systems research has stagnated due to combined effect of the middleware of the UI stack being closed (or in our case, until the recent flowering of the free desktop undid more than a decade of stagnation) and this effect.  Many good ideas of all kinds have been explored from hardware, to window system UI ideas, to UI ideas for specific classes of applications. But there is much less proof of which ideas actually works in a real system, for the reasons Dan lays out.  The resulting research experiments are usually “toy” systems, and toy applications, built in the limited environment of MacIntosh and Windows where much of the system is off-limits.  The research community has neither the resources nor (if they work on Mac and/or Windows) the ability to make advances “real”.  But we do! We have the resources, the open system, and the ability to and desire to innovate.

Our fundamental advantage we have is the ability to experiment  and modify all areas of the stack; from hardware, to the window system, though toolkits to applications.  Just as compositing has allowed a thousand flowers to bloom (most of which stink, but we’ve picked some that smell pretty sweet) in eye candy, accessibility and in other areas, compositing and other modern free software technologies can be used in new an unexpected ways. We are able to perform experiments, and have a large audience to test the experiments radically faster than commercial software.  Nice as the Web is, there are just some things you can’t do in the web until the underlying technologies have support.  20 years of frustration in the UI research community shows that pushing from research to commercial vendors does not and cannot work at more than a glacial pace. Let us pull people to free software by out innovating and becoming the system with the best user experience, by pulling with the best ideas of free software and research innovation.

How to lead?  I think some of what is going on now (e.g. the work to bring  journals to avoid file management among others) are fundamental.  But there are also almost 20 years of ideas lying fallow since the first flowering of UI work in the 1980’s. By mining research for the best ideas, fostering collaboration with researchers when possible, and combining with your own good ideas and production code now on millions of desktops, we can accelerate our progress.

Thankfully, the ACM is becoming more enlightened: conference proceedings and videos once locked up are now available. (Dan Olsen points out that videos done later found on the researcher’s web sites are often better than those presented at the conference; due to an oversight, the UIST 2008 videos are not yet up). The proceedings of UIST is one good place to start for the free desktop community. There is a list of other ACM conferences on many other topics. Go see which ideas are worth grabbing and running with!

This is a two way street: I had great fun demonstrating Compiz Fusion and some of our eye candy (as well as showing videos of Facades and Metisse) to a number of UIST attendees, who had been unaware that the free desktop had advanced beyond the commercial state of the art, already solving in a real system, problems they could not solve in their “toy” research prototypes on Windows and Mac.  When you have a chance, this is also very worth while: the more bright people working on free software, the better.

But it is up to you to figure out which ideas are good, which are bad (and why), which ideas really work, recombine them with your own great ideas, and get them into people’s hands (both literally, and on the desktop)!