LWN.net Weekly Edition for January 26, 2012

LCA: Jacob Appelbaum on surveillance and censorship

Talks at linux.conf.au often cover a wider range of topics than those held at many other Linux-related events, and LCA 2012 was no exception. The final keynote at this conference was from Jacob Appelbaum, a lead developer of the Tor project. This no-holds-barred session took an uncompromising look at surveillance and censorship and the people behind them. It was a strong call for action - and for more free software - from a courageous man who clearly lives by the words written on his T-shirt: "be the trouble you want to see in the world."

We live, Jacob said, in a surveillance society. We don't really live in independent states anymore; instead, we live in different surveillance cones on a surveillance planet. Increasingly, the world resembles the Panopticon, a prison designed in 1786. Anybody who thinks otherwise need only look at, for example, the widespread warrantless wiretapping of US citizens with AT&T's help under (at least) the Bush administration. We are, indeed, being watched.

There are a number of coping strategies that we all adopt in the face of this kind of surveillance, starting with the specious claim that "I have nothing to hide." The fact that the attendees decided to put clothes on before going to the conference that morning (a decision your editor, at least, much appreciates) demonstrates otherwise. Or we say that yes, people are watching, but bad things will never happen to us personally. Which is a fine position until something does happen.

The problem with this kind of surveillance structure, according to Jacob, is that "it attracts assholes." Once this machinery is put into place, it will be put to bad uses regardless of its original intent. For example, the "Echelon" spy network was put into place as part of the cold war, but it was also alleged to be used to, for example, funnel information to Boeing to be used to win aircraft orders.

Many (or most) countries allow for "lawful" interception of some communications by governments without a warrant. Traffic data for phone calls or text messaging, for example, falls under this umbrella. It's said not to be "content" that requires a warrant to access, but it still tells a story about a person and will be abused by governments. We need to make it harder for governments to get at this data.

But it gets worse. The switches at the core of the phone system and the Internet all have governmental backdoors built into them. Sometimes those backdoors are more widely used than intended; Jacob recommended reading The Athens Affair, an IEEE article about the use of surveillance backdoors to spy on the Greek government (and many others). These backdoors are an attractive target, to the point that the operators of these systems should think hard about what their lives are worth; the man in charge of planning the Greek Vodafone-Panafon network died suspiciously as the compromise of that network was discovered.

Jacob played a video advertisement for the "FinFly" device, meant to be installed in an Internet provider's equipment rack. The FinFly is a highly capable man-in-the-middle attack device, able to pick out traffic associated with specific targets, record it, and even install malware on the target's systems. This device, sadly, is built on top of the Backtrack-Linux distribution. Among its customers was the former government of Egypt, which used it against pro-democracy activists there. Jacob does not want to live in a world where governments can do things like that.

FinFly is just the beginning; there is a whole range of products designed to meet the needs of the surveillance state. Quite a bit of information about this particular area of commerce can be found in the Spyfiles release from WikiLeaks. There is a lot of money to be made in surveillance equipment, but the companies involved should be held culpable for the uses to which that equipment is put.

Pervasive surveillance allows the government to put together a picture about almost anybody. That picture is based on facts, but may still not be true. But it is useful for the purposes of control, enforcement of power structures, and harassment. Jacob knows that latter aspect well, having been detained several times, threatened with jail, and subjected to seizures of his electronic equipment.

Along with surveillance goes censorship - the determination by people in power that there are things they do not want others to know. Practices like Internet filtering are designed to promote ignorance and retain power. It's done in lot of different ways. There is the famous great firewall of China, which, he said, is more of a spider web catching those who try to stray beyond the boundaries. In the US, censorship is accomplished through "legal threats and illegal tactics." In Lebanon, the national firewall uses a version of squid - a good thing, Jacob said, since they haven't gotten around to patching it for a long time. In Syria, off-the-shelf products are used. And so on.

Not all censorship is equal, and it is often easy to bypass. But censorship, combined with surveillance, often leads to self-censorship. The net was not built to make us fear our own state, but that is what is happening. When a company like Google is frightened by a law like SOPA, we should all be scared; Richard Stallman's The Right to Read was not meant to be a manual. History has shown us over and over again that people with power will turn into thugs. The Stanford prison experiment also demonstrated that quite clearly. With so much experience in this area, why is it that we keep repeating the experiment?

