Generally-accepted practice for verifying the identity of other cryptography users and extending your web of trust to them usually involves checking a government-issued photo ID, verifying that the picture is the person giving you the key fingerprint, and then verifying that the name on the ID matches the name on the PGP key that you are going to sign. The purpose of this is to know that, when you encrypt to that key, only the person you think is receiving the mail can read it, and that signatures from that key come from the person who claims to use it. It allows you to associate the cryptographic key with a person.

In the present era, where state-level adversaries are on the top of many security-conscious users’ minds, isn’t this a hole? Aren’t we depending, critically, on the very entity we are trying to protect ourselves from?

I don’t think this is a significant weakness, though. To understand why, let’s first consider exactly what attacks would be enabled by the government misusing its identity-certifying authority. It allows them to compromise key exchanges. That is it. Specifically, if Alice and Bob want to exchange key fingerprints, what Proconsul Eve can do by forging an identity document is to substitute her operative Albert, with government-issued documents certifying he is Alice, at the meeting. The result is that Bob will have thought he verified that Alice’s key actually belongs to Alice, when in reality the private key is held by Eve. So when he talks to Alice, he’s really talking to Eve.

Once the key exchange is done, however, Alice and Bob have no need for government-issued ID. They have securely exchanged keys, and Eve cannot fake an exchange to substitute her own keys. The only thing that can be done by issuing an invalid ID card is to compromise the initial key exchange.

So you have a new research question. You’re reading a paper, or a book, or a news article, and a hypothesis forms in your head. Or you have a new idea for resolving an important conundrum in your research.

What do you do?

In startup and business culture (or certain segments of it, at least), there is the concept of the minimum viable product. This is basically the smallest version of a product, stripped down to its barest essentials, to see whether it would gain traction in the market. Create a minimal product and iterate quickly instead of spending a year building something that might not take off.

I think this concept is instructional for research. Minimum viable research would be to ask yourself: what is the simplest thing I can test to see if this idea might go somewhere? Rather than spending a week doing data analysis, is there a 1—2 hour way to see if it might work, or if it is trivially falsifiable? Can you structure your research inquiry so as to fail fast, to not spend excessive time trying to fit a model that just won’t work?

Patrick Volkerding released Slackware 14.1 yesterday. Yep, Slackware is still alive and kicking.

Many years ago, I first encountered Slackware. I was in junior high, and had been using some GNU tools on Windows via DJGPP, but I read about ‘GNOME’ and wanted wanted to try this Linux thing. So I convinced my dad to let me install LoopLinux on the family computer (a 120 MHz Pentium from Gateway 2000).

LoopLinux was a Linux system that ran from a single file on your DOS or Windows filesystem. The installed system consisted of the filesystem file, kernel, initrd, and LOADLIN; it would boot the kernel, mount the DOS filesystem, and mount the Linux system as a loopback filesystem. Once installed, LoopLinux used Slackware packages.

We only had dialup at the time. I stayed up all night the night I downloaded LoopLinux; I’d sleep for an hour or two on the living room couch, then wake up and go check the downloads and see if I needed to start another of the files downloading.

From Twitter this morning: writing tips for academics. Prof. Feamster’s advice in that column is excellent. I would just like to add one thing that I have found very helpful in my own writing: think about what the paper — and each section of it — need to accomplish.

Software engineers are familiar with the concept of requirements: when designing a program, it is important to understand what its users require it to do. If you do not know what the program is supposed to do, and how it relates to the things around it, it is difficult to write a good program. Indeed, it is difficult to even know what a good program would be.

I apply a similar idea to my writing. There are many times when I do not necessarily think about it explicitly. But when I get stuck on a section of a paper, I often find it helpful to think about what that section is supposed to accomplish. I even think about it like a software module: its prerequisites or dependencies (i.e. the things it assumes previous sections have stated or set up) and its outputs (the things later sections will assume it will have done). If I spend 5 minutes writing down what the section has to say, it is often easy to finish drafting the section.

I personally find this more useful than deep outlining. Many people like to outline down to the paragraph level, writing out their paragraph topic sentences. This is good advice, and likely helpful to many writers. But for my own writing, I have difficulty thinking in that way. I find it more useful to outline the sections and subsections of my paper, and then start thinking about each section’s requirements. Sometimes, these requirements may turn directly into paragraphs; other times, they may be merged or split or interwoven. But they’re still useful, and they give me something concrete to think about as I go to implement the ideas with prose.

Those of you in the Introduction to Recommender Systems MOOC may have noticed that I am always in a blue button-up shirt. You may or may not be asking ‘does he have any other shirts?’

I do. I primarily wear the blue shirt in the studio because the video producers have advised us against wearing white (the lights reflect off of white shirts to create a disturbingly angelic glow).

If you’re around GroupLens, or the CS department, you may have noticed that I am (almost) always in a white button-up shirt. You may have asked ‘does he have any other shirts?’, unless you are also in the MOOC, in which case you know I at least have a blue shirt.

Several months (or perhaps a year) ago, Jennifer and I embarked on a plan to standardize my wardrobe. We see minimalism as a useful tool for living the kind of life we want, and a number of minimalist writers we have read have a standard outfit. Also, deciding what to wear in the morning is a pretty low priority with respect to the rest of what I have to do, resulting in wasted decisional energy.¹