The rise and fall of perfect security

Modern societies, however resilient, are built on remarkably shaky foundations: every single day, we all depend on the moral standards and the restraint of thousands of random strangers. The rules of this game are weakly enforced through series of very imperfect deterrence mechanisms (less than 20% of all property crime is ever solved in the United States) - but in the end, our world is little more than an incredibly elaborate honor system that we all voluntarily participate in.

That's probably okay - we are programmed to play along, and this approach proved to be a smart evolutionary move. A degree of trust is essential to advancing our civilization at a reasonable pace; and paradoxically, despite the apparent weaknessess, the accelerated rate of progress makes us stronger and more adaptable as a species in the long run.

When it comes to the online existence, our attitudes seem drastically different, though: we only joke about the idea of using the evil bit - and yet, we are perfectly comfortable that the locks on our doors can be opened with a safety pin. We scorn web developers who can't seem to be able to get input validation right - even though we certainly don't test our morning coffee for laxatives or LSD. We are being irrational - but why?

Perhaps the reason is simple: the mankind had thousands of years to work out the rules for social interactions in the real world; societies collapsed, new ones emerged - with an increasingly complex system of moral values passed from one generation to another. The Internet is much younger in comparison, and in the end, very different from what we are accustomed to: your neighbor will not try to sneak into your house, but may have far fewer qualms about using your wireless network - a concept that feels much less like a crime. He will not condone theft - but likely feels ambivalent about making unlawful copies of digital content. He may frown upon crude graffiti - but just chuckle at the sight of exploited persistent XSS on a popular website.

An argument can be made that the incentives in online interactions are so different from these in the physical realm, that any such comparisons are simply inappropriate. But then, consider Wikipedia - a design that stands against everything we know about information security, yet demonstrates remarkable resilience in the face of attacks.

Here's a perverse thought, then: what if our pursuit of perfection in information security stems from a fundamental misunderstanding of how human communities can emerge and flourish? We are essentially preaching a model of a society based on complete distrust - but as the complexity of the online world approaches that of real life, the odds of being able to design perfectly secure software are rapidly diminishing; and the impact of being so paranoid is already taking its toll on how much we can achieve today.

If this model is not sustainable, will our online world share the fate of many other early civilizations - collapsing under the weight of its own imperfections, and ultimately, going the way of the dinosaur?

Perhaps; if so - new, more enlightened communities will certainly emerge.

Read More

Barbers and security professionals

There seems to be a significant, government-sponsored push for compulsory certification and licensing in the security industry. The wonderfully self-contradictory report from the Commission on Cybersecurity aside, Larry Seltzer pointed out that this very idea is also a major part of the proposed Cybersecurity Act of 2009:

"Beginning 3 years after the date of enactment of this Act, it shall be unlawful for any individual to engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any [...] information system or network designated by the President, or the President’s designee, as a critical infrastructure information system or network, who is not licensed and certified under the program."

I agree that there are persuasive arguments to be made in favor of taking this step - but it is very important to recognize that the same arguments can easily be made in favor of mandatory licensing for almost any contemporary profession. Quite simply: in modern societies, people serving even the most mundane roles can and occasionally do cause profound losses or significant distress to others. C'est la vie.

There is a small subset of professions where the stakes are particularly high - for example, building engineers; and several classes of occupations endowed with unique social privileges or an unusual degree of trust - say, doctors, lawyers, or teachers. In all these cases, licensing probably makes sense - although quite literally, it comes at a very significant price.

In most other occupations, however, the situation is far less obvious - and the current regulatory practice is rather arbitrary. We usually license barbers and hot-dog vendors - but not bakers, farmers, or pacemaker assembly line workers. Electricians and plumbers are licensed - but construction workers do not need to demonstrate even basic competency to any external body. Louisiana has a tough test and mandatory licensing for florists. Many of these distinctions are driven by specific interest groups, some are fueled by moral panics; but they do not seem to form a coherent, cost-efficient plan to make our society a safer place.

The extra cost of licensing aside, the most significant pitfall of overzealous regulation is that in attempts to preemptively police complex industries or individual human behaviors, governments are necessarily clumsy and heavy-handed - and often fail to consider many of the socially valuable corner cases. Here's a couple of my favorite (if only vaguely related) non-IT anecdotes:

