Abstract: Despite the conventional wisdom that proactive security is superior to reactive security, we show that reactive security can be competitive with proactive security as long as the reactive defender learns from past attacks instead of myopically overreacting to the last attack. Our game-theoretic model follows common practice in the security literature by making worst-case assumptions about the attacker: we grant the attacker complete knowledge of the defender’s strategy and do not require the attacker to act rationally. In this model, we bound the competitive ratio between a reactive defense algorithm (which is inspired by online learning theory) and the best fixed proactive defense. Additionally, we show that, unlike proactive defenses, this reactive strategy is robust to a lack of information about the attacker’s incentives and knowledge.

Discussion: This 2010 paper, a collaboration between security and machine learning researchers, makes the bold claim that rather invest your resources in making your system as secure as possible up-front, in many scenarios it’s just as good — or even preferable — to fix security problems based on what systems attackers target, a paradigm they call reactive security. It justifies this with a simple game-theoretic model in which a defender with finite resources, typically a high-level security manager, must allocate them among particular lower-level security tasks.

The primary model used by the paper, of interest on its own, is a two-player game taking place on a graph: the attacker begins at a start vertex and moves through the graph by executing successful attacks. Each vertex has a payoff value that the attackers receives once that vertex is reached, and each edge has a cost, indicating how much the attacker must pay to cross it (representing effort invested in an attack). The initial cost of an edge is based on the surface area of the system being attacked, and the defender can invest in defending an edge, temporarily increasing its cost for one round, but has only finite resources to go around during each round. Attackers and defenders alternate in rounds: the defender picks a set of edges to invest in, then the attacker gets to execute a series of attacks, always beginning at the start vertex. Finally, edge costs are hidden to the defender until the attacker uses the edge; this models how it’s difficult to determine a priori where security weaknesses in a system are.

Although the examples in the paper have vertices representing system components like machines on a network, I think vertices in the graph are best thought of not as particular systems being exploited, but rather a set of resources controlled by the attacker, or more generally, the current attacking capabilities of the attacker. At the start vertex, they control nothing but their own system; as each edge is traversed, they add new attacking resources to their collection. This allows systems like the one shown to the right, where an attacker may or may not have full control over a front-end system before attacking a back-end system, to be modelled.

The main result of the paper is this: under the assumption that the defender’s investment in an edge is linearly reflected in the attacker’s cost for that edge, a specific machine learning algorithm for reactive security (based on placing more weight on recently attacked nodes and exponentially decaying the weight over time) performs comparably to a pure proactive approach, in which the defender knows all edge costs a priori and picks a fixed, optimal strategy. This is done essentially by reducing the problem to a standard online learning problem and using known results. Moreover, they argue that in cases where the edge costs are estimated incorrectly or the attacker acts unexpectedly due to incomplete knowledge, the reactive security algorithm is superior to the proactive approach. Besides providing support for reactive security, this model also provides formal support for other pragmatic measures like defense in depth, which is investing in defense measures that are never needed unless some other defensive measure is first overcome.

Although the model is simple, it is quite general: not only can vertices represent machines on a LAN, but also components of an application, or a hybrid thereof. Traversing an edge can correspond to an attack from outside, a privilege elevation on a single machine, or to an attack between machines on a LAN. Two different attacks on the same system can be expressed by distinct edges with distinct costs, if the attacker possesses a different set of resources in each case, which makes sense. Even social engineering can be modelled: once the attacker has invested in tricking or bribing the employee, they can add the employee to their set of resources, lowering the cost of attacking new systems.

On the other hand, the model also has a number of weaknesses. A couple were made explicit in the paper:

• The model assumes that the mapping from defender investment in an edge to attacker cost to overcome it is linear. This is justified heuristically with the claim that the rate of discovering new security defects in software is roughly constant. Experience shows however that exploits that are easy to exploit can be hard to fix (e.g. DoS attacks), and exploits that are hard to exploit can be easy to fix (e.g. a buffer overflow in code that doesn’t directly handle user input). Moreover, the same “investment” in a system can be spent many different ways, and the model offers little insight into which way is most effective. One solution is to successively use the model itself to decompose vertices into subgraphs.
• Reactive security is unsuitable for dealing with situations in which an attack is so devastating to the company that it cannot recover. For example, a company that suffers a high-profile blow to its reputation in the press may see a drop in sales that ultimately drives it into bankruptcy, or may have major investors pull out. Even an optimal response in such a scenario is too little, too late.

Some other weaknesses are less obvious:

• The assumption that edge costs become known as soon as an attacker exploits that edge. In reality, the detection of a single exploit of a system gives very little information about the overall security of a system, particularly after that exploit is repaired. The frequency of exploits of an edge might be a better indicator (the learning may already effectively take this into account).
• The assumption that edges have a fixed cost which only increases temporarily if the defender invests in them. In reality, the cost of an attack depends on many dynamic factors, including the skill set and resources available to the attacker marketplace, and the behavior of the system under attack. As new attackers enter the attacker marketplace, as attackers learn new techniques, as transaction costs among attackers change (or as they form teams), or as new hacking tools become available, the cost of attack can go up or down. Patches, upgrades, installation of new applications, or even changes in load can expose new vulnerabilities or fix old ones (in particular, patches implemented in reaction to particular attacks do not go away after the round is over). All these factors can change quickly and are largely invisible to the defender.
• Similarly, payoff is assumed to be fixed from round to round. Payoff changes by the minute based not only on what new information the attacked resources are storing, but also the marketplace value of the information, which can be rapidly shifting and unpredictable. Reactive investment in defense of a system that, tomorrow, is of little interest to attackers is a bad idea.
• Edge costs are assumed to be independent, in the sense that investing in one edge does not affect the cost of any other edge. In reality, as is easy to see in the diagram above, improvements to one edge may quite directly affect the cost of another related edge as well. Another common example would be rolling out an operating system upgrade in the data center, which could increase the cost of all edges simultaneously.
• Attackers are assumed, after each round, to lose control over all their attacked resources. Long-lived attacks such as rootkits can go undetected during attempts to clean up after an attack, allowing the attacker to start in the next round with more resources in the bag at the beginning. In the worst case, the rootkit itself delivers a positive payoff to the attacker, and the attacker doesn’t need to take any additional action at all!

Although the system provides formal evidence that reactive security can be beneficial, it also provides formal evidence that extreme reactive security, pouring all your resources into the system that was just attacked last week, is a terrible strategy. Simple attack strategies which alternate between systems can exploit this kind of reactionary tactic.

Despite the many weaknesses and limitations enumerated above, as I would expect to find in any nascent research area, I find this work exciting and think it opens up a range of possibilities for software security management and challenges the intuition that reacting to attackers is impulsive or short-sighted. Perhaps future work in this area may provide richer models that will offer more new and surprising strategies to defenders.

Abstract: We introduce the notion of a conditioned-safe ceremony. A “ceremony” is similar to the conventional notion of a protocol, except that a ceremony explicitly includes human participants. Our formulation of a conditioned-safe ceremony draws on several ideas and lessons learned from the human factors and human reliability community: forcing functions, defense in depth, and the use of human tendencies, such as rule-based decision making. We propose design principles for building conditioned-safe ceremonies and apply these principles to develop a registration ceremony for machine authentication based on email. We evaluated our email registration ceremony with a user study of 200 participants. We designed our study to be as ecologically valid as possible: we employed deception, did not use a laboratory environment, and attempted to create an experience of risk. We simulated attacks against the users and found that email registration was significantly more secure than challenge question based registration. We also found evidence that conditioning helped email registration users resist attacks, but contributed towards making challenge question users more vulnerable.

Discussion: This paper from NDSS 2009 introduces conditioned-safe ceremonies, an informal model for security protocols that explicitly models the actions of users. Rather than conservatively considering users to be unpredictable agents capable of any action, it takes advantage of their properties as creatures of habit to help facilitate the desired, secure outcome.

Many of us are familiar with the problem of security warnings sometimes known as click fatigue: when a user is asked to dismiss a security warning frequently during normal operation, they begin to disregard it in all situations. This was for example the primary criticism of Windows Vista’s User Account Control (UAC) feature. There are two reasons for this: one is that security is not the primary concern of users who are focused on completing their primary task; the other is that humans asked to perform a process repeatedly will naturally begin to streamline the process by omitting optional steps and completing mandatory steps using rapid rule-based processing and simple pattern matching. If a situation called for a particular response in the past, visually similar stimuli will encourage users to perform the same task nearly automatically. In psychology this kind of decision-making strategy that settles upon an adequate solution is known as satisficing, and is very difficult to reverse.

Unfortunately this is precisely the type of user behavior exploited by phishers: a typical user presented with a log-in form resembling one they have used many times in the past will thoughtlessly enter their credentials, having long since eliminated the optional steps of carefully examining the security indicators that would expose it as a fraudulent replica.