The good news, according to Jacob, is that we have the power to change things. And, in particular, we can challenge surveillance and censorship with anonymity. The American revolution was fueled by anonymous pamphlets that could be circulated without their authors ending up in prison. We need the ability to distribute anonymous pamphlets in this century as well.

So what can we do? We need to reframe the issues so that freedom and openness come first. We need to observe - and report on - surveillance and censorship on the net. We should write more free software and get more people to use it, and everybody writing software should be thinking about their users' freedom and security. Free software needs to be free as in freedom, though; "open source for business" is not the same thing. He looks forward to the day when the only binary blob running on his system is the government rootkit.

Tor is one piece of the puzzle, certainly, but there are others. Jacob mentioned TextSecure, which allows encrypted text messaging between Android phones, as an important piece of freedom-related technology. He also called out FreedomBox, the GNOME project, the Ada Initiative (what does freedom mean, he asked, if half of our population is oppressed?), and the Electronic Frontier Foundation.

In the end, he said, it comes down to freedom for everybody - no exceptions. But that is not how the surveillance state works. Securing that freedom will require a dedication to open standards, open designs, free software, free hardware, and decentralization. We can, he said, push back the surveillance state and create for ourselves an accountable government and freedom for all.

[Your editor would like to thank the LCA 2012 organizers for assisting with his travel to the event.]

Comments (27 posted)

An LCA 2012 summary

Your editor is still recovering from his journey home from Ballarat, Australia, where the 2012 linux.conf.au was held. The richness of this event can be seen in the numerous articles already published here; this article will attempt to cover a variety of talks that, for various reasons, did not turn into articles of their own.

Freedom is always a strong theme at LCA, and the 2012 version was no exception. That emphasis tends to be especially strong in the keynote talks, as should be clear from the reports on the keynotes by Bruce Perens and Jacob Appelbaum. Karen Sandler's keynote was just as concerned with freedom and just as noteworthy; it would have merited an article of its own had we not covered some of her topics from another talk back in 2010. Karen retold her chilling story of trying to get access to the source code for an implanted device designed to protect her from abrupt heart failure. Not only is that source not available to her; even the regulatory agency in the US (the FDA) charged with approving the device normally does not review the code. The presence of catastrophic bugs seems guaranteed.

In addition to simple worries about whether the device will work as needed, there is another concern: these devices are increasingly given wireless communications capabilities that allow them to be reconfigured and controlled remotely. To the extent that the security associated with that access can be verified, it seems to be notable mostly in its absence. In other words, implanted medical devices would appear to be open to a variety of denial of service attacks with extreme consequences. Given that some of them are implanted into important people (she named Dick Cheney who, as a result of his implanted device, no longer has a pulse), it only seems like a matter of time until somebody exploits one of these vulnerabilities in a high-profile way. Karen noted dryly that, given the type of people she hangs around with, it would be unwise to expose herself to such attacks; she went out of her way to get an older device with no wireless connectivity.

She pointed out that a lot of other safety-critical devices - automotive control systems were mentioned in particular - have similar problems. The solution to the problem is clear: we need more free software in safety-critical applications so that we can all review the code and convince ourselves that we can trust our lives to it. And that, she said, is why she made the move to the GNOME Foundation. GNOME's work to make free software usable and attractive in current and future systems is, she said, an important part of getting free software adopted in places where we need it to be.

Another theme at LCA has always been represented by the maker contingent: whether it's Arduino, rockets, robots, or home automation, the people who make their own toys always turn out in force at LCA. Notable among a strong set of maker-oriented talks was "Rescuing Joe" by Andrew "Tridge" Tridgell. The challenge here is to make an autonomous aircraft that can search a defined area for a lost bushwalker ("hiker," in US dialect), drop a water bottle nearby (without hitting him), then return safely back to its landing point. This challenge has been run for a few years, but nobody has yet fully achieved its goals; Tridge's team hopes to be the first to succeed.