• To combat the proliferation of basement meth labs, Texas requires a license and a home inspection to buy a beaker. While this is unlikely to have any impact on real criminal activity, teaching your children chemistry suddenly gets a lot more complicated.

  
  
  

• In an attempt to curtail drug use, eleven US states require you to have a prescription to buy syringes. This has a significant impact on many types of precision hobbies, where syringes are indispensable as a measuring tool; and probably only promotes syringe reuse among drug addicts.

  
  
  

• Following reports of people pointing lasers at aircrafts, Australia and some other jurisdictions ban sale or import of lasers with output over 1 mW. This rule also covers more powerful but completely eye-safe lasers with integral pattern-generating optics - commonly used in machine vision and hobbyist robotics; the impact on these applications is profound.

  
  
  

In the end, it is a natural human instinct to try and minimize many of the perceived risks we are subjected to - but it's also important to seek sensible balance between this goal, and the task of maintaining our civil liberties, or enabling scientific progress. We can make our lives resemble one giant TSA checkpoint - but it's not a cheering prospect to contemplate.

So, yup: it is clear that bad software engineering may lead to real damage, and that the current situation is far from being perfect. There is also a potential for damage in getting a bad haircut, or being served a mystery hot-dog. In the end, however, I believe that in absence of truly exceptional circumstances and profound social benefits, we should be giving people the right to choose - and leave it to the industry to come up with the sort of meaningful professional certifications that it actually needs (if it needs any). Rudimentary liability for negligent engineering may be a far better method of improving status quo, by creating incentives to care about security - rather than having a certification system to hide behind.

Some of the urgency around this topic is fueled today by the end-times rhetoric about cyber-terrorism, cyber-warfare, and the imminent cyber-apocalypse - and the apparent shortage of qualified personnel to step up and save the day; but for most part, I do think this idea is very misguided. The landscape of information security, and the economics of vulnerability exploitation, have not fundamentally changed in the past 6-8 years or so - spare for a body of vivid anecdotes, and a couple of interesting but not surprising incidents; we also enjoyed a steady growth of a competent workforce, and a very self-limiting problem of charlatans. It is still the bored teenagers and the crazy geeks, and not the XSS-obsessed arm of Al Qaeda, that are the most significant threat to our infrastructure. True, government agencies are finding it unexpectedly difficult to hire the right talent, but some of the reasons for this may lie with the organizational challenges these entities are facing today - and not with the failings of the outside world.

...

Even if you disagree with the vaguely libertarian premise outlined earlier - that governments should not regulate professions in absence of exceptional social benefits of doing so - the other important question is whether there exists a body of stable, scientific knowledge that could be enforced as a part of a professional licensing scheme; if not, then the entire philosophical argument is moot. The apparent failure of commercial certifications systems - a fact confusingly pointed out and then subsequently completely ignored in the CSIS report - may offer an important clue: are the existing schemes inadequate and weakly embraced simply because people who administer them are incompetent quacks? If not, then perhaps, something more profound is amiss - and a new, shiny licensing scheme is not going to change that.

Read More

Vær snill med roboten?

Som noen kanskje har fått med seg har politiet tatt ut tiltale mot to personer for å ha lurt en robot. Den uheldige roboten eies av det utenlandske meglerhuset Timber Hill. Roboten ble visstnok lurt 2200 ganger og var således ikke av den mest lærenemme varianten.

Saken er helt spesiell siden det normalt er roboten som er kjeltringen i finansmarkedene. Det har lenge vært kjent at meglerhus flytter sine datamaskiner fysisk nærmere børsen slik at signalene skal bruke kortest mulig tid fra børsen til meglerhusets server. En del børser har til og med latt finansinstitusjoner ha servere inne i selve børsbygningen. En daytrader er derfor normalt sjanseløs mot slike lynkjappe roboter, som har blitt beskyldt for alt fra juks til å forårsake unormalt store svingninger i aksjemarkedet.

Så hvorfor er myndighetene da så ivrige etter å ta to amatørinvestorer for å ha lurt en slik robot. Dette er tross alt en klassisk david-mot-goliat-historie hvor David vinner til slutt.

