March 29, 2008

ICD for home computer security

Ph.D. student Rick Wash and I are applying ICD design tools to the problem of home computer security. Metromode (online magazine) recently published an article featuring our project.

One of the major threats to home computers are viruses that install bots, creating botnets. These bots are code that use the computer's resources to perform something on behalf of the bot owner. Most commonly, the bots become spam sending engines, so that spammers can send mail from thousands of home computers, making it harder to block the spam by originating IP (and also saving them the cost of buying and maintaining a server farm). Bots, of course, may also log keystrokes and try to capture bank passwords and credit card numbers.

The problem is crawling with incentives issues. Unlike first generation viruses, bots tend to be smarter about detection. In particular, they watch the process table, and limit themselves to using CPU cycles when other programs are not using many. That way, a normal home user may not see any evidence that he or she has a virus: the computer does not seem to noticeably slow down (but while they are away from the machine the bot may be running full tilt sending out spam). So, the bot doesn't harm its host much, but it harms others (spreading spam, the bot virus itself, possibly other harmful activity like denial-of-service attacks on other hosts). This is a classic negative externality: the computer owner has little incentive (and often little appropriate knowledge) to stop the bot, but others suffer. How to get the home computer user to protect his or her machine better?

We are developing a social firewall that integrates with standard personal firewall services to provide the user additional benefits (motivating them to use the service), while simultaneously providing improved security information to the firewalls employed by other users.

We don't have any papers released on this new system yet, but for some of the foundational ideas, see "Incentive-Centered Design for Information Security", ICEC-07.

Posted by jmm at 09:44 AM | Comments (0) | Permalink »

May 19, 2006

Volunteer grid computing projects

Most people have heard of SETI@Home, the volunteer distributed grid computing project in which computer owners let software run on their machine when it is idle (especially at night) that helps search through electromagnetic data from space in an effort to find communications from extra-terrestials. But this is only one of many such projects; over a dozen are described in "Volunteer Computer Grids: Beyond SETI@home" by Michael Muchmore, many of them devoted to health applications.

Why do people donate their computer cycles. At first glance, why not? These programs, most of which run BOINC (Berkeley Open iNfrastructure for Networked Computing), are careful to only use CPU cycles not in demand by the computer owner's software, so the cycles donated are free, right? Well, sort of, but it takes time to download and install the software, there is some risk of infecting one's machine with a virus, many users may perceive some risk that the CPU demands will infringe on their own use, etc. Most users will believe there is some amount of cost.

With certain projects, volunteers may get some pleasure or entertainment value out of participating: for example, the search for large Mersennes primes is exciting to those who enjoy number theory; searching for alien intelligence probably provides a thrill to many.

I suspect a related motivation is sufficient for most volunteers: the projects generally have a socially valuable goal, so people can feel like they are helping make the world a better place, at a rather small cost to themselves. For example there are projects to screen cancer drugs, search for medications for tuberous sclerosis, and help calibrate the Large Hadron Collider (for physics research). As Muchmore writes, "a couple of the projects—Ubero and Gómez—will pay you a pittance for your processing time. But wouldn't you feel better curing cancer or AIDS?"

These projects appear to attract a lot of volunteerism. Muchmore reports estimates of participation that range from one to over five million computers at any given moment. According to the BOINC project, volunteers are generating about 400 teraflops/second of processing, far more than the 280 tps that the largest operational supercomputer can provide.

Posted by jmm at 03:29 PM | Permalink »

March 17, 2006

ICD with a twist

In a comment on Felten's blog article about false congestion as an incentive to send less traffic, Jim Horning reminded me of a classic article by Coffman and Kleinrock about incentives in scheduling computer resources:

E.G. Coffman and L. Kleinrock. “Computer scheduling methods and their countermeasures.? In AFIPS conference proceedings, volume 32, pages 11–21, 1968.

Coffman and Kleinrock argue that users will adapt to any scheduling rule implemented. Therefore, they argue, an incentive-compatible designer would decide which new behavior she wants users to adopt, and then implement a scheduling rule that to which that behavior is the best countermeasure. That's a very apt and clever way to express the principle of incentive-centered design!

Posted by jmm at 01:38 AM | Permalink »

Creating false congestion to selectively discourage sending on the Internet?

My first significant foray into research on incentive-centered design was my work with Hal Varian, Liam Murphy and others in the early-mid 1990s on incentives for congestion control in the Internet. Ed Felten in his popular "Freedom to Tinker" blog has brought up one of the key issues we in the networking community debated back then -- but the issue is still valid today!

The issue is this: the primary mechanism for congestion control in the Internet (we're talking about the transport of packets here) is technological: a standard protocol called "slowstart" (developed by Van Jacobsen at LBL). All compliant TCP stacks implement slowstart. In simple terms, when a server or user starts sending packets (a file, a streaming video, whatever), the flow rate starts slowly, and slowstart checks how long it takes for ACK (acknowledgment) packets to return from the other end. If the return time is within the acceptable range, the flow rate ramps up. But if congestion at any point is high enough to delay the ACKs beyond the threshold, then slowstart immediately drops the sending rate (typically cutting it in half as I recall), what is known as "backing off".

If TCP software all implements this protocol, then senders are effectively playing a cooperative game, backing off to reduce traffic when there is congestion.

One problem with this: What if some users use a version of TCP that turns off slowstart? They would then hog all available bandwidth, while everyone else was backing off to give them room. Similarly, there is another protocol on the Internet called UDP that does not use slowstart: it is supposed to be available for a small number of special purposes, but from time to time people have written software that uses UDP to transmit regular traffic, thus hogging bandwidth.

Felten raises a variation on this problem: what if a network service provider started discriminating against senders by sending false congestion signals to them (actually, delaying or blocking the ACK packets so the senders think the network is congested)? Those users would back off (if they were slowstart-compliant), bearing more than their share of the cost of congestion. This might, for example, be one step towards implementing a non-neutral net charging scheme, which has been much in the news recently: "pay up or we'll cause you to send less traffic."

Of course, as Felten also points out, if network service providers started doing this, the willingness of senders to abide by the entirely voluntary slowstart protocol might quickly erode, and then everyone would be worse off as congestion skyrocketed.

(Thanks to Rick Wash for pointing out Felten's article.)

Posted by jmm at 01:30 AM | Comments (0) | Permalink »