A cryptographic protocol – such as SSL – is usually described in terms of a number of nodes representing participating machines which exchange messages over channels. A ceremony, coined by Intel’s Jesse Walker, extends the concept of protocols by incorporating nodes for the human users themselves and explicitly representing communication between users and their machines via I/O devices (Carl Ellison. Ceremony Design and Analysis. Cryptology ePrint Archive, Report 2007/399, 2007). This model opens up opportunities for modelling user behavior.

A conditioned-safe ceremony is one designed under the assumption that users will satisfice and behave according to habit; it operates by conditioning the user to follow certain rules during the ceremony. A simple example of conditioning is the Windows log-in screen, which asks the user to press CTRL+ALT+DEL before logging in. This key signals to the operating system that the information entered in the log-in dialog should not be made available to applications or keyboard interception drivers. Because users are always asked to do this, and are not permitted to skip this step, they develop a consistent habit of doing so. The inability of a user to log in without first pressing this key is called a forcing function: forcing functions encourage conditioning and discourage omitting steps which may seem unimportant.

A conditioned-safe ceremony should satisfy several important properties:

• It should only condition safe rules – “rules that are harmless to apply in the presence of an adversary.”
• It should condition at least one immunizing rule – “a rule which when applied during an attack causes the attack to fail.”
• Conditioned rules should be safe to follow under all circumstances, without any complex decision-making.
• It should not assume users will reliably perform any action that is not conditioned by the ceremony.

There are two different types of errors a user can make during a ceremony which may threaten its security:

• An error of omission: The user was expected to apply a rule but took no action.
• An error of commission: The user took an unexpected action not conditioned by the ceremony.

An attacker may attempt to induce either type of error. For example, if an application pops up a Windows log-in box, a user may unthinkingly enter their password without pressing the protective CTRL+ALT+DEL hotkey, because they were not instructed to do so in this instance. An error of commission is usually induced by the attacker giving the user specific instructions, such as “visit this URL in your web browser” or ” Users tend to be suspicious of unfamiliar instructions, making attacks of this type more difficult. An ideal conditioned-safe ceremony should protect against as many errors of both types as possible.

The paper presents an example conditioned-safe ceremony for machine validation: the first time a user logs into a site from a particular machine, they must validate their identity. To do this, the site sends them an e-mail containing a link that they must click; after the link is clicked, a cookie is installed and the user has full access to the site from their current machine. The link only works once. The goal of the attacker is to trick the user into not clicking on the link in the e-mail, instead giving it to the attacker; to accomplish this, they display a phishing web page giving specific instructions on how to do this.  This involves both an error of omission (not clicking on a link that they usually click on), and an error of commission (pasting the link into the website, an action they do not normally take). The expectation is that, if users tend to perform actions they are accustomed to, they will ignore or fail to complete the attacker’s instructions, and the attack will fail.

Sure enough, the experiment bears this out: although as many as 40% of users fall for the attack described above, an alternative design that does not follow the principles of conditioned-safe ceremonies leads to attack  success rates of over 90%. Interviews with the subjects who didn’t fall for the attack show that over half of them didn’t notice the attacker’s special instructions, or thought they were unimportant – the same inattentive attitude that makes security warnings useless now benefits users!

The most exciting thing about this work to me is that it’s one of the first to adopt and exploit a successful model of human behavior in the design of security protocols – a critical step, as humans all too often remain the weakest link in any secure system. Previous efforts have given great insight into the types of errors people make, but not into how designs can work around these limitations in human behavior.

On the other hand, the informal model presented in this work stands in stark contrast to the mathematical models used in cryptography, where cryptographic protocols are routinely subjected to formal verification techniques such as model checking and theorem proving – an important future direction is to generalize these same tools to ceremonies. Moreover, although satisficing behavior is evidently an important component in user behavior, it is obviously not the only such component: 40% of users were persuaded to commit multiple errors in the ceremony. It should come as no surprise that humans are complex creatures that cannot be adequately modelled by a simple set of conditioned rules. In this case, what processes underlie these divergent behaviors, and how can they be modelled? Another important question involves modelling of errors, or divergence of users from the model: can we empirically predict the likelihood of certain sets of errors occurring, and then formally validate that attacks are not possible  in the most likely scenarios? The attacks in this work were relatively ad hoc and don’t seem to rule out the possibility of another attack involving only a single user error.

In short, the area of ceremonies is fertile ground for the development of new models that can effectively predict the behavior of the system as a whole, facilitating the development of protocols that will subtly push users towards making all the right security decisions, even when security is the last thing on their mind.

The author releases all rights to all content herein and grants this work into the public domain, with the exception of works owned by others such as abstracts, quotations, and WordPress theme content.

Abstract: One way to provide fault isolation among cooperating software modules is to place each in its own address space. However, for tightly-coupled modules, this solution incurs prohibitive context switch overhead. In this paper, we present a software approach to implementing fault isolation within a single address space. Our approach has two parts. First, we load the code and data for a distrusted module into its own fault domain, a logically separate portion of the application’s address space. Second, we modify the object code of a distrusted module to prevent it from writing or jumping to an address outside its fault domain. Both these software operations are portable and programming language independent.

Our approach poses a tradeoff relative to hardware fault isolation: substantially faster communication between fault domains, at a cost of slightly increased execution time for distrusted modules. We demonstrate that for frequently communicating modules, implementing fault isolation in software rather than hardware can substantially improve end-to-end application performance.

Discussion: This 1993 paper by Wahbe and Lucco (now at Microsoft), Thomas E. Anderson (now at the University of Washington), and Susan L. Graham describes a software-based method for isolating modules on RISC machines, with immediate application to fine-grained privilege separation. Address spaces, implemented in hardware, are used to isolate processes in modern commodity OS’s, and software fault isolation (SFI) is an alternative with several advantages: most notably, it requires no hardware support, and communication cost between protection domains is much lower.

Background

Suppose a system is divided into modules (components) – for example, a multitasking operating system may have a kernel with various applications running on top of it. A system is said to provide fault isolation if it can recover from the failure of a module without risking the integrity of the rest of the system. For example, if you’re playing a game and it crashes, that shouldn’t cause your web browser – or your entire computer – to crash, or even to malfunction. Fault isolation is valuable for mitigating failures in large software systems where failures are inevitable.

Fault isolation also forms the foundation for a valuable security technique called privilege separation: if each module is only permitted to perform a limited set of certain operations, then even if a module is compromised by an attacker, the attacker only gains access to the privileges held by that module, rather than the entire system. For example, if you’re playing a game it should only have access to the game data files, not the files containing your bank information, which it doesn’t need; then, even if an attacker hijacks your game, they still can’t access your bank information. Privilege separation allows security vulnerabilities in large systems to be mitigated and allows the effort of security verification and auditing to be concentrated on the modules that hold the most dangerous privileges.

In a typical fault isolation system, each module owns some subset of memory where it stores its code and private data structures. To ensure that a misbehaving module does not compromise the integrity of other modules, modules must not be able to write to memory owned by other modules. Moreover, modules must communicate in a controlled manner, usually through an explicit interface, so that other modules can’t trick a module into modifying its own memory maliciously on their behalf.

Today, the primary mechanism used to enforce these properties is dynamic address translation, which maps virtual addresses (memory locations accessed by the application) to physical addresses (locations on the memory device itself) on-the-fly. This functionality is implemented by a specialized piece of hardware called a memory management unit (MMU). By introducing this layer of indirection, the operating system can ensure that a process has no ability to read or write memory belonging to other processes simply by configuring the MMU to provide no mapping from any virtual address to these locations. Because only the operating system kernel can reconfigure the MMU, this protection is secure enough to use with malicious code.

The downside to MMU-based protection is that communication is expensive. Suppose module A wants to send a message to module B. Normally, if both modules had the same view of memory, it would just call module B and pass it a pointer to the message. This takes only a few instructions and is very fast. When two modules have different address space mappings, however, the cost rises dramatically: just switching from running one module to running the other requires a context switch, which involves saving and restoring the complete register set, reconfiguring the MMU, and flushing the MMU’s cache (the translation lookaside buffer). On top of that, it can’t just pass a pointer to the message, because for module B that same pointer may map to a different location in physical memory. There are many different ways to send messages from one process to another, but these all involve overhead.

In applications where the number of messages sent is large, this overhead rapidly becomes prohibitive. An example is a Gigabit Ethernet driver, which has to send a new packet to the network stack about every 12 microseconds. Considering the CPU time needed to parse the headers, this leaves very little time for expensive context switches. As a consequence, in practice components like this are simply not modularized; if they crash, the system crashes.

More generally, any system that is decomposed into fine-grained modules will tend to exhibit a lot of communication between modules – the performance disadvantage of doing this under the MMU model outweighs the security and robustness advantages of having smaller modules.