Jo, akkurat denne roboten hadde trolig fått tildelt en helt spesiell rolle i markedet som ”market maker”, og det går for å være nokså gjevt i robotmiljøet. Market makerens oppgave er å tilby kjøps og salgskurser for små og lite likvide aksjer. For enkelte verdipapirer er en slik aktør helt avgjørende for at det i de i det hele tatt skal eksistere et marked. Oslo Børs ber derfor av og til meglerhus om å passe på enkelte aksjer med spesielt lav omsetning ved å påta seg denne oppgaven. Meglerhuset forplikter seg da til å holde differansen mellom kjøps og salgskurs innenfor et gitt nivå. For den vanlige investor betyr det at en enkelt kan få omsatt aksjene en sitter på, noe som reduserer risikoen betydelig. Meglerhusene bruker automatiske handelssystemer til dette, eller roboter, og tjener på sin side på at kursene han kjøper til jevnt over er lavere enn de han selger til.

Det er imidlertid helt avgjørende at roboten endrer kjøps og salgskursene kontinuerlig i takt med ordretilgangen. Hvis ikke vil eksempelvis en økning i tilbudet føre til en stadig større beholdning av aksjer og en tilhørende økning i den finansielle risikoen. Roboten i denne aktuelle saken har fulgt den meget enkle regelen at kursen justeres opp hver gang noen kjøper aksjer.

Denne enkle strategien kan utnyttes. En kjøper et større antall aksjer til gjeldende salgskurs. Deretter ”dytter” man robotens kjøps- og salgskurser oppover ved å kjøpe små ubetydelige kvanta til økende pris. Når kjøpskursen er høyere enn den opprinnelige salgskursen, selger man alle aksjene.

Bør så dette være ulovlig? Oslo Børs vil hevde at dersom det skal være lov å manipulere tynne markedet på denne måten, så vil de små selskapene forsvinne ut av børsen. På den annen side så har ikke denne roboten vært spesielt oppvakt. De som har programmert roboten må ha vist om denne sårbarheten, så det er jo litt rart at man ikke har laget en sikkerhetsmekanisme som i alle fall kunne luket ut 2200 repetisjoner av en enkel strategi. Det kan imidlertid ha vært kontraktsmessige grunner til robotens enfoldighet. Børsen kunne også kanskje ha hindret dette ved å innføre restriksjoner på reversering av ordrer i slike småselskaper, men det ville fjernet daytraderne og omsetningen som de bringer med seg til markedet.

For den vanlige investor er det jo heller ikke åpenbart at det er ulovlig kursmanipulasjon en bedriver når en dytter på kursen. På meget kort sikt er jo tross alt markedet et nullsumspill der den enest tap er den andres gevinst. For daytradere handler derfor hele spillet om å lure andre investorer, så hvorfor skulle det være ulovlig å loppe akkurat denne tungnemme karen? Av den grunn hadde det ikke skadet om børsen hadde lagt inn begrensninger på slik aktivitet på forhånd heller enn å straffeforfølge i ettertid.

Selv for en market maker utstyrt med puls og hjerne er det vanskelig å beskytte seg 100% mot denne type markedsmanipulasjon. Oslo Børs burde derfor kanskje ha strengere regler for børsnotering slik at de minst likvide aksjene som det er vanskeligst å drive market making for, fjernes fra markedsplassen.

Alternativt kan man forsøke å finne måter å drive market making som ikke er så utsatt for markedsmanipulasjon. Én vei å gå er naturligvis å utvikle smartere roboter. I så fall er det ikke nødvendigvis en god idé å straffeforfølge investorer som avdekker feil.


Market maker:
• En aktør som tilbyr likviditet til markedet ved å både være selger og kjøper samtidig. Market makeren stiller en kjøpskurs og en salgskurs og tjener på differansen.
• I enkelte markeder, slik som Oslo Børs, er det kun market maker for de minst omsatte aksjene. Gjennom en avtale med Oslo Børs gis en market maker ansvaret for å tilby likviditet i en bestemte aksje.
• I enkelte markeder, slik som NASDAQ i USA, oppfordres alle investorer til å drive market making ved at man får en rabatt på handelsavgiften dersom en stiller kjøps eller salgskurs.

