Denial-Of-Service Attacks As Civil Disobedience, Part III

Last week's Economist, which I'm only now getting around to reading, has a brief and interesting article on DoS attacks and civil disobedience. Of particular note is the following passage:

But in a free society the moral footing for peaceful lawbreaking must be an individual’s readiness to take the consequences, argue in court and fight for a change in the law. Demonstrators therefore deserve protection only if they are identifiable. Some countries (like Germany) even prohibit protesters from wearing masks.

....

Protesters in cyberspace, by contrast, are usually anonymous and untraceable. The furtive, nameless nature of DDOS attacks disqualifies them from protection; their anonymous perpetrators look like cowardly hooligans, not heroes.

The author has a valid point which I failed to take into consideration in my previous defense of DoS attacks. An act of civil disobedience derives its moral authority from the perpetrator's willingness to suffer legal sanction in order to further eir cause. Seminal examples, such as Gandhi's violation of the British salt tax or Rosa Parks' refusal to yield her seat, involved public, head-on confrontation with the powers that be. DoS attacks are, by contrast, relatively anonymous and thus pose little personal risk to the perpetrators, which seems a strong argument in opposition to the notion that they are a valid form of civil disobedience.

Can a DoS attack ever be a legitimate form of civil disobedience? If I put up a web page saying "I'm DoS'ing X in support of Y" I'm no longer anonymous and am thus vulnerable, in theory at least, to prosecution for my actions. This would seem to clear the hurdle set up in the previous paragraph.

Now, what if I join a DDoS, and all 10000 of us put up web pages? Again, in theory each of us could be prosecuted for our actions, though as a matter of pure logistics its unlikely that the government would ever bring 10000 prosecutions, which means that the risk to any particular individual is small. One could argue that, because each participant is exposed to only nominal personal risk, a DDoS isn't a legitimate form of civil disobedience.

Here, however, we have a real-world example against which to test that assertion. Suppose that I, and 9999 of my closest friends, participate in an illegal gathering; maybe we block an intersection in protest against something or another. Clearly the police can't arrest all 10000 of us, so the individual risk to myself is small, but at the same time such mass actions are typically seen as a legitimate form of civil disobedience. Which indicates to me that, in meatspace at least, nominal exposure to prosecution is sufficient to surpass the threshold of legitimacy. I can see no reason to hold online protests to a higher standard, in which case DoS attacks can be considered legitimate provided that the actors identify themselves in a meaningful fashion.

Denial-Of-Service Attacks As Civil Disobedience, Part II

Prokofy, in a comment on my previous post, takes exception to my characterization of Denial-Of-Service (DoS) attacks as civil disobedience, saying:

DdOS attacks are a form of coercion and a crime.

They aren't civil disobedience, and to claim they are is a whitewash.

At first blush I think that's a reasonable position to take, though one with which I obviously disagree, so I wanted to examine eir (and my) reasoning on the subject in more detail.

Prokofy seems to be making several related assertions regarding DoS attacks:

1. They are a crime.
2. They are coercive.
3. They are not, by virtue of 1 and 2, civil disobedience.

So let's just start at the top of the list and work our way down, shall we?

DoS attacks have been successfully prosecuted in the US, though I wasn't able to find direct citations of the associated statutes. Prokofy is correct that, at least in some circumstances, DoS attacks are a crime.

How about eir assertion that they're "coercive"? That question is a little more interesting, since DoS attacks do seem to meet the dictionary definition of "coerce":

1. to compel by force, intimidation, or authority, esp. without regard for individual desire or volition: They coerced him into signing the document.
2. to bring about through the use of force or other forms of compulsion; exact: to coerce obedience.
3. to dominate or control, esp. by exploiting fear, anxiety, etc.: The state is based on successfully coercing the individual.

However, coercion is a fairly complicated concept, the nuances of which aren't easily contained in a dictionary definition. A coercive act typically requires an explicit, conditional threat; telling someone you'll DoS them is coercive, but actually carrying through with the threat may fail to meet this condition¹. More generally, DoS attacks lack certain hallmarks that have typically defined coercive activity. Coercion has historically required an imbalance wherein the actor has more power than the target, but DoS attacks are often performed by (relatively) powerless individuals against institutions backed by significant economic/legal/political resources. The nature of the threat itself is also different. Classically, coercion has involved private violence, expropriation of property, blackmail, etc., acts which the general public agrees are morally odious. It is questionable whether DoS attacks, which can cause indirect economic and/or reputational damages, are subject to the same opprobrium. Given all of that I'm comfortable categorizing DoS attacks as "mildly coercive" on the grounds that they do involve threats of force to change the target's behavior but don't rise to the same level of damage that we typically associate with the word.

Now on to Prokofy's final point, that acts which are criminal and coercive in nature cannot rightly be classified as "civil disobedience". Civil disobedience is criminal by definition:

Civil disobedience is the active, professed refusal to obey certain laws, demands, and commands of a government, or of an occupying international power.