Software fault isolation (SFI)

Software-based fault isolation, or SFI, aims to provide a substantially different model for fault isolation emphasizing fast communication between modules. In this model, all modules have the same view of memory (run in the same address space), but different subsets of memory are owned by different modules, and every write to memory is checked to make sure the current module owns that memory. Additionally, function calls between modules are controlled so that each module can only be entered at a predetermined set of entry points described in its interface specification.

Despite the name, the important thing here is not that these mechanisms are implemented in software – this offers the convenience of deploying the solution on existing commodity platforms, but is not essential, and indeed most SFI systems rely on some creative combination of software mechanisms and (existing) hardware mechanisms.

In its simplest form, this model is straightforward to provide: imagine you have a trusted compiler and you use it to compile an application consisting of multiple modules.  Each module is assigned a fixed range of memory for its code and data. Whenever the compiler emits a write instruction, it also emits a check to make sure that the address being written to is in the range of the module being executed. Likewise, whenever the compiler emits an indirect branch or jump, it inserts a check to make sure that that jump either lies within the current module, or is a valid entry point of some other module. This simple solution has two main problems:

1. It’s really slow.
2. It’s possible for a malicious module to circumvent the checks. For example, it could insert an indirect branch to one of its own write instructions, skipping the check in front of it.

To deal with the circumvention problem, Wahbe et al use a dedicated register that holds an address. When the compiler emits code, it maintains two invariants:

1. All writes must be performed to the address stored in the dedicated register;
2. The dedicated register should almost always point to a valid address inside the current module; if any instruction invalidates this invariant, the program must either fail or restore the invariant before the next write or indirect branch instruction.

Now, a module is free to jump to any instruction it wants within its own bounds, without risking writing to another module’s memory. This does imply that the dedicated register can’t be used for any other purpose, but on a RISC machine with 32 registers this is not a problem. The same trick can be used to protect indirect branches (jumps to data must be excluded; this can be done either by using a second dedicated register for code, or by marking all data non-executable).

This leaves open the question of how to allow calls between modules (called cross-fault-domain RPCs by Wahbe et al). The scheme implemented in this work stores a jump table inside each module, with one entry for each possible cross-module call. The trusted compiler permits this jump table (and only this jump table) to contain branches to points outside the module. This allows the checks on indirect jumps to be very simple (they just have to make sure modules only jump to their own code region). Rather than transferring control directly to another domain, these jump tables transfer control to call stubs which perform several important operations before invoking the actual call:

• Because each module needs to access its own data on the call stack, each module is given a private stack in its own data region. When transferring control to another module, we have to switch to its stack and copy across any stack-based arguments. A similar mechanism is used by commodity OSs when trapping in and out of the kernel.
• Standard calling conventions include callee-save registers, registers which must not be altered by the function being called. Since the called module may be malicious, the call stub saves these registers instead.
• The dedicated register invariants must be restored upon return.

Finally, we return to the problem of performance: inserting complex checks before every write and indirect jump is expensive, especially if those checks involve branches. The insight of Wahbe et al is that if the code and data region for each module is the set of all addresses with some common bit prefix (say, addresses 0x1f00000 through 0x1fffffff) then we can make sure that all writes and jumps go into this region by merely bitmasking the target address to have the correct prefix. If the original address lies outside the region, this will cause some random part of the module to get overwritten or jumped to – but only malicious or invalid code will encounter this behavior, so it’s not a problem (except, perhaps, during debugging).

Another important optimization involves the stack: writes to the stack are considerably more common than writes to the heap in typical programs, and are usually made at a small fixed offset from either the stack pointer or the frame pointer. Rather than check every one of these, they take advantage of the stack’s locality by maintaining the invariant that the stack pointer (or frame pointer) points inside the module’s data region, and only checking it when it’s modified. Since writes through the stack pointer may have a small offset attached, they create “guard regions” containing nothing useful before and after each module’s data region; even if the stack pointer is at the beginning or end of the region and the offset is set to the minimum or maximum value, it still can’t write past the guard regions.

To actually implement privilege separation with SFI, a little something extra is needed – if all modules in an application could make the same system calls, they would effectively have the same privilege. As described in section 3.4, Wahbe et al’s scheme uses a simple but flexible model in which one module is permitted to make system calls freely and no other module is permitted to make any; it acts as an arbitrator and can implement arbitrary fine-grained policies by observing which module invoked it.

Evaluations show that with all the optimizations described above, the overall scheme is quite efficient – runtime overhead ranged from 0 to 12%, with an average of 4.3%. However, this is only checking writes – checking reads, which is done in the MMU model and is important for protecting sensitive module-private data such as passwords, requires a much higher overhead due to the larger number of reads (21.8% on average).

One practical issue with Wahbe et al’s scheme as a security solution is that it depends on a large, trusted compiler for correctness – later works such as MIT’s PittSFIeld mitigated this problem by using a separate, smaller verifier that is run on machine code when loading it.

Practical impact and later work

Despite the apparent utility of Wahbe et al’s scheme, sometimes termed classical SFI, it is not widely used in practice. This may be because the scheme depends critically on a number of features of RISC machines, and RISC machines are not widely deployed in the PC market (they are, however, quite common in the mobile and embedded market). It may be because it was never effectively developed into a robust product or integrated well with other tools. More recent work, such as MIT’s PittSFIeld (2006) and Vx32 (2008), have effectively extended SFI to CISC platforms such as the x86 and put more effort into promulgating a robust prototype.

Although SFI is a hot research area now, I remain skeptical of approaches like Vx32 that depend on creative exploitation of legacy hardware that is in the process of being phased out. The way I see it, SFI presents a useful fault isolation model that is independent of its software-based implementation, and deserves explicit hardware support to mitigate its performance costs. Doing an efficient check for each read and write is exactly the sort of thing hardware is good at (and software is really bad at). The hard question is exactly what hardware support should be implemented to support typical applications – SFI is so poorly deployed, that few applications have ever been architected with fine-grained modularization and privilege separation in mind, and the array of possible design choices is overwhelming. Some proposed schemes include Mondriaan Memory Protection (2002), and the Hard Object (2009) project I worked on at UC Berkeley. Just as important is more work on programming tools to describe and implement module isolation and interfaces in a generic way that can be implemented using a variety of fault isolation schemes, ranging from no protection to dynamic address translation to SFI to new hardware schemes – this will help to bootstrap the process of getting large enough applications built that new platforms for isolation can evaluated. Regardless, this is going to be an important area of research in the near future and I’m excited to see what techniques will gain adoption.

The author releases all rights to all content herein and grants this work into the public domain, with the exception of works owned by others such as abstracts, quotations, and WordPress theme content.

Abstract: In 1985 Luca Cardelli and Peter Wegner, my advisor, published an ACM Computing Surveys paper called “On understanding types, data abstraction, and polymorphism”. Their work kicked off a flood of research on semantics and type theory for object-oriented programming, which continues to this day. Despite 25 years of research, there is still widespread confusion about the two forms of data abstraction, abstract data types and objects. This essay attempts to explain the differences and also why the differences matter.

Discussion: This October 2009 essay by Assistant Professor William R. Cook of the University of Texas at Austin, an active programming languages researcher, seeks to clarify the fundamental difference between two often-confused forms of data abstraction: abstract data types (ADTs) and objects (as in object-oriented programming).

Both abstract data types and objects have the same basic purpose: they allow the same functionality to be implemented in different ways, and allow the implementation to be modified without affecting client code. For example, when using a “dictionary” module mapping keys to values, the client shouldn’t have to care whether that functionality is internally implemented using a hash table or a red-black tree; and the implementer should be free to modify this kind of implementation detail at any time.

The “objects” provided by mainstream object-oriented programming languages such as Java, C++, and C# are actually a sort of hybrid of abstract data types and true objects, able to effectively simulate both abstractions. To demonstrate the distinction, here we outline an implementation for an “IntQueue” class representing a first-in first-out queue of integers in Java using both methods. First using objects:

[sourcecode language="java"]
interface IIntQueue {
public boolean isEmpty();
public void enqueue(int i);
public int dequeue();
public IIntQueue append(IIntQueue q);
}

class IntQueue implements IIntQueue {
java.util.ArrayList list;

public IntQueue() { list = new java.util.ArrayList(); }
public boolean isEmpty() { return list.size() == 0; }
public void enqueue(int i) { list.add(i); }
public int dequeue() { int i = (Integer)list.get(0); list.remove(0); return i; }
public IIntQueue append(IIntQueue q) {
IntQueue result = new IntQueue();
while (!this.isEmpty()) { result.enqueue(this.dequeue()); }
while (!q.isEmpty()) { result.enqueue(q.dequeue()); }
return result;
}
}