Read More

Commercial web scanners and the word "suck"

I had an interesting debate on a public mailing list today. It might have started with me casually claiming that commercial scanners are "sucky" - and escalated with both the former CTO of SPI Dynamics and the former director of Watchfire both expressing their displeasure. Their take is fair - but this particular argument is perhaps interesting enough to capture it here in a more coherent form.

Let's begin with a relatively uncontroversial observation: we simply don't know how to build decent web application scanners today - be it in the commercial or the open source world. How bad is the issue? Consider that the following topics essentially remain the Millenium Prize Problems in this field:

• Deciding whether two HTTP responses seen at two different URLs functionally correspond to the same component. Many unrelated pages look very much alike, because of the heavy use of headers, footers, and other templates. Conversely, a single page may change appearance every time it is requested if the content is generated dynamically. Pretty much every single fuzzy matching algorithm used here has spectacular and common failure modes.

  
  

• Deciding what constitutes "page not found" and "error occurred" responses for various parts of the website, a prerequisite for a crawl. This task gets particularly interesting when various URLs are mapped to several different back-end frameworks, a common scenario in enterprise settings; in some of these cases, HTTP response codes are not passed through to the end user, too.

  
  

• Figuring out how the application encodes query parameters and interprets URL paths. Surprisingly, even the most respected and largest enterprise vendors - say, SAP or Oracle - often treat RFCs as a friendly suggestion at best, and invent their own, outlandish conventions for no apparent reason. Throw mod_rewrite into the mix, and things get seriously hairy.

  
  

• Telling whether a particular security attack probe succeeded at all. Consider testing for a buffer overflow: both a successful attack on a vulnerable code, and tripping a security exception due to a well-implemented parameter length check, may result in an identical HTTP 500 response. What next?
  

The list goes on. In the end, automated scanners very often fare poorly when it comes to finding security bugs: they consistently fail to reach or properly recognize all the low-hanging fruit, spew out significant amounts of false positives - and just as often, simply catch fire when attempting to crawl a site in the first place.

This does not mean that web application scanners are worthless; but their primary value lies in equipping a skilled, human pentester with the initial view of the structure of a site; and automating certain cumbersome tasks, such as the execution of brute-force attacks. The reality is harsh: without the right person behind the wheel, the output of such a scanner, no matter how well tabulated and color-coded, tells you next to nothing about how secure your infrastructure is.

Regrettably, skilled pentesters with in-depth vulnerability hunting expertise, and excellent insight into how the web actually works, are exceptionally hard to get; heck, they are even difficult to recognize: there are no meaningful certifications, no particularly useful professional bodies... and even an impressive employment history or a history of conference presentations is a hit-and-miss indicator.

As a result, many commercial entities end up without the low-level security expertise needed to truly benefit from running a web security scanner - and in absence of this, they unrealistically expect the tool to give them some sort of a turn-key insight into the unknown. This never works as expected; and with nobody equipped to reliably evaluate the quality of the crawl, or the accuracy and ingenuity of the probes used, there is not even a proper feedback loop.

The problems the customers have here reflect negatively on the vendors, too: the company eventually accumulates a baggage of institutional customers who do not exert any pressure on improving the products to - let's say - always have cutting-edge SQL injection checks; and heavily focus on more easily verifiable, but peripheral functionality, instead: plug-and-play support for all sorts of internal SSO systems, elaborate reporting capabilities, compliance-related views that can be shown as a proof of due diligence, and so forth. All these features have some value, of course - but ultimately, they divert resources from the one pursuit that matters the most: helping a skilled pentester, and getting better at it.

In this sense, the commercial vulnerability scanner market is, by large, driven by pathological incentives - and will probably remain this way, at least until enough skilled professionals enter the workforce, or - less likely - until a major technological breakthrough is made.