It's not "disobedience" unless you're breaking a law. Far from being a disqualifier, an action cannot be classified as civil disobedience unless it is criminal to some degree.

Can civil disobedience be coercive? Again, that's a really interesting, and somewhat slippery, question. In Defining Civil Disobedience, from Civil Disobedience in Focus, Brian Smart sketches out the following taxonomy of the types of civil disobedience:

• Threatening by
  • Coercion of Force of Violence
  • Coercion of Force of Nonviolence
  • Coercion of Persuasion (with or without violence)
• Non-Threatening with
  • Violence
  • Nonviolent Force
  • Persuasion

Note that Smart makes a distinction between threats and action, which goes back to the question of whether a DoS is even coercive. He also makes a distinction between violence and non-violence, suggesting that the former is a less valid as a form of civil disobedience than the latter. I believe that it's fair to say, given the taxonomy above, that a DoS is both non-violent and non-threatening for purposes of this discussion.

What is not yet clear to me, however, is whether a DoS constitutes nonviolent force or persuasion. Smart says the following in that regard:

Coercion of force is illustrated by my giving up my wallet at the point of a gun: while the threat poses two theoretical alternatives only one action is humanly possible: 'I am not left room for effectual reflection and judgment about what I do.' I illustrate the coercion of persuasion by a director threatening to resign if his board votes against a takeover, and where the director is regarded as valuable but not indispensable. The threat presents the board with two practicable alternatives, leaving it room for effectual reflection and judgment: it may incline but it does not necessitate.

If the distinction between force and persuasion revolves around the scope of action given to the target then a DoS attack strikes me as more persuasive than forceful, since the target generally remains at liberty to reflect on their future course of actions. However, in the preceding paragraph he writes:

For Morreall civil disobedience can include violence since violence is a form of force and force can certainly be used in civil disobedience as in the case of sit-ins, lying down in the road, and mass tax refusals.

In my previous post I argued that DoS attacks are closely analogous to sit-ins, which suggests that they include an element of force in their execution as determined by Smart's criteria. Per Smart, non-threatening, non-violent force is accepted as a valid form of civil disobedience by a couple of major names in the field including Rawls and Honderich.

So it would seem that there's a pretty solid argument to be made that DoS attacks are a legitimate form of civil disobedience. Against this view Prokofy offers the following:

5. "What they do isn't a crime, it's just a misdemeanor, or it's just a prank or it's just noble civil disobedience." Geeks tend to downplay what they do, so that their entire tribe doesn't become suspect (which it should become, in my view, when they refuse to ever condemn these miscreants). The Guardian and the Wire State's Secretary of State Evgeny Morozov -- who is actively cheering the coordination of the attacks on sites by retweeting and commenting on the Anon ops accounts and giving them PR advice -- are now claiming that their takedown of the Amazon and other payment sites are just a form of "civil disobedience". Geek techno-determinist Doug "Program or Be Programmed" Rushkoff calls it a "glitch". Anything to diminish and dumb down what in fact is a crime and is disabling and destruction of property.

Which doesn't add much in the way of substantive rebuttal. I should note that ey's writing about the actions of Anonymous² as a whole and not just the DDoS conducted via the Low Orbit Ion Cannon. The defense above is limited strictly to DoS attacks³; I make no claims about the moral standing of Anonymous' behavior as a whole.

---

1 Though, I suppose, there's always an implicit threat that it could get worse if the target doesn't change their behavior.
2 Which ey appears to be incorrectly conflating w/ the entire 4chan user base.
3 Specifically SYN-floods and other methods which overwhelm through sheer volume. My analysis probably doesn't hold for DoS attacks which exploit bugs to disable or modify the behavior of services.

Denial-Of-Service Attacks As Civil Disobedience

Update: See also posts 2 and 3 on this topic.

---

(via Glenn Greenwald) An editorial in The Guardian draws a parallel between denial-of-service (DOS) attacks and civil disobediance:

The hacktivists of Anonymous may be accused of many things - such as immaturity or being run by a herd instinct. But theirs is the cyber equivalent of non-violent action or civil disobedience. It disrupts rather than damages. In challenging the credit card companies and the web hosts in this way, they are reminding these businesses that their brand reputation relies not only on how the state department sees them, but also on how they maintain their independence in the eyes of their users.

Absolutely, and well said. I can't say that I've ever made the connection before, but Bruce Schneier's take seems correct: DOS attacks are the digital equivalent of blocking access to a building¹. That's an interesting idea that bears further consideration, if for no other reason that it requires people to think about "hacking" in a more sophisticated fashion.

As a side note, I'm regularly and vigorously annoyed by the bulk of "cybercrime" articles I come across; it seems like most writers thereof have educated themselves on the subject via repeated viewings of The Net and Golden Eye. So its heartening to see non-technical outlets making nuanced distinctions between the activities of Anonymous and generic hacking.

---

1 For non-technical folk playing along at home: The most popular DOS attack these days involves sending gigabytes of spurious connection requests to the servers which host a particular service, thus preventing legitimate users from making use of that service. Think of it as filling up a building's lobby so that no-one else can get in, more like a sit-in then just blocking the entrace. In any case it's a very apt analogy, one of the rare examples of a meatspace concept porting well to the online world.