public class Program {
public static void main(String[] args) {
IIntQueue q1 = new IntQueue(), q2 = new IntQueue();
q1.enqueue(1); q1.enqueue(2);
q2.enqueue(3); q2.enqueue(4);
IIntQueue q3 = q1.append(q2);
while (!q3.isEmpty()) {
System.out.println(q3.dequeue());
}
}
}
[/sourcecode]

This Java sample follows two important disciplines:

1. Concrete class names, such as IntQueue, are only ever used in “new” expressions, not as parameter types, return types, or even local variable types – and this includes in the definition of the IntQueue class itself. Instead, we are constrained to exclusively use interfaces (pure virtual classes in C++) for our static types.
2. Reference equality (==) is never used.

Although they may seem draconian, adhering to this “pure object” discipline introduces some powerful flexibility. For example, instead of having the “append” method construct the combined queue all at once, we can introduce a new class that allows us to rewrite it as a constant-time operation:

[sourcecode language="java"]
class IntQueue implements IIntQueue {
// (same as before)
public IIntQueue append(IIntQueue q) { return new LazyAppendIntQueue(this, q); }
}

class LazyAppendIntQueue implements IIntQueue {
IIntQueue q1, q2;

public LazyAppendIntQueue(IIntQueue q1, IIntQueue q2) { this.q1 = q1; this.q2 = q2; }
public boolean isEmpty() { return q1.isEmpty() && q2.isEmpty(); }
public void enqueue(int i) { q2.enqueue(i); }
public int dequeue() { if (q1.isEmpty()) return q2.dequeue(); else return q1.dequeue(); }
public IIntQueue append(IIntQueue q) { return new LazyAppendIntQueue(this, q); }
}
[/sourcecode]

This modification requires no changes to the client code; indeed, no client code could possibly detect any change in behavior, as long as it’s constrained to accessing objects through the IIntQueue interface.

An alternate way of optimizing the append() method is to append the underlying arrays, and then make this the underlying array of a new IntQueue. In the strict objects model, however, this is impossible: the append() method can see the representation of this, but can only access its argument through the IIntQueue interface. We might try to fix this by adding a method to the interface to get the underlying array, but that would severely limit the possible implementations of IIntQueue (in particular, LazyAppendIntQueue above would be excluded). The restriction that objects cannot access other objects except through their interface, even other instances of the same type, is called autognosis, and is a fundamental limitation of objects.

Now let’s consider how this same data structure could be implemented in the style of an abstract data type (ADT):

[sourcecode language="java"]
class IntQueue {
java.util.ArrayList list;

public IntQueue() { list = new java.util.ArrayList(); }
public boolean isEmpty() { return list.size() == 0; }
public void enqueue(int i) { list.add(i); }
public int dequeue() { int i = (Integer)list.get(0); list.remove(0); return i; }
public IntQueue append(IntQueue q) {
IntQueue result = new IntQueue();
result.list = this.list;
result.list.addAll(q.list);
return result;
}
}
[/sourcecode]

This looks more like typical Java code – each method of IntQueue is free to ravage the internal state of any instance of IntQueue, and interfaces are not used; consequently, different implementations of the same module are not interchangeable at runtime. They are, however, interchangeable at compile-time – if we had two different implementations of “class IntQueue” in two different namespaces, we could decide with a single “import” statement which one we’d like to use. Different parts of the program might choose to use different implementations, but they wouldn’t “mix” – they couldn’t be passed to one another’s append() methods. For these reasons, ADTs are considerably less flexible than true objects, but what they lose in flexibility they make up for in simplicity and the potential for optimization.

Considering how much more ADTs look like normal Java code, you might be asking yourself where objects are really used in practice. In general, they tend to pop up in places where a single, relatively stable interface has many different implementations; common examples include “windows, filesystems, or device drivers.” Filesystems are the most illustrative example: by providing a single fixed API, not only can many different filesystems be accessed through the same uniform filesystem interface, but they can be composed in interesting ways, such as mounting an ISO (a file on one filesystem contains the underlying storage for a different filesystem).

The filesystem example also exposes one of the strongest disadvantages of objects: once many implementations have been written to a stable interface, changing that interface in any way is very difficult. ADT signatures on the other hand are straightforward to extend; for example, if a client of Dictionary needs to iterate over the dictionary in order, you can just add that functionality to the version based on red-black trees, and then compel that client to use that particular implementation.

Following a development process based on refactoring, it’s not uncommon to introduce an abstraction using ADTs and later refine it into a true object when more flexibility is needed. Conversely, the need for optimization using autognosis may require introducing some elements of ADTs. Using type inspection like “instanceof” and reflection, it may be possible to get the “best of both worlds” by optimizing certain common cases, but falling back on the generic interface for unrecognized types. This is sort of a poor man’s version of multiple dispatch.

Neither Cook nor I promote the use of either ADTs or true objects over the other. The most important takeaway from this is: know how to use both ADTs and true objects, recognize which one you’re using, and know their advantages and disadvantages. By avoiding the conceptual conflation that hybrid data abstraction systems tend to induce, you can better predict where to expect issues with extensibility and efficiency in your system.

The author releases all rights to all content herein and grants this work into the public domain, with the exception of works owned by others such as abstracts, quotations, and WordPress theme content.

Abstract: The embedded zerotree wavelet algorithm (EZW) is a simple, yet remarkably effective, image compression algorithm, having the property that the bits in the bit stream are generated in order of importance, yielding a fully embedded code. The embedded code represents a sequence of binary decisions that distinguish an image from the “null” image. Using an embedded coding algorithm, an encoder can terminate the encoding at any point thereby allowing a target rate or target distortion metric to be met exactly. Also, given a bit stream, the decoder can cease decoding at any point in the bit stream and still produce exactly the same image that would have been encoded at the bit rate corresponding to the truncated bit stream. In addition to producing a fully embedded bit stream, EZW consistently produces compression results that are competitive with virtually all known compression algorithms on standard test images. Yet this performance is achieved with a technique that requires absolutely no training, no pre-stored tables or codebooks, and requires no prior knowledge of the image source.

The EZW algorithm is based on four key concepts: 1) a discrete wavelet transform or hierarchical subband decomposition, 2) prediction of the absence of significant information across scales by exploiting the self-similarity inherent in images, 3) entropy-coded successive-approximation quantization, and 4) universal lossless data compression which is achieved via adaptive arithmetic coding.

Discussion: This 1993 paper described EZW, one of the earliest successful image compression algorithms using the discrete wavelet transform, and was the first published fully embedded code for images. With such a code, an image file can be truncated at any point and the result will be a valid approximation to the image, enabling a fine-grained tradeoff between file size and quality. It is also, unusually for its time, a compression scheme that requires no training on an existing database of images, instead adapting to the statistics of the image at hand.

If you don’t have a background in signal processing there’s quite a bit of background required for this one, but I’ll summarize the necessary concepts here.

The first concept, adaptive arithmetic coding, is an entropy coding strategy used in a huge variety of both lossless and lossy coding schemes. To simplify discussion, let’s consider the simple scenario where we’re decoding a bilevel (black and white) image file pixel-by-pixel in scan order, and we have access to all preceding pixels in scan order. Suppose the previous pixel is white. How can we use this information to predict the color of the next pixel? One simple way is to keep a count of how many times so far a white pixel has been followed by a black pixel, and how many times it’s been followed by a white pixel; these frequencies are used to estimate the probabilities that the next pixel will be black, or white. This is the first part of the entropy coding scheme, called the model; it is adaptive because it depends on what other pixels have been decoded so far.

The second half is the arithmetic coding. Like all entropy coding schemes, it encodes a sequence of symbols, using less bits to represent a symbol that is expected to occur with high probability, and more bits to represent a symbol that is expected to occur with low probability. The details of how this coding is done are not important here; the important thing is that it is near-optimal, in the sense that if a symbol is expected to appear with probability p, it can be encoded in close to −log₂ p bits, even if this value is not an integer, which is the lower bound of Shannon’s source coding theorem. For example: a symbol expected to appear with probability 0.5 can be encoded in −log₂0.5 = 1 bit, a symbol expected to appear with probability 0.95 can be encoded in −log₂0.95 or about 0.074 bits, and a symbol expected to occur with probability 0.001 requires about 10 bits. Compared to Huffman coding, arithmetic coding is particularly useful in situations where the number of symbols is small, or where the probabilities are close to 1.