Now, here's an interesting tidbit: have a look at the open-source vulnerability scanner world. Almost all the web application scanning tools that cropped up in the past two years are written by active bug hunters who use these tools in their day to day work, and were unhappy with what commercial tools have to offer. Not all of these alternatives are good, and not all will succeed - but they are developed with a very important goal in mind: to get really good at spotting bugs, and nothing more. Many of them already surpass some of the more stagnant commercial offerings in this department - and the improvement will continue.

I am very reluctant to make sweeping statements about the superiority of one software development model over another - but in this case, it seems to make a real difference, at least today. And, sure, I recognize that this argument goes both ways: the moment those open source developers start deriving most of their income from selling their products, rather than from consulting services, many of the tools will (as one person put it) quickly begin to suck.

Read More

On designing UIs for non-robots

In a typical, attentive human subject, the usual latency between a visual stimulus and a voluntary motor response is between 100 and 300 milliseconds. As should be evident, we do not pause for that long to assess the situation after each and every muscle movement; instead, we routinely schedule series of motor actions well in advance - and process sensory feedback only after the fact, in an asynchronous manner. Within that sub-second window of opportunity, we are simply unable to abort a premeditated action - even if things go wrong.

And here lies an interesting problem: on today's blazing fast personal computers, a lot can happen in as little as one-tenth of that timeframe. Within a browser, windows can be opened, moved around, and then closed; system prompts triggered or destroyed; programs launched and terminated. In such an environment, designing security UIs that take human cognitive limitations into account is a tricky game: any security-relevant prompt that does not enforce a certain amount of uninterrupted, distraction-free, in-focus screen time before accepting user input, is likely completely broken.

Intuitively, this just feels wrong - surely, humans can't be that bad, so the issue can't be that serious - but this is exactly the sort of a fallacy we should be trying to avoid. There is nothing, absolutely nothing, that would make attacks impractical; increasingly faster JavaScript has the ability to programatically open, position, resize, focus, blur, and close windows, and measure mouse pointer velocity and click timings with extreme accuracy; with a bit of basic ingenuity, any opportunity for a voluntary user reaction can be taken out of the equation. That's it: we suck, and there is nothing you can do to change it.

To back this claim, let's have a look at the recently-introduced HTML5 geolocation API; the initial call to navigator.geolocation.getCurrentPosition() spawns a security prompt in Firefox, Opera, Chrome, Safari, and a couple of other browsers. This UI does not implement a meaningful delay before accepting user input - and so, this
crude and harmless Firefox proof-of-concept can be used to predict the timing of mouse clicks, and steal your location data with an annoyingly high success rate. This particular vector is tracked as Mozilla bug 583175, but similar problems are endemic to most of the new security UIs in place; the reason is not always simple oversight, but often, just explicit opposition to the idea of introducing usability roadblocks: after all, to a perfect human being, they are just a nuisance.

Fine-grained click timing is, of course, not where the story ends; it has been demonstrated time and time again that with minimal and seemingly innocuous conditioning, healthy and focused test subjects can be reliably duped into completely ignoring very prominent and unusual visual signals; the significance of this problem is unappreciated mostly because not many exploit writers are behavioral scientists - but that's not very reassuring thought.

There is some admirable work going on to make browser security messaging more accessible to non-technical users; but I'd wager that our problems run deeper than that. We are notoriously prone to overestimating the clarity of our perception, the rationality of our thought, and the accuracy of our actions; this is often a desirable trait when going through your life - but it tends to bite us hard when trying to design security-critical software to be used by other human beings.

We need to fight the habit the best we can, and start working on unified, secure human-to-machine interfacing in the browser. If we dismiss our inherent traits as an out-of-scope problem in security engineering, we will lose.

PS. On a somewhat related note, you may also enjoy Jesse Ruderman's recent 10-minute presentation about UI truncation attacks.

Read More

BP, oljekatastrofer og risikospredning

Oljefondet har fått mye ufortjent kritikk for sin eksponering mot det brittiske oljeselskapet BP i etterkant av oljekatastrofen i Mexicogulfen. Siden oljerelatert virksomhet utgjør en betydelig del av verdens verdiskapning så tilsier referanseindeksene som oljefondet følger at de gjør store investeringer i slike bedrifter. En kan alltids kritisere fondet for ikke å ha ringt 800-nummer for å få hjelp til å forutse krisen, men utover det blir kritikken av investeringene i BP nokså meningsløs.