Getting there requires the design of a complex system involving autonomous avionics, an independent failsafe mechanism that will crash the plane if it leaves the search area, computer vision systems to locate the hiker, mechanical systems to reliably drop the water bottle in the desired location, and high-bandwidth digital communications back to the launch base. The test systems currently run with a combination of Pandaboard and Arduino-based systems, but the limitations of the Arduino are becoming clear, so the avionics are likely to move to another Linux-based Pandaboard in the near future.

This project requires the writing of a lot of software, most of which is finding its way back upstream. The hardware requirements are also significant; Tridge noted that the team received a sophisticated phased-array antenna as a donation with a note reading "thanks for rsync." All told, "challenge" appears to not even begin to describe the difficulty of what this team has taken on. The whole talk, done in Tridge's classic informative and entertaining style, is well worth watching.

Rusty Russell and Matt Evans recently took a look at V6 Unix, as built for the PDP-11, and noted something obvious but interesting: it was a whole lot smaller than the systems we are running now. The cat binary on that system was all of 152 bytes - in an era when everything was statically linked - while cat on Ubuntu 11.10 weighs in at 47,696 bytes - and that is with dynamic linkage. We have seen similar growth in grep (2,190 bytes to 151,056) and ls (4,920 bytes to 105,776). So they asked: where is all this growth coming from, and what did we get for it?

What followed was an interesting look into how Unix-like systems have changed over the years; watching the video is well recommended. Their first observation was that contemporary binaries could be reduced in size by about 30% by using the GCC -Os option, which causes the compiler to optimize for size. In other words, we are paying a 30% size penalty in order to gain some speed; the actual speed benefit they measured was about 9%. But there is a lot more to it than that.

A simple program consisting of a single "return 42;" line on Ubuntu will, when build statically, weigh in at about 500,000 bytes. Rusty and Matt determined that this program, which makes no direct C library calls, was pulling in about 17% of glibc anyway. Even the simplest program, anymore, must make provisions for dynamic loading, atexit() handling, proper setuid behavior, and more. So the program gets huge but, in this case, only about 2% of the pulled-in code actually gets run. In general, they found, most of the code dragged in by contemporary programs is simply wasted space. That waste can be reduced considerably by linking against dietlibc instead of glibc, though.

How much does 64-bit capability cost? An amusing exercise in porting the V6 code to the imaginary 64-bit "PDP-44" architecture increased its size by about 50%; the size difference between 32-bit and 64-bit Ubuntu programs is rather smaller, at about 9%. Use of "modern infrastructure" (that, for example, forces malloc() to be used instead of sbrk() in all programs) bloats things by about 120%. The large growth in features (ls has 60 options) leads to a massive 440% increase in size; they also measured a 20% time overhead caused by rarely-used features in ls. It's worth noting that half of that time cost goes away when running with LANG=C, leading to the conclusion that locales and other flexibility built into contemporary systems has a large cost. In the end, though, these appear to be costs that we are willing to pay.

David Rowe gave a fascinating talk on the development of Codec2, a speech-oriented codec that is able to produce surprisingly good voice quality at data rates as low as 1,400 bits/second. To understand the math involved, one should watch the video. But even without following that aspect of things, the talk is an interesting discussion of the open development of a patent-free codec with interesting real-world applications - sufficiently interesting that it risked being classified as a munition and treated like cryptographic code.

In summary, LCA remains unique in its combination of strongly technical talks, freedom-oriented and hands-on orientation, wide variety of topics covered, and infectious Australian humor. There is a reason some of us seem to end up there every year despite the painful air-travel experiences required. Linux Australia has put together a structure that allows the conference to be handed off to a new team in a new city every year, bringing a fresh view while upholding the standards set in the previous years. With regard to upholding the standards, the LCA 2012 lived up to expectations in a seemingly effortless manner - it was a job well done indeed. They have set a high bar for the 2013 team (Canberra, January 28 to February 2) to live up to.

[ Conference videos can be found on YouTube, in Ogg format, and in WebM. Your editor would like to thank the LCA 2012 organizers for assisting with his travel to the event. ]

Comments (16 posted)

Robots rampage (in a friendly way) at SCALE 10X