The discrete wavelet transform (DWT) is, like the discrete cosine transform (DCT) used by JPEG files, a way of representing an image in the frequency domain instead of the spatial domain. It is a reversible operation that converts an array of pixels into an equal-sized array of coefficients each representing how much energy the image has in a certain range of frequencies, in a certain part of the image. The reason for doing this is that natural images like photographs tend to have most of their energy at low frequencies due to their smooth, continuously-varying regions, with high-frequency information like edges and fine details being limited to only a small portion of the image. The result is that after undergoing such a transformation, most of the coefficients will be close to zero, and can be truncated to zero with little visual impact on the image. The main difference between the DCT and the DWT is the DCT is applied to a fixed-size spatial region: in JPEG, it’s always applied to an 8×8 block of pixels. The DWT is applied in a multiresolution fashion: it uses a high-pass filter to isolate local changes in brightness (details) in the image between adjacent pixels, then low-pass filters and downscales the image and repeats this process. As a consequence its coefficients vary not only in the frequency range they cover but also in the size of the spatial region they cover, allowing them to represent both very fine details and larger-scale details compactly. Since a range of frequencies is called a subband, this is also called a hierarchical subband decomposition.

The array of DWT coefficients can be visualized as a new image, which at low bit rates will be mostly black (close to zero), but with white in some places, representing the significant coefficients. See the example to the right (Alessio Damato / CC-BY-SA). The main challenge in representing such an image is not so much representing the values of the significant coefficients,  but their position, using a data structure called a significance map.

This is where the zerotrees come in. Notice how the three images in the upper-left closely resemble the three large images. In particular, where the smaller images are black, the larger images also tend to be black. Zerotrees take advantage of this by encoding the smaller images first, and assigning one of four values to each coefficient: positive significant coefficient, negative significant coefficient, zerotree root, and isolated zero. A zerotree root is an insignificant (near zero) coefficient for which the corresponding coefficients in all larger images are also insignificant. An isolated zero is an insignificant coefficient that does not have this property. Once a zerotree root has been encoded, none of its descendants need to be encoded, since they’re already known to be insignificant. Additionally, since isolated zeros are rare, this symbol is assigned a small probability and the use of arithmetic coding ensures that not too much space is wasted accounting for this possibility. The parameter that determines how much space our zerotree occupies is the threshold between significant and insignificant coefficients.

This is already a great way of compressing images, but how do we turn this into a fully-embedded code that can be truncated at any point? The key to this lies in a successive-approximation scheme. In this scheme, initially all coefficients are assumed to be insignificant, so the initial zerotree is trivial (one zerotree symbol). We then lower the threshold (divide it by 2) and compute and output a new zerotree, and repeat this indefinitely. Any significant coefficients already detected by previous zerotrees are assumed to be zero, so that they don’t get encoded more than once. Simultaneously, each time we produce a new zerotree we also add one bit of precision to the magnitudes of all the already-known significant coefficients. We don’t have to finish writing out any particular zerotree, since each one prioritizes writing out coarse details (smaller coefficient images) before finer details (larger coefficient images); any coefficients left unencoded are assumed to be insignificant.

What’s happened to EZW today? Its raw compression performance and speed have long been since been exceeded by other systems, such as SPIHT (Said, Amir and Pearlman, William A. A new fast and efficient image codec based upon set partitioning in hierarchical trees. June 1996. PDF),which benefits from a more complex partitioning scheme then the simple splitting-into-four shown here, and other improvements. But its ideas remain the foundation of all the best modern image compression systems. These ideas were incorporated into the JPEG 2000 image format, which uses a very similar wavelet-based fully-embedded code. This eliminates JPEG’s blocking artifacts due to its multiresolution nature, permits a fine-grained quality-for-size tradeoff, gives significantly better quality at low bit rates, and allows lossy and lossless encoding in a single framework, among other advantages. JPEG 2000 hasn’t seen wide adoption in consumer applications – one can only speculate as to why – but these techniques remain a valuable way to look at image compression.

The author releases all rights to all content herein and grants this work into the public domain, with the exception of works owned by others such as abstracts, quotations, and WordPress theme content.

Abstract: A simple variant of a priority queue, called a soft heap, is introduced. The data structure supports the usual operations: insert, delete, meld, and findmin. Its novelty is to beat the logarithmic bound on the complexity of a heap in a comparison-based model. To break this information-theoretic barrier, the entropy of the data structure is reduced by artificially raising the values of certain keys. Given any mixed sequence of n operations, a soft heap with error rate ε (for any 0 < ε ≤ 1/2) ensures that, at any time, at most εn of its items have their keys raised. The amortized complexity of each operation is constant, except for insert, which takes O(log 1/ε) time. The soft heap is optimal for any value of ε in a comparison-based model. The data structure is purely pointer-based. No arrays are used and no numeric assumptions are made on the keys. The main idea behind the soft heap is to move items across the data structure not individually, as is customary, but in groups, in a data-structuring equivalent of “car pooling.” Keys must be raised as a result, in order to preserve the heap ordering of the data structure. The soft heap can be used to compute exact or approximate medians and percentiles optimally. It is also useful for approximate sorting and for computing minimum spanning trees of general graphs.

Discussion: This 2000 paper by Bernard Chazelle introduced a data structure called a soft heap, which is a heap data structure that can perform any operation in amortized constant time. In exchange for this ideal performance bound, a new limitation is imposed: at any time, any element in the heap may have its key increased at the discretion of the data structure; such an element is said to be corrupted. There is an upper limit of εn corrupted elements, where n is the number of operations completed so far and ε is a fixed parameter. For example, if ε = 0.01, and we insert 1000 elements into the heap, at most 10 elements will be corrupted.

Heaps are one of the fundamental data structures studied in computer science. Like dictionaries or hash tables, they store a set of elements, each with an associated key. Heaps support four fundamental operations:

• insert: Insert a new element, given the element and its key.
• extract minimum: Get the element with minimum key and delete it from the heap.
• decrease key: Update an existing element’s key to a smaller value.
• merge or meld: Combine two existing heaps together into one large heap.

The most obvious application of these operations is a priority queue: if the keys indicate priority (with smaller values indicating higher priority), then insert adds a new task to the queue, and extract minimum retrieves the current highest-priority task. Heaps also form the basis of the heapsort sorting algorithm, which in its simplest form inserts each element into a heap one-by-one and then uses extract minimum repeatedly to get the result list in order.

The sorting application demonstrates an important lower bound regarding heaps: it is impossible to design a heap data structure that can do both the insert and extract minimum operations in amortized constant time, for if this were possible we would be able to do a comparison sort in linear (O(n)) time; but any such sort requires Ω(n log n) time. Indeed, the best known heap data structure, the Fibonacci heap, developed in 1984, can do all these operations in amortized constant time except for extract minimum, which requires Θ(log n) amortized time.

But what if there were some way to modify the heap data structure that let us break through this lower bound and do all operations in amortized constant time without contradicting the above result? This is exactly what the soft heap does. A soft heap is like a normal heap, but with the troubling property that the key you assign to an element when you insert it may not stay that way; more formally, the data structure may choose at its discretion to increase the key of any element at any time. Any element that has had its key increased is called corrupted. It’s easy to see how this might be helpful in reducing complexity; if the data structure just decided to increase the keys of all elements to infinity, it would be trivial to do all operations in constant time.

But to make soft heaps actually useful and not just fast, we need an additional constraint. This constraint is as follows: each soft heap has a fixed parameter ε called the error rate. Roughly speaking, this controls what proportion of the elements may be corrupted at any given time. More formally, it specifies that if we start with the empty heap and do n operations, the resulting heap will have at most εn corrupted elements. If all n operations are inserts, then indeed ε will be an upper bound on the proportion of corrupted elements. If extract minimum operations are included, the relationship is no longer so clear – it’s possible all elements may become corrupt.

As Chazelle so elegantly says, “despite this apparent weakness, the soft heap is optimal and—perhaps even more surprising—useful.” Perhaps the simplest nontrivial application of soft heaps is finding the median of a list of values in linear time. There is a classical algorithm for doing this, but the implementation and analysis of the algorithm based on the soft heap is much simpler. All we have to do is set ε = 1/3, then insert all n elements into the heap, and then do extract minimum n/3 times. Depending on exactly which elements got corrupted, the final element extracted, the pivot, will be somewhere between the (n/3)th and (2n/3)th smallest element in the list. We then partition the list into the sublist of elements less than or equal to the pivot, and those greater than the pivot, and recursively invoke this procedure on the one containing the median. This is similar to the quicksort algorithm, but only recursively processing one of the sublists instead of both, and it runs in worst-case linear time.

Historically, soft heaps were invented with a specific application in mind: computing minimum spanning trees. Chazelle has achieved some fame for discovering the asymptotically best known algorithms for several problems, and this is one of them: his soft-heap based algorithm can compute minimum spanning trees in O(n α(n)) time, where α is the inverse Ackermann function, a very slowly-growing function that is less than 5 for all remotely practical values of n. I don’t discuss the details of this algorithm here because they’re pretty complex, but you can see Chazelle’s paper (Bernard Chazelle. A Minimum Spanning Tree Algorithm with Inverse-Ackermann Type Complexity. JACM 47(6):1028–1047, 2000, PDF). In 2002, Pettie and Ramachandran presented a minimum spanning tree algorithm based on soft heaps that is known to be asymptotically optimal.