An Erlang Flow File Parser

You may recall that, a long time ago, I wrote that FlowScan is looking a little long in the tooth. One of the major problems with the package is that it uses a single thread to process flow files serially; on modern servers this means that you have multiple cores sitting idle during during processing. When I was thinking about this problem it occurred to me that writing a FlowScan replacement in Erlang might solve at least part of this problem, since Erlang automagically parallelizes many of its operations across multiple cores.

I'm nowhere near having a full-blown replacement for flowscan yet, but I've finally got around to implementing a set of Erlang modules which solves part of the problem: parsing flow files. Given the interest that my posts on Erlang and flow file processing have generated (relative to the rest of the crap I write) I figured I'd commit the code to the web for posterity.

One of the first challenges I had to deal with in putting these modules together was how to actually structure the code. Parsing any particular file generated by flow-capture turns out to be pretty easy (especially in Erlang), but this is complicated by the fact that there are two different flow file formats, each of which can encapsulate any one of several NetFlow export formats. Were I programming in an object oriented language this problem could be easily solved through the application of the factory pattern in conjunction with appropriate base and derived classes. Alas, Erlang doesn't have classes or inheritance, so that idea was a non-starter.

As I've noted before there's a relative dearth of information related to Erlang best-practices, so I ended up having to do a fair amount of experimentation before I arrived at an approach that was satisfactory. I started with a single, monolithic file, but it got very large very quickly and made it difficult to come up with concise, meaningful names by which to distinguish functions for different format/export versions. This led me to break the code up into format-agnostic and format-specific modules using Erlang's package mechanism¹, and then repeat that trick again when it came time to handle different NetFlow export formats. The result is a layout that should look familiar to Perl programmers: a module "X.erl" combined with a subdirectory "X" containing all of X.erl's sub-modules.

The other code structure problem that I encountered was in deciding where to put the v3 I/O routines. I initially placed them in v3.erl, but that led to an awkward circular dependency between v3.erl and v5.erl: the former would delegate record parsing to the latter, which would then call the former to read the data off of disk. That was eventually resolved by moving I/O functions into their own module, io.erl, eliminating the dependency.

So, that's the brief story of my struggle with code structure. I ended up with the following:

• src
• buffer.erl: An improved version of the buffer module I originally wrote about here that contains the additional method length/1.
• flow_file.erl: Format-agnostic functions. This does processing which is common to all format versions, delegating format-specific operations to the appropriate submodule.
• flow_file.hrl: Header file containing public declarations (records and such) needed to work with the flow_file module. This recursively includes all of the header files for submodules as appropriate.
• flow_file
• flow_file.erl: Defines a data type for passing around information about a flow file in a generic fashion. Sorry about the name, couldn't think of anything more appropriate.
• utils.erl: Generic utility functions that aren't strictly related to parsing flow files.
• v3.erl: Handles the specifics of parsing v3 format flow files. Delegates to the appropriate submodule when it comes time to read records in a specific NetFlow export format.
• v3.hrl: Public definitions associated w/ v3 format files.
• v3
• io.erl: Handles all filesystem I/O specific to v3 format files.
• v5.erl: Parses NetFlow export v5 records.
• v5.hrl: Public definitions supporting processing of NetFlow export v5 records.
• test
• buffer_test.erl: Test code for the buffer module.
• flow_file_test.erl: Test code for the flow_file module.

Note that this code only handles format v3 and NetFlow export v5; those are the most widely used versions and what I was interested in working with. It'd be trivial to expand to support other NetFlow versions; the only real work that the v5 code does is defining an appropriate record type for the flow and then populating that record by decomposing a chunk of binary data read from the file.

None of this is rocket science from a code-complexity standpoint, especially since Erlang's bit syntax makes the processing of binary data relatively painless. Parsing the dynamic header of v3 format files is somewhat involved, but is simplicty itself in comparision with the C implementation of the same process from flow-tool's ftio.c. The only other moderately tricky bit is handling compressed flow files. Erlang provides a zlib wrapper, but doesn't provide a mechanism for directly streaming compressed data off of disk. So I had to do a little work in io.erl (which is where the buffer module gets used) to read and decompress compressed flow files in chunks. The alternative would be to slurp in and decompress the entire file at once, a non-starter since flow files are often hundreds of megabytes in size.

And there you have it; I've copiously documented the source files, so the rest should be easy enough to figure out. For my next trick I'm probably going to focus on profiling the code to make the process of reading and processing the files more efficient.

---

1 Packages are an experimental feature, but seem to work pretty well for the most part. I had some problems with the use of nested includes and edoc doesn't do a great job with resolving references for (sub)packages, but those are minor issues which might very well be attributable to me doing it wrong.

Sigh... Again

Just wanted to note that, between the Al-Aulaqi decision and all the crap that has befallen WikiLeaks, I'm not feeling positive about the state of civil liberties right now.