"World domination" is a less prevalent theme in Linux and open source discussions these days than it was some time ago, but it still comes up regularly in one field of study: robots. At the 2012 Southern California Linux Expo (SCALE) in Los Angeles, Willow Garage's Tully Foote described the Robot Operating System (ROS) project, an open source stack for state-of-the-art robotics. ROS is in use by industry and academic research projects, often on hardware that runs in the hundreds-of-thousands of dollars range, but it is capable of running on low end and homebrew robots, too. Naturally, the ultimate homebrew device automation option is the open source Arduino, which was also on display at SCALE thanks to Akkana Peck and her flying robot shark....

ROS's universal robots

In his talk, Foote illustrated the need for a common, open source platform like ROS by describing his own background in robotics. As a graduate student, he often lamented the fact that interesting developments described in research papers were nearly impossible to re-implement at a different institution because there was no baseline framework on which to build the new bits. As a result, every research group ended up re-building the same infrastructure in a separate silo, slowing down the pace of useful research. The same productivity hit was evident in the DARPA Grand Challenge; Foote and his teammates saw that virtually every successful entrant ran Linux, but they shared no code. The difference between the teams that completed the challenge and those that failed was "a couple of percent" more efficiency in key algorithms, he said — a tiny amount of time compared to the hours spent constructing and debugging the predictable, underlying base layer.

ROS grew out of those concerns. The idea is to provide a reusable meta-framework that researchers can run on their own robot hardware, taking care of low-level services like hardware abstraction, device control (for sensors, actuators, motors, and other robo-building-blocks), and message-passing, and to offer reusable modules for common services like 2D and 3D object recognition and navigation. Developers can incorporate the libraries they need, then write their own code focused on the area of research interest.

Rather than simply design the system and post the code, however, the ROS team has taken an active interest in cultivating an active community of robotics researchers and code contributors. There is a thorough documentation site and a StackOverflow-style question-and-answer site, plus a bug tracker, IRC channel, and mailing lists. The code is licensed BSD-style, in order to encourage adoption by commercial research groups in addition to academics.

The plan seems to be successfully attracting developers; the wiki lists more than 400 "stacks," which are installable ROS variants tuned for a specific task, hardware configuration, or research project. Many are marked as being maintained by institutions other than Willow Garage. Willow Garage itself is a "long-term incubator", as Foote described it. The team does its own robotics research as well as developing ROS, in the hopes of making a breakthrough someday that will warrant spinning off a startup company.

Architecture and marathons

Structurally, ROS is a collection of processes that communicate via the ros_comm middleware layer. This communication framework is abstracted at the network level, with C++, Java, Python, and Lisp all equally supported for developing modules. There are several message-passing paradigms supported, including synchronous RPC-style services, asynchronous publish-subscribe, and simple data acquisition. Under the hood, ROS is designed to run on Ubuntu (and the official downloads for the current release, "Electric Emys," are packaged only for Ubuntu), although experimental packages are available for other distributions, as well as Mac OS X and Windows.

Robotics research is centered on compute-intensive subjects like computer vision, object-detection, and decision making (rather than simply programming repetitive tasks like car assembly), rarely manageable by a single CPU. Thus, ROS supports grid-like designs it calls "compute graphs" in which multiple slave compute nodes can talk to each other in peer-to-peer style, as well as report back to a master node. Foote described his team's DARPA Grand Challenge vehicles, which in different generations used everything from six rack-mount servers to a trunk full of Mac Minis. ROS can also run on remote compute nodes that communicate wirelessly to a robot — Foote mentioned that an Android application is in development that will allow users to run ROS on their phones to control small, Roomba-like robots.

A Roomba and an Android phone does not make for a cutting-edge proof of concept, however, so Willow Garage set out to develop a state-of-the-art research robot for working with ROS. The result is the PR2, a mobile (wheeled) robot with stereo vision, two manipulator arms with five pressure-sensing fingers on each, and an assortment of rangefinders and other sensors for interacting with the world. The PR2 is powered by sixteen i7 cores, and has a $400,000 price tag (although Foote said the company offers some level of discount for open source projects).

