Monday, June 28, 2010

Utilitarianism

I've called myself a utilitarian for some time but I've recently concluded that utilitarianism is untenable as a moral philosophy.

I'm an engineer so my job is to understand the tradeoffs inherent in designing a device to suit a purpose.  Utilitarianism appealed to me because it treats all ethical decisions as tradeoffs.  I was trying to come up with a definition of tradeoffs and concluded that a tradeoff is any attempt to compare incomparables : e.g., maximum speed versus average power consumption, or cash on hand now versus a distribution of returns later.  There is no natural ordering of such values, so engineers fall back on (hopefully) their client's utility function : Q(low max speed, low power consumption) > Q(high max speed, high power consumption) is meaningful.

Since tradeoffs can only be made in the presence of a utility function, utilitarianism requires a global utility function.  I started to think about the properties such a function would have.  For it to be useful in making moral decisions, it must be computable or at least approximable in a time that is sublinear to the number of inputs given that utilitarianism says that everything is potentially an input -- potentially the entirety of the moral actor's past light cone.  It must also be able to concretely balance short term gains against long term gains unless one is to forever be sacrificing present good for some distant utopia.

Then I realized that my client's utility function is part of the dynamic system that describes them -- it might be better for my client that they change their utility function than that I really remove seatbelts to save weight.  This is not a problem for an engineer since it is my job to understand what the client wants, not worry about their mental health (within reason).  But utilitarianism equates "good" and "utility" so I can't make conative assumptions ; if I did, the global utility function would just be a fancy name for a personal god for which I have no evidence.  This is not fatal to a global utility function since many functions have fixed points, but it does eliminate many classes of simple functions so there is reason to be skeptical that there exists an approximation that requires only a very small portion of the inputs to the global utility function.

These criteria (approximability, tractability, and horizon-independence) are not trivial so I can't just assert that such a function exists in the same way that any other mental abstraction exists.  Unless I have positive reason for believing such a function exists and that I can apply it to solve moral questions, then I have no business calling myself a utilitarian.

So for now, I'm just an ex-utilitarian who thinks that the techniques engineers use to optimize designs can be useful in thinking about moral priorities, but that there are probably other principled ways to the same end.

Tuesday, June 15, 2010

Reversing Code Bloat with thr JavaScript Knowledge Base

Lindsey Simon and I just announced JSKB on the google code blog about browser-specific JavaScript optimization.  I wanted to expand on that.  Unfortunately, I don't have the technical chops necessary to put nice looking charts into blogs, so take a look here.

Wednesday, June 9, 2010

Talking at OWASP in Stockholm

I'm going to be talking at OWASP's AppSec Research Conference in Stockholm the week after next (23 June).

Jasvir Nagra and I are talking about virtualization as a strategy for bolting new security policies onto systems that have major legacy constraints, e.g. the web.  If we have time, we're going to discuss some of the language changes that Tom Van Cutsem and Mark Miller (who I believe is presenting at OOPSLA) have proposed for EcmaScript.







Beyond the Same Origin Policy
Jasvir Nagra and Mike Samuel, Google Inc.

The same-origin policy has governed interaction between client-side code and user data since Netscape 2.0, but new development techniques are rendering it obsolete. Traditionally, a website consisted of server-side code written by trusted, in-house developers ; and a minimum of client-side code written by the same in-house devs. The same-origin policy worked because it didn't matter whether code ran server-side or client-side ; the user was interacting with code produced by the same organization. But today, complex applications are being written almost entirely in client-side code requiring developers to specialize and share code across organizational boundaries.

This talk will explain how the same-origin policy is breaking down, give examples of attacks, discuss the properties that any alternative must have, introduce a number of alternative models being examined by the Secure EcmaScript committee and other standards bodies, demonstrate how they do or don't thwart these attacks, and discuss how secure interactive documents could open up new markets for web developers. We assume a basic familiarity with web application protocols : HTTP, HTML, JavaScript, CSS ; and common classes of attacks : XSS, XSRF, Phishing.