So how does it work? In Chazelle’s original implementation, the soft heap was a simple variant on the binomial heap. Instead of storing a single element at each node, it would store a list of elements, associated with a single key that is an upper bound on the original keys of all the elements. This is the source of the “corruption” – any values in this list whose original keys are smaller than the common key are corrupted. Such “multivalued” nodes could only appear near the top levels of the trees making up the heap, which limits how many corrupted elements there can be. These lists are formed during the soft heap’s special “sift-up” routine, which under certain conditions will run twice on the same node, causing it to merge (concatenate) element lists with one of its children. There are a number of subtleties to this process, however, and to explicate them Chazelle gives complete C source code for the data structure in a literate programming style.

Recently a simpler implementation of soft heaps by Kaplan and Zwick has appeared (A simpler implementation and analysis of Chazelle’s soft heaps. In Proceedings of the Nineteenth Annual ACM -SIAM Symposium on Discrete Algorithms (Jan 4-6, 2009).) They use the original soft heaps concept of storing a list of items at each node, and of occasionally running sift on elements twice during sifting, but rather than being based on binomial heaps, this implementation is based on a set of heap-ordered binary trees. Also, their condition for running sift twice on a node is somewhat less arbitrary: each node x has an associated “size” value that increases exponentially with rank, and the size |list(x)| of the element list at any internal node x must always satisfy size(x) ≤ |list(x)| ≤ 3size(x).

How do you know if soft heaps might be useful for something you’re doing? Due to their peculiar behavior, they tend to be most useful for inventing new algorithms with better worst-case performance than existing algorithms, particularly in situations where the “approximate rank” – or approximate position in sorted order – of an element in a list is useful. It tends to be applied in places where ordinary heap data structures have traditionally been applied in the past, like graph algorithms and sorting. Beyond this though, there may still remain a rich set of untapped applications of soft heaps to be found that employ them in novel ways.

The author releases all rights to all content herein and grants this work into the public domain, with the exception of works owned by others such as abstracts, quotations, and WordPress theme content.

Discussion: This classic machine learning textbook discusses a variety of well-studied application-independent methods of classifying inputs into one of several distinct classes, as well as some of the theory behind them. The book’s organization is constructed around the amount of information available to the classifier, beginning with scenarios where the actual distribution of features of classes is known, and finishing with scenarios where even the classes themselves must be inferred. Among the many techniques considered are decision trees, neural networks, genetic algorithms, Boltzmann learning, nearest neighbor classification, k-means clustering, principal and independent component analysis, formal grammars, linear discriminants, resampling methods like bagging and boosting, and maximum-likelihood estimation; most of these are treated in great detail.

Perhaps the best demonstration of the level of detail that the book goes into is its discussion of neural networks in chapter 6. Whereas any general book on artificial intelligence is bound to include basic discussion of neural networks and their dominant learning algorithm, backpropagation, the discussion here is both denser and covers a broad range of extensions and relations to other methods. First of all, it contextualizes neural networks and places them in their historical context by preceding the chapter with a thorough chapter on linear discriminants, a powerful tool in their own right that are basically equivalent to neural networks with no hidden layers. Unlike more generalized references which tend to merely describe the most common implementation of neural networks without any justification, every design choice going into the neural network is derived and justified and alternative choices are discussed, from the update rules to the activation function to the number of layers and hidden units to the initial weights to the training protocol to the stopping condition. Perhaps most important from an engineer’s point of view is section 6.8, which discusses a variety of extensions needed to make neural networks efficient and accurate in practice, such as input standardization, momentum, weight decay, hints, use of second-order information, and so on. Each of these occupies no more than a page, but still effectively conveys the essence of the technique. Besides these essentials, the chapter also informally proves the power of three-level networks, and incorporates a variety of interesting visualizations of network structure, network weights, error surfaces, convergence, and so on, which helps a lot in developing an intuition for the behavior of neural networks. In short, this chapter contains about as much information on neural networks as I would normally expect to get from an entire book on the subject.

The book isn’t just a bunch of survey papers stapled together though; it has a number of things that tie it together. Most important is its organization of progressively less well-specified problems. Chapter 2 begins with Bayesian decision theory and describes how to perform classification optimally, given the complete probability distribution of each feature for each class. This also brings in the first major theoretical result, the lower bound on classification error given by the Bayes error. From there it progresses to maximum-likelihood estimation, in which the distribution type (e.g. Gaussian) is known but not its parameters (such as mean and standard deviation), and these parameters must be determined from manually-classified example data. After this comes simple nonparametric techniques like nearest neighbor estimation and linear discriminants that make no assumptions about the distribution but only work well when the classification function is simple and the dimension isn’t too high. Neural networks can describe more complex functions, but still get tripped up by complex classification functions with many local minima and maxima. The next chapter addresses stochastic methods like simulated annealing and genetic algorithms that cope well with complex classification functions, at the expense of much greater training time. Skipping over a couple chapters, the final one deals with unsupervised classification, where the example data have not been assigned to classes and the classes are not even known and must be inferred; a typical technique in this scenario is clustering. This organization is effective at emphasizing the point that a classifier needs to take advantage of as much information as the application domain makes available to be effective.

Chapters 8 and 9 don’t fall well into the natural progression. Most of the chapters deal with numeric features, like width or age, leaving discrete features such as color or gender, and the classifers that process them such as decision trees and formal grammars, to chapter 8. Chapter 9, entitled “algorithm-independent machine learning”, is based around theory and metalearning techniques that can be used to enhance all classifiers. It begins with the fundamental No Free Lunch theorem, which essentially states that no classifier performs better in all cases than any other classifier, including the naive classifer that merely guesses at random. It also discusses resampling methods that aim to improve unstable classifiers or combine different types of classifiers, and describes how to compare one classifier with another, which is essential when espousing the benefits of any new classifier.

The progressive organization, while useful, also necessarily implies that some essential basic topics, such as decision trees (chapter 8), resampling methods (chapter 9), and k-means clustering (chapter 10), are not introduced until long after more specialized topics have been visited, such as Bayesian belief networks (chapter 2) and hidden Markov models (chapter 3). As a consequence it probably makes more sense to just read the first few sections of each chapter first, rather than reading the book straight through.

Another frustration with this book is that there are a number of forward references: in particular, cross-validation is mentioned several times before it’s finally explained in Chapter 9, and probabilistic neural networks were discussed in chapter 4 in the context of Parzen windows, with neural networks discussed in chapter 6. They also assume quite a bit of math background in areas that aren’t covered in-depth in most undergraduate programs, like matrix calculus and statistics, with only a terse appendix for a refresher on this material. It would have been helpful to demonstrate of these techniques in the one-dimensional case, where the familiar intuitions of real number calculus apply.

Well dense and thorough, there are necessarily some things the book doesn’t cover, in order to fit into 600 pages. Some theorems are not proved in the text, particularly the No Free Lunch Theorem, but also many of the convergence results and probability bounds. This is generally not a big deal since the book is intended more for those looking to apply machine learning to an application domain, rather than those looking to study theoretical machine learning and conceive new techniques – and its references are thorough enough that this information can be located if needed. On the other hand, it also doesn’t contain any real code or references to real machine learning libraries – it’s not a programmer’s handbook. Finally, the second edition in particular concentrates heavily on application-independent models, and does not delve into the intricacies of the immense number of applications of machine learning; problems like determining the best features to use and how to compute them are discussed but motivated only by toy examples and not real-world problems like speech recognition, image processing, or expert systems. It helps when reading it to have an application domain in mind to mentally plug into the models.

In short, if you’re looking for a dense and application-independent survey of major classification algorithms in machine learning, this is the book to get you started, and will take you a few steps beyond anything you might have studied in an AI intro class. But I would precede it with some reading on matrix calculus, and follow it with some reading on a specific application area of your choice, to help make the concepts more concrete.

The author releases all rights to all content herein and grants this work into the public domain, with the exception of works owned by others such as abstracts, quotations, and WordPress theme content.

Abstract: Learning from examples is the process of taking input-output examples of an unknown function f and infering an implementation of f. Learning from hints allows for general information about f to be used instead of just input-output examples. We introduce a method for incorporating any invariance hint about f in any descent method for learning from examples. We also show that learning in a neural network remains NP-complete with a certain, biologically plausible, hint about the network. We discuss the information value and the complexity value of hints.

Discussion: This short 1990 machine learning paper introduced a technique for learning with hints in a neural network; that is, it allows a neural network to learn a function for which we have some limited information about its properties.

In machine learning, neural networks are a simple way of representing functions that is sufficiently powerful to approximate any function. They consist of a set of at least three layers of processing nodes connected by edges labelled with weights. All the inputs into each node are multiplied by the weights on their edges, then a sigmoid function (a particular strictly increasing function bounded between -1 and 1) is applied to produce the output. By adjusting the weights, we can gradually modify the function being computed.