Foote played videos of several demonstration projects that Willow Garage undertook, which are available at the bottom of the PR2 page. They included training the PR2 to "run" a 26.2 mile marathon (a problem that seemed to focus largely on teaching the PR2 to notice when it was running low on battery power, find an outlet, and plug itself in to recharge), play pool, and fetch and open bottled beer (determining the brand by visually scanning and interpreting the labels it finds in the fridge).

Nearly half a million bucks is a hefty bill by most standards, but Foote said there are around twenty PR2 units in the field — and that together they result in the publication of more than 100 research papers every year. The ROS community as a whole has expanded the number of software packages available from the initial 200 to more than 3000. Luckily, ROS runs on a range of other robot hardware, including several inexpensive options like the LEGO NXT and Willow Garage's new offering, the TurtleBot. TurtleBot is based on an iRobot Create, augmented with an ASUS netbook, a Microsoft Kinect, and various other sensors. TurtleBot kits are available for between $400 and $1400 (US), depending on how many of the off-the-shelf components are included.

The DIY approach

Foote's talk and PR2 videos wowed the crowd (which strained the capacity of the session room), but so did Akkana Peck's live demonstration of Arduino development in the "Fun With Linux and Devices" talk. Peck described herself as an circuit-building novice, emphasizing that Arduino was a simple way to get into the world of programming hardware devices and robots even for those inexperienced with IDEs and soldering irons.

Peck began with an overview of the Arduino itself, including digital and analog I/O, programming via USB cable, and the various options for power (USB-supplied, battery, and AC adapter). She then explained the Arduino software environment and how to compile and upload code. "The first project is always making the LED blink," she said, "which is a lot more exciting than it sounds when you finally get yours to blink."

From the blinking LED, she gradually increased the complexity of the projects, including how to interface with devices that draw more power than an Arduino can safely handle, how to read from sensors, and how to write Python code that interfaces with the Arduino's I/O pins — thus allowing the user to monitor and control devices. Along the way, these examples included several live demonstrations, including linking the blinking-LED signal into a series of desk lamps and Christmas tree lights, creating a functioning oscilloscope, and an echolocation rangefinder.

But those projects were only the lead-up to the main event, Sharkduino: controlling an "Air Swimmers" flying shark from a Linux box. Air Swimmers are helium-filled balloon toys with motorized tails and adjustable ballasts, and can be flown using an infrared remote controller. They are also inexpensive, which makes them a tempting target for an Arduino automation project. In addition, the infrared controller is more limited in functionality than a typical radio-controlled airplane or helicopter, making it ripe for hacking. Peck said she considered attaching a small Arduino directly to the shark, but ultimately chose to connect to it via the remote in the interest of making flying-shark-run-amok a less likely outcome.

The project involved dissecting the infrared remote, getting help from the Arduino community on what sort of circuits to attach to the remote control's switches, and writing a Python application to run on the desktop. The end result allows the user to fly the shark by moving the mouse up, down, left, or right. It may not shoot lasers yet (to Dr. Evil's certain dismay), but "Bruce" (as the shark is evidently named) was still a hit with young and old alike in the audience.

Along the way, Peck included tips on where to find Arduino components, how to ask for help from the Arduino community, and how the platform compares to BeagleBoard, RaspberryPi, and other rapid-prototyping products. All of the code demonstrated in the session (including the Sharkduino application) is available on Peck's personal web site, along with the session slides.

Penguin overlords not far behind

In some ways, ROS and Arduino could not be further apart. ROS is developed (although not exclusively) on expensive specialty hardware, while Arduino boards come as cheap as seven dollars (thanks to the open hardware plans). ROS is designed for complex, compute-intensive tasks, while Arduino is designed to be as simple as possible. But in the more fundamental sense, they serve the same goal: to provide a reliable, common platform on which others can experiment and innovate. Neither could accomplish that as effectively if they were proprietary, closed-source projects.

Willow Garage's TurtleBot promises to bring brainy robotics to the hobbyist market (while giving those hobbyists the same reliability and service that research institutions already enjoy), which should have an interesting effect on the ROS project and its community. And if the thought already occurred to you that a low-cost ROS robot outfitted with an Arduino-controlled sensor board sounds like an intriguing platform for exploration — why yes, there are several modules to do exactly that.

Comments (4 posted)