Et mer grunnleggende spørsmål er imidlertid hvorfor referanseindeksene inneholder oljeaksjer i det hele tatt. Norge er allerede overeksponert mot oljeprisrisiko gjennom mange kanaler i form av skatteinntekter, eierskap i Statoil, og ikke minst eierskapet til ressurser som fortsatt ligger på havbunnen (SDØE). Om vi priser inntektene fra disse virksomheter som aksjer og regner det som en del av oljefondet, så har vi trolig en eksponering mot oljemarkedet alene på i alle fall samme størrelsesorden som det eksisterende fondet på snart tre tusen milliarder kroner.

En av de viktigste innsiktene som finansteori kan gi er at om en sprer investeringene så senker en risikoen uten at det gir lavere avkastning. Dette konseptet er altså så nært en gratis lunsj som en kommer i økonomifaget. Staten kan oppnå slik risikospredning for eksempel ved å selge seg ned i Statoil og SDØE, men det er ikke politisk mulig. En enkel, kostnadsfri og upolitisk løsning vil imidlertid være å renske ut alle oljerelaterte aksjer fra oljefondet. Så hva er årsaken til at en ikke allerede har gjort det?

Finansdepartementet har naturligvis tenkt nøye gjennom akkurat det, og argumentene for å la fondet fritt investere i oljeaksjer er flere. Blant annet mener departementet at oljefondets beholdning av oljeaksjer er liten og at lav samvariasjonen med oljeprisen uansett tilsier at gevinsten ved denne type risikospredning er minimal. I tillegg har departementet det noe selvmotsigende argumentet at olje og gass sektoren utgjør en så stor andel av den globale indeksen og har gitt så stor avkastning at det vil være galt å utelukke slike aksjer.

Det er imidlertid flere svakheter med denne argumentasjonen. For det første er det jo slik at ettersom oljefondet vokser og reservene svinner så vil oljeaksjene i fondet utgjøre en stadig større andel av vår samlede formue. Allerede i dag er olje- og gassaksjene trolig verdt om lag 20% av SDØE. Fordelen ved å luke ut oljeaksjene fra fondet vil altså bare øke med tiden. Det kan derfor være greit å gjøre noe med saken nå.

I tillegg ser det ut til at departementets anslag på risiko er feil, ettersom de i praksis har lagt til grunn at verdien av landets samlede oljeformue kan oppsummeres i spotprisen på olje. Oljeformuen avgjøres imidlertid av forventet fremtidig oljepris, akkurat slik verdien på internasjonale oljekonsern fastsettes i aksjemarkedet. Risikoen knyttet til statens oljeverdier gjenspeiles derfor trolig bedre ved å anta at de er nær 100% korrelert med kursutviklingen for internasjonale oljeselskap, og ikke havparten av dette slik som spotprisen indikerer. Dette vil i så fall gi helt andre anslag på fordelene ved risikospredning.

Som departementet nevner så har imidlertid avkastningen på oljeaksjer vært høy historisk. Det vil likevel bære helt galt av sted om en skal legge til grunn ulike sektorers historiske avkastning ved valg av portefølje, uten å ta hensyn til at slik avkastning er en indikasjon på særlig høy risiko.

Departementet mener uansett det er vanskelig å droppe oljeaksjene fordi de utgjør en så stor andel av verdens aksjemarkeder, men det er nettopp derfor disse aksjene bør utelukkes. Isolert sett vil det medføre en mer konsentrert portefølje. Det er likevel sammensetningen av vår totale portefølje, inkludert fremtidige skatteinntekter, produksjonsrettigheter og Statoil, som er avgjørende. Ideelt sett bør vår eksponering mot olje være omtrent som verdensmarkedets, dvs. om lag 12,5%. Den faktiske andelen er trolig langt over 50%.

Read More

Cookies v. The People

For some reason, The Wall Street Journal launched a new, large-scale offensive on web cookies - and decided to focus on the purported malice of Microsoft in particular:

"All the latest Web browsers, including Internet Explorer, let consumers turn on a feature that prevents third-party browser cookies from being installed on their computers. But those settings aren't always easy to find. Only one major browser, Apple's Safari, is preset to block all third-party cookies, in the interest of user privacy.