Neural networks are particularly useful in classification problems; for example, one might construct a neural network that takes as input an image and outputs 1 if it looks like a hamburger, or else -1. It would be really difficult to manually write a program that does this. Instead, neural networks can be trained with a set of inputs and their associated outputs; the weights are adjusted based on the examples using the backpropagation algorithm until it computes a function close to the actual one.

For our purposes, the most important thing to note is that the backpropagation works by feeding the training input to the network and determining how far the output is from the desired training output, called the error. It then adjusts the weights in a way that decreases that error. It does this repeatedly until it reaches a stopping point.

Backpropagation is efficient and general but can run into two important related problems:

• Insufficient data: There may not be enough training data to learn weights that generalize well to new inputs.
• Overfitting: The resulting function may end up being oversensitive to parameters of the training examples that are actually irrelevant.

For example, say you train a hamburger recognizer on many images off the Internet, and then I give it a picture of an upside-down hamburger. Because it’s never seen an upside-down hamburger before, it’s quite likely to claim that it’s not a hamburger, despite the fact that intuitively we know that orientation does not affect an image’s hamburgerness. Likewise it may fail to recognize an image that is smaller or larger than those in its training set, or where lighting is unusual. These kinds of restrictions on the function representation are called invariants. Invariants cannot be directly expressed as input-output examples; they are larger restrictions on the scope of functions under consideration.

The most obvious way to deal with invariants is to expand your training set – turn all your training images upside-down, and add them to your training set. But when we begin to consider more and more combinations of invariants, this approach can rapidly grow infeasible. Not only does the training set become large, but if there are not enough inputs in the original training set to teach the invariant, then it will not be properly learned.

The key observation of Abu-Mostafa’s work is that we can don’t need to rely entirely on training examples. Whereas training examples specify the constraint that f (x) = y, where f is the function we’re learning and x and y are the input/output, for invariants it’s more useful to deal with equality examples, which are pairs where f (x₁) = f (x₂). The backpropagation algorithm can be easily modified to accomodate this: instead of computing the error based on the distance between the actual output and desired output, we compute it as the distance between the two outputs produced by the two examples. There’s no requirement to know what the value of f (x₁) or f (x₂) is. Using this advantage in our example, we can take any image, even if we don’t know whether or not it looks like a hamburger, rotate it, and use the two images to train our network. We could even generate random images and rotate these.

Another way of framing this is that we want to encourage the network to learn new features that describe the input but in some way summarize or interpret the original input features. These new features can then be leveraged by the network to guide the final output. To take an example from the book Pattern Classification (Richard Duda, Peter Hart, David Stork, section 6.8.12): if the input is a soundwave, and we want to determine what speech phoneme it represents,  a useful intermediate feature would be deciding whether it’s a vowel or a consonant. To encourage the network to learn this feature, we can add a new output node that is set to 1 or -1 depending on whether the input soundwave is a vowel or consonant. By incorporating an initial training phase that modifies the network weights to predict this output well, we now have a starting network that can already distinguish vowels and consonants, which is a big help in making finer subclassification. Without the hints, the network may have learned this on its own, but the more domain-specific information we can give it, the quicker it will train and the better it will generalize. In the case of our original example, these intermediate features would be properties of the original image that are insensitive to the invariants like rotation.

For learning with hints, neural networks with more than three layers of nodes are often helpful as well. The idea is that the first layer can convert the input features to the new intermediate features of interest, and then normal learning can be applied to these. Where the invariants are very simple, they can even be applied to the inputs before training (and prediction), placing them in canonical form. For example, to help deal with brightness variation in images, it helps to scale all images to the same brightness range.

My apologies for the long delay in this post – I’m currently engaged in reading the book Pattern Classification, and intend to follow up here with a discussion of it when I’m done.

The author releases all rights to all content herein and grants this work into the public domain, with the exception of works owned by others such as abstracts, quotations, and WordPress theme content.

Abstract: Bagging predictors is a method for generating multiple versions of a predictor and using these to get an aggregated predictor. The aggregation averages over the versions when predicting a numerical outcome and does a plurality vote when predicting a class. The multiple versions are formed by making bootstrap replicates of the learning set and using these as new learning sets. Tests on real and simulated data sets using classification and regression trees and subset selection in linear regression show that bagging can give substantial gains in accuracy. The vital element is the instability of the prediction method. If perturbing the learning set can cause significant changes in the predictor constructed, then bagging can improve accuracy.

Discussion: This 1996 machine learning paper described a very simple mechanism called bagging (short for “bootstrap aggregating“) for improving the accuracy of predictors by averaging the results of a number of independent predictors trained over samples from the same training set.

Suppose we’re creating a decision tree to predict, based on a number of medical tests, whether or not a patient has cancer. A typical way to do this is to gather some cases from a medical database, then use them to train a predictor model, such as a decision tree or neural network.

The issue with this straightforward approach is that many predictors used in machine learning, including decision trees and neural networks, are unstable: training them on a slightly different data set can produce significantly different results. For example, if we split our training set in half, and use each half to build a decision tree, those two decision trees are likely to be quite different and yield different predictions. This is a result of overfitting, the phenomenon where a model fits itself too well to the training data, and not well enough to the complete population of past and future cases underlying the sample.

To overcome this, we introduce ideas from a statistical technique called bootstrapping. To motivate this concept, suppose you have a random sample of 1000 test scores from a pool of 1 million, and you want to estimate what the median test score is. Because we can’t know this exactly, we instead seek a confidence interval that has a 98% chance of containing the median. Finding a confidence interval for the mean test score is easy using standard techniques, because the sample mean and population mean are analytically closely related, but the same is not true of the median.

When analysis fails, we take a more computational approach. The idea is to use the sample itself as an approximate model of the underlying distribution: we can replicate each score 1000 times to obtain a pool of 1 million scores that will statistically resemble the real 1 million scores. We then take (say) 200 independent samples of size 1000 from this pool, and compute their medians. Finally, we take the 1% and the 99% percentiles of these median scores to get our confidence interval. In practice, rather than duplicating scores many times, it’s more typical to simply sample with replacement, so that each score can be chosen multiple times. Provided the original sample is a good empirical approximation of the complete population, the result is a very good prediction of the actual median.

What does this have to with machine learning? Well, suppose instead of test scores we have medical test results, and instead of the median, we’re estimating whether they have cancer. We draw (with replacement) bootstrapping samples from the original data, and for each one we use it as training data to construct a predictor. Then, for new cases we take a majority vote among the predictions to determine the overall prediction. Provided that the data is a good empirical approximation of the complete population of past and future cases, the result will be a good prediction that resists overfitting.

This technique is extremely general, and can be applied to virtually any type of classification problem and any model. It can even use completely different models for different bootstrap samples, which can make it easy to sidestep difficult questions about choosing good models and model parameters. It has three main disadvantages:

• Performance: For each of the bootstrap samples, we have to construct a separate model from scratch, and each query must bear the overhead of querying each of these models and combining their results. Fortunately, bagging is easily parallelizable – because of this, and because it can extract good accuracy from fast-to-query models like decision trees, it can actually be more efficient in some cases.
• Relies on instability: If the model being used is stable, or in other words does not change significantly between bootstrap samples, the resulting system can actually be less accurate than a model built directly on the original data. An example of a stable model is a nearest-neighbor classifier. To vividly illustrate this point, the paper describes an experiment with a linear regression model where the stability of the model depends on the number of variables used. Sure enough, there is a crossover point in accuracy between the bagged and the unbagged versions of this predictor.
• Interpretability: One of the widely cited advantages of models like the decision tree is that it’s easy for a human to understand how it makes it decisions – like a flowchart, it just performs a series of tests. But when you have twenty decision trees, each making different decisions on the same inputs, it’s harder to get an intuitive feel for their aggregate decision making – it’s like predicting the decision that a committee will make by learning about its members.

Bagging is just one of a family of resampling ensemble methods; another popular one is called boosting, a technique that iteratively combines multiple predictors by encouraging each new model to focus on cases misclassified by previous models. Boosting can learn more quickly than bagging because of its focus on misclassified cases, but is also less robust to errors in training data. A 2005 paper by Kotsiantis and Pintelas described a scheme for combining the two (“Combining Bagging and Boosting”, International Journal of Computational Intelligence, PDF).

Bagging has already played a strong role in the design of machine learning systems. Now that we’ve hit the clock speed barrier and are seeing more highly parallel and multicore systems, it’s bound to become an even more attractive option. Keep it in mind if you ever need to design a simple but accurate machine learning system.

The author releases all rights to all content herein and grants this work into the public domain, with the exception of works owned by others such as abstracts, quotations, and WordPress theme content.

