Inspired by the cover of Newsweek’s now notorious return to print, I made a couple of bitcoin masks for mysterious Satoshi cosplay. In case it’s not obvious, that’s the bitcoin B on its side—a great look.
We actually made more than one mask. I think I like the one above, opera-glasses style, but there’s a flexible version that’s extra sparkly with elastic, too.
In order to serve its purpose at all, encryption and secure communications software has to be single-mindedly dedicated to protecting and promoting its user’s interest. In the real world, that dedication can be subverted in a handful of ways. Broadly speaking, these failures can come from with technical problems, or from the developer’s interest being misaligned with the user’s.
The Freedom of the Press Foundation, which is currently raising money for a handful of important secure communications projects, published a blog post Thursday about the need to give financial support to open-source encryption tools. It’s a good post, and a vital effort, but it focuses only on the second class of failures.
Part of the issue is that the term “open-source” is doing more work here than it’s able: yes, software has to have the technical robustness and verifiability that comes with access to the source code, but it can’t stop there.
Access to source code is important for any program you’re going to trust, but for a security or encryption program it’s essential, for two related reasons. One: if the program doesn’t adhere to Kerckhoff’s principle, it’s vulnerable to bad actors busting through the obscurity on which it depends. Two: in the spirit of Linus’s Law, eyeballs on the source code may be the best hope for finding bugs.
But beyond any kind of licensing questions, users need to know they are actually running the software described by that source code. That affects a whole range of things that aren’t dictated by the license. Software source and binaries both need to be distributed securely—an area in which we are really horribly failing. Builds need to be verifiable, and currently only a small handful of projects promise that. Source code needs to be documented and tested, not just available to read. These are the kinds of technical guarantees that encryption tools need to make—not just access to source code.
These are reasons enough to reject software for encrypted communications that doesn’t follow these practices. But as is often the case, alongside these technical requirements is a need for software that actually respects the user’s freedom. For that reason, despite the fact that it might raise confusion about funding models, I think we should demand that our security tools are not just open-source, but are free software.
Fundamentally, the Foundation’s blog post talks about how commercial proprietary software has interests that are out of alignment with those of their users. That’s absolutely correct, and the efforts to raise money for better services is a good way to address that problem in the near term.1
But while “open-source” is a nice proxy to describe that kind of alignment, it doesn’t quite do the trick. Releasing source code doesn’t make software respect its users, and operating for profit doesn’t necessarily mean a software company will cut corners on security concerns or turn to surveillance as its business model. Really, beyond a threshold of technical competence, the meaningful axis is commitment to user freedoms, and only free software delivers on that.
It’s like the problems with that old tired phrase, “If you’re not paying for it, you’re the product.” Sometimes you’re not paying for something because it’s been released free into the world; sometimes you’re paying for it and they’re still selling you out.
We can and should support open-source encryption tools. The Freedom of the Press Foundation’s current bundle is a great way to do that—and in fact, all of the tools it supports are free software and set a high bar for respecting users. (Full disclosure, I donated early on in this cycle.) But most importantly, we should support and promote tools that respect our freedoms.
A couple of years ago, Jake Appelbaum and Dmytri Kleiner had a great conversation about this at Republica in Berlin. I’ve been meaning to snip out the best bits for a while. ↩
The New York Times launched a major redesign last month and, as is the way with these things, got a bunch of angry comments from pitchfork-wielding Times readers who wanted to be able to print articles with a single click instead of two. And though public editor Margaret Sullivan claims to have sifted through though thousands of comments, my one little nitpick hasn’t been addressed.
For years the Times has had a hidden feature called “Emphasis,” which would allow readers to click shift twice and then highlight and deeplink to individual sentences and paragraphs. It’s really great for a site like the New York Times to be able to pick out one well-reported detail in a longer piece and direct people’s attention directly there.
I liked it so much I found a WordPress plugin that incorporates the feature and added it to this blog. I am skeptical that anybody has ever used it here, but it’s been an option. (You can try it out by clicking shift twice.)
In any case, Emphasis is gone from the new redesign, and as far as I can tell hasn’t been mentioned since. The technical recap describes a ground-up rewrite, and it probably was just not a priority. I suspect it was never a very popular feature, but I, for one, miss it.
Today I got a chance to check out the last day of the Ex Postal Facto conference, made up of a few panels at the San Francisco Public Library. The conference was dedicated to mail art, and today’s panels featured a handful of people that have been in that scene for decades, including these two:
Those are pictures I took today of Anna Banana and Lowell Darling. (I added Anna’s to her existing Wikipedia article, and created a new one for Lowell.)
I wasn’t really familiar with mail art at all and after today I feel like I’ve been missing out. But you could hardly get a better introduction than the one I had today: incredibly friendly leaders of the community having a great time meeting in person and sharing stories about the 40+ year history of the art movement.
Actually, it felt a lot like a hacker conference, but for a totally different community.
Speaking of hacker parallels, I was struck by how the timelines of the mail art community and the golden age of phone phreaking lined up. It’s really striking because in neither case was it really facilitated by new technical developments. Rather it was just people digging in and really exploring the communications networks they were using.
I had a great time and plan to dig more into mail art in the next few weeks. One fun project might be to try to find a cheap pinhole perforator to make artistamps—or to fashion one out of an old sewing machine.
We had a keysigning party at work today, and after it finished a few of us were looking for a way to visualize the newly increased signature density. It turns out the best tool for the job is called sig2dot, which is available in the Debian repositories (and as a Perl script on its homepage).
Just make sure your keychain is refreshed with the most up-to-date keys (that’s just gpg --refresh-keys), and then run the script to create a file in the DOT language. I had to download the script itself, so I ran:
$ gpg --list-sigs | ./sig2dot.pl > keyring.dot
Then, you can use one of a number of programs to render a visual file out of keyring.dot. If you have the package graphviz installed, you can use its dot command, or the neato command, which behave differently. Here are examples from my own key ring of the two programs in action:
$ dot -Tpng keyring.dot > keyring.dot.png
$ neato -Tpng keyring.dot > keyring.neato.png
In both cases, I’ve reduced the size of the graph a lot intentionally so the names are unreadable, but I’m looking at them locally at full size. In each case I’m the bright pink node in the middle. In the second graph, the keysigning party is clear as the dense patch in the top.