The Internet Explorer planners proposed a feature that would block any third-party content that turned up on more than 10 visited websites, figuring that anything so pervasive was likely to be a tracking tool.

When he heard of the ideas, Mr. McAndrews, the executive involved with Microsoft's Internet advertising business, was angry, according to several people familiar with the matter. Mr. McAndrews feared the Explorer group's privacy plans would dramatically reduce the effectiveness of online advertising by curbing the data that could be collected about consumers."

I do not have any insight into the decision process behind browser features at Microsoft - and it would be unfortunate if this factor alone had such a significant bearing on the final outcome. I do know, however, that the characterization of third-party cookie blocking as an important privacy feature is grossly misguided at best - and that there are compelling technical arguments to be made in favor of not enabling it by default.

The fundamental problem is that for better or worse, browsers necessarily make it trivial to track users across cooperating websites, without any need for the actors to appear malicious or evil. Quite simply, every computer system is unique, and browsers, by design, offer a substantial insight into it: very few other people share exactly the same browser and OS version, uptime, browser window size, installed fonts and applications as you - and so, reliable browser instance fingerprinting is certainly not science fiction.

This obvious possibility aside, there are many types of core web features that offer functionality essentially identical to cookies, and are depended on by much of the Internet; for example, RFC2616 caching allows long-lived tokens to be stored and retrieved through HTTP headers such as ETag, or simply embedded in persistently cached JavaScript code. The only reason why cookies are preferred is that they are well-known, purpose-built, have well-understood security properties, and can be managed by users easily. I encourage you to check out Ed Felten's excellent essay for more: the alternatives are very easy to embrace, but will suck for consumers more.

It is possible to build a reasonably anonymous browser, but only by crippling many of the essential features that make the modern web tick; products addressed to the general public should probably not go there. Disabling third-party cookies alone feels like a knee-jerk reaction that really does nothing to improve your privacy - and actually impacts your security. A striking example is that a ban on third-party cookies makes it very difficult to create XSRF-resilient single sign-on systems for complex, SOP-compartmentalized web applications (at least unless you introduce a dependency on JavaScript - the other Great Satan of the Internet).

To add insult to injury, because of compatibility issues, the existing third-party cookie blocking mechanisms gradually morphed into honor systems anyway: one implementation allows cookies to be set once the third-party frame is interacted with (which can be facilitated without user knowledge by having a transparent, invisble frame follow the mouse pointer for a while). Another allows cookies to be read and modified after the initial visit to a particular "third-party" site. A yet another implementation allows servers to declare good intentions by specifying a special HTTP header (P3P) to simply bypass the mechanism.

Given the way the web works, the most realistic way to improve user privacy is to create a community standard for notifying well-behaved players about your privacy preferences, and allowing them to comply. It will actually work better than the inevitable technological whack-a-mole with cookie-equivalent mechanisms: malicious parties will have the ability to track you for the foreseeable future anyway - but with explicit preference declarations, parties who want to be seen as reputable would not be able to assume that cookies are blocked simply because this is how your browser ships - and promptly switch to an alternative tracking mechanism in good faith. Commercial search engines obey robots.txt, so this system has a chance of working, too. If you disagree and distrust corporations, legislative approaches to privacy protection may be your only remaining bet.

Speaking of advisory privacy mechanisms, Microsoft actually deserves some credit rather than blame - namely, for supporting the aforementioned P3P signaling in their products: the associated HTTP headers are used to make cookie policy decisions in Internet Explorer, and not in any other browser. Alas, the protocol is a bit of a cautionary tale by itself: W3C attempted to create a complex, all-encompassing, legally binding framework to compel businesses to make honest, site-wide declarations; and the concept eventually collapsed under its own weight. Large businesses are extremely hesitant to use P3P, out of the risk of increasing their legal footprint; while small-scale web developers are simply intimidated by the monumental 110 page specification, and copy off recipes from random places on the web, with little or no regard for their intended meaning.

So yeah, privacy is hard. Blaming a browser vendor is easy. It's just not very productive.

Read More