Abstract: We argue that the random oracle model — where all parties have access to a public random oracle — provides a bridge between cryptographic theory and cryptographic practice. In the paradigm we suggest, a practical protocol P is produced by first devising and proving correct a protocol PR for the random oracle model, and then replacing oracle accesses by the computation of an “appropriately chosen” function h. This paradigm yields protocols much more efficient than standard ones while retaining many of the advantages of provable security. We illustrate these gains for problems including encryption, signatures, and zero-knowledge proofs.

Discussion: This influential 1993 paper introduced the random oracle model, designed to enable a methodology for the design of efficient formally sound cryptographic protocols such as encryption and authentication, and is one of the milestones in the philosophy of cryptographic protocol design.

The holy grail of cryptography is cryptographic protocols – algorithms for tasks like encryption and signing – that are provably secure against attack. However, in the study of algorithms, negative results such as “no efficient algorithm exists to break this scheme” are notoriously difficult to prove; this is one reason why major problems like whether P=NP defy solution.

Like complexity theorists, cryptographers turned to conditional results: they assume that some cryptographic primitive is available – a very simple building block such as one-way functions, or one-way trapdoor functions – and then build more complex primitives, including complete protocols, using them. In “The Random Oracle Metholodgy, Revisited,” discussed later, Ran Canetti defended this practice:

One of the great contributions of complexity-based modern cryptography, developed in the past quarter of a century, is the ability to base the security of many varied protocols on a small number of well-defined and well-studied complexity assumptions. Furthermore, typically the proof of security of a protocol provides us with a method for transforming [an] adversary that breaks the security of said protocol into an adversary that refutes one of the well-studied assumptions. The Random Oracle Methodology does away with these advantages.

One may draw an analogy with the P=NP problem: why do we suppose that NP-hard problems are difficult to solve? Because if we could solve any one of them in polynomial time, it would resolve the longstanding P=NP problem and provide fast algorithms for a variety of well-studied problems. Likewise, if we could show that a protocol relying on a particular cryptographic primitive is insecure, it would solve a longstanding open problem (e.g. do one way functions exist?) and simultaneously break many other protocols relying on that primitive.

However, unlike the case of P=NP, systems proven conditionally secure by reduction to cryptographic primitives are rarely implemented. Indeed, until the publication of “Random Oracles are Practical,” most cryptographic systems used in practice had no formal justification whatsoever. This is because conditionally secure formal systems are much too inefficient for practical use. Yet there were ad hoc efficient cryptographic protocols in use in practice that clearly were good at withstanding concerted attack – without any formal backing, what was it that gave them their strength? Bellare and Rogaway write:

Theorists view certain primitives (e.g. one-way functions) as “basic” and build more powerful primitivees (e.g. pseudorandom functions) out of them in inefficient ways; but in practice, powerful primitives are readily available and the so-called basic ones seem to be no easier to implement. In fact theorists deny themselves the capabilities of practical primitives which satisfy not only the strongest kinds of assumptions they like to make, but even have strengths which have not been defined or formalized.

To facilitate the design of more efficient protocols,  the authors advance the following methodology: suppose that all parties in a cryptographic protocol, including the attacker, have access to a random oracle. A random oracle is like an ideal pseudorandom number generator: you seed it with a particular initial value, and then it gives you an arbitrarily long sequence of random bits. The sequence depends on the seed, but has no other predictable patterns (and in particular, does not cycle).

In real life, random oracles cannot be implemented; deterministic programs cannot produce arbitrarily-long random outputs. But this paper asserts the following thesis: if a protocol can be proven secure in the presence of a random oracle, and we then replace calls to the random oracle with calls to a good cryptographically secure pseudorandom number generator, a process called instantiation, the resulting protocol is expected to be secure in practice. Moreover, schemes designed using this method are expected to be more efficient than conditionally secure schemes.

It’s not hard to see that this methodology is not perfectly sound in theory. For example, one can design a cryptographic protocol that passes zero to the oracle, and if the result is f(0), it reveals its secret key. In the random oracle model, this is very unlikely to occur, so the system remains secure; but if the system is instantiated with f, then it always occurs, and the system is completely insecure. Part of the thesis is that “an appropriate instantiation for a random oracle ought to work for any protocol which did not intentionally frustrate our method by anticipating the exact mechanism which would instantiate its oracles” (section 6, Instantiation).

To provide some practical justification for its thesis, “Random Oracles are Practical” presents a very simple, efficient encryption algorithm for long messages that is secure against a variety of attacks in the random oracle model. We begin by assuming (as in the conditionally secure model) that we have access to two primitives:

• a trapdoor permutation f, which is a function that, like RSA, can encrypt or decrypt a short k-bit value;
• a random hash function H that inputs arbitrarily long strings and outputs k-bit results.

Now suppose we want to encrypt the message x. We choose a k-bit random value s which will be used as the seed for the random oracle. We XOR the output of the oracle with the message x to generate the encrypted message. Finally, we append the encryption f(s) of the seed with the trapdoor permutation, so that the receiver can determine s, and the hash H(sx) of the seed together with the message to protect against tampering. This scheme is secure against three types of attacks in the random oracle model:

• In a chosen-plaintext attack, the polynomial-time adversary supplies two strings, one of them is encrypted, and the adversary must determine by examining the ciphertext which one was encrypted. They don’t have to do this perfectly, just significantly more than 50% of the time.
• In a chosen-ciphertext attack, the adversary is additionally given access to the decryption function, and they can ask it to decrypt any string except the encrypted string they’re given.
• Finally, a malleability adversary is one that, given the encryption of one string, can determine the encryption of a related string, such as an extension of the original string or one where some characters are replaced by other characters.

Sure enough, when the random oracle is replaced by a cryptographically secure pseudorandom number generator, the result is a system that is secure in practice, in the sense that no practical attack against the system has ever been found. The authors go on to describe similar efficient systems for signing and non-interactive zero-knowledge proofs that are sound in the random oracle model.

Over the years, many researchers took the advice of this paper and designed new efficient protocols based on the random oracle model. Encouragingly, these systems withstood the test of the time and have not been broken. This seems to say that the methodology is sound. But in 2002, a strong result by Canetti, Goldreich, and Halevi cast doubt upon the thesis (“The Random Oracle Methodology, Revisited.” J. ACM 51, 4 (Jul. 2004), 557-594. PDF). Their main result is as follows:

There exist signature and encryption schemes that are secure in the Random Oracle Model, but for which any implementation of the random oracle results in insecure schemes. [...] Moreover, each of these schemes has a “generic adversary”, that when given as input the description of an implementation of the oracle, breaks the scheme that uses this implementation.

In other words, not only can these encryption schemes be broken for any possible instantiation, but they supply a constructive method to do so fully automatically.

The proof method is similar to the example cited earlier of an encryption protocol revealing secret information if the oracle returns f(0) when given zero for the seed, where f is the cryptographically secure pseudorandom number generator used to instantiate the protocol. The difference is that instead of modifying the protocol to always fail for one particular f, it causes it to fail on a different f for each input. The input that causes failure under instantiation with f is simply the description of f (i.e., the machine code for f). Because the attacker has access to this information, they know just how to break the system. Fundamentally, this attack relies on a sort of “white box” reverse engineering – not only can the attacker execute the function f, but they can examine its code as well.

This does not say that the practical schemes designed to be secure in the random oracle model are insecure — to the contrary, they have stood the test of time quite robustly — but it does call the theoretical advantages of the paradigm into doubt. The authors of “The Random Oracle Methodology, Revisited” disagree sharply about the philosophical implications of this result for protocol design. Ran concludes that “the Random Oracle model is a bad abstraction of protocols for the purpose of analyzing security,” and strongly prefers the older approach of reductions to hard problems. Oded sees the random oracle model as an effective “sanity check” for rapidly ruling out insecure designs. Shai speculates on two possible reasons why existing protocols based on the random oracle model have defied attack:

1. The systems are more difficult to break because a proof of security in the random oracle model rules out a large class of attacks – those that work in the random oracle model. Methods of attack that overcome this will take longer to develop.
2. Existing protocols have some as-yet-unidentified feature that makes them more resilient than the contrived protocols described in this work.

Shai’s view of the utility of the model is more optimistic: he sees it as an “engineering tool” that is better than having no formal proof of security at all, and makes finding attacks more difficult.

What’s the future of the random oracle model? Perhaps we will identify some class of protocols for which instantiation is a sound procedure, or at least for which the generic attacks in this paper are inapplicable. Or perhaps we will adopt a new model that provides stronger guarantees. For now, formalizing and justifying the design of cryptographic protocols remains a difficult problem and a contentious philosophical debate.

The author releases all rights to all content herein and grants this work into the public domain, with the exception of works owned by others such as abstracts, quotations, and WordPress theme content.