Does Privacy Matter?

A few years ago, I made a tool called Collusion in an attempt to better understand how websites I’d never even heard of were tracking my adventures across the Internet.

The results my tool showed me were at best a bit creepy. I didn’t really mind terribly that third parties I’d never heard of had been watching me, in collusion with the sites I visited. I just wish they’d asked me first (through something more approachable than an inscrutable privacy policy).

But, as the old adage goes, I had nothing to hide. What do I care if some advertising companies use my data to offer me better services? Or even if the NSA mines it to determine whether I’m a terrorist?

I’m still struggling to answer these questions. I don’t know if I’ll ever be able to answer them coherently, but after reading a few books, I have some ideas.

For one thing, I don’t think it matters whether one has nothing to hide. What matters is if they look like they have something to hide.

One of the most invisible things about the Internet is that there are hordes of robots constantly scrutinizing your aggregate online behavior and determining whether you fit a certain profile. If you do, as Daniel Solove argues, your life could become a bit like that of Josef K. from Kafka’s The Trial. Or—to cite a true story—like that of Sarah Abdurrahman of On The Media, whose family was detained and aggressively interrogated for several hours at the US-Canada border for unknown reasons.

What determines whether you look like you have something to hide? The robot builders have it in their best interests to keep that secret: otherwise, the people with something to hide would simply start gaming the system. Yet this can also result in a chilling effect: innocent people self-censoring their online behavior based on what they think the robots might be looking for.

These robots don’t have to be working for the government, either. They could be working for, say, your health insurance company, looking for prior conditions that you might be hiding from them. The robots might even ostensibly work for “the people” in the name of transparency and openness, as Evgeny Morozov argues, distorting the public’s perception of you in ways that you can’t control.

What can one do to protect their privacy? One of the problems with using a tool like PGP or Tor to protect one’s privacy is that it paradoxically makes one look like they’re hiding something. When everyone lives in a glass house, you’ll look suspicious if you don’t.

Privacy problems are systemic, and I think their protections are necessarily systemic too: in order for one to not look like they’re trying to hide something, privacy needs to be a default, not something one opts-in to. Not only does this need to be done with technology, but it also needs to be accomplished through legislation and social norms.

How Colorblindness Blinds Us

When will we (finally) become a colorblind society? The pursuit of colorblindness makes people impatient. With courage, we should respond: Hopefully never.

— Michelle Alexander

In her excellent book The New Jim Crow, Michelle Alexander makes an argument that the notion of colorblindness is a deeply flawed principle that has proved catastrophic for African Americans in the post-civil rights era.

This is a notion that I find confusing, and I don’t claim to fully understand Alexander’s argument. One aspect I can relate, to, however, are the effects that occur when we set unreasonable expectations for our own inevitable prejudices.

I was particularly struck by two seemingly trivial racially-charged faux pas that occurred earlier this year. The first occurred when Lisa Lampanelli, a celebrity I’ve never heard of, posted the following Tweet:

The other was when actress Julianne Hough decided to wear blackface as part of her Halloween costume.

What surprised me wasn’t the incidents themselves, but the public’s response to them, which was to inundate the celebrities with scorn and derision. No discussions were had, and no rationales were given: the actions of these celebrities were instantaneously judged vile and offensive, and everyone was told never to repeat the same mistakes:

Race isn’t brought up very often in today’s public discourse; when it is, it usually follows this familiar pattern of a faux pas followed by scorn and a hasty apology. This is partly due to the colorblind principle, which polarizes the notion of prejudice: we’re supposed to be colorblind, and if we’re not, we’re a racist bigot. Therefore, it’s safest to never, ever mention race, at the risk of being labeled.

In 2008, a study at Northwestern University’s Department of Social Psychology found that “white subjects [are] so afraid of being branded as racist, they indicated a preference for avoiding all contact with black people.” This is something I’ve felt personally, despite not being white. And it’s no surprise, given the outcome of the aforementioned incidents and countless others like them.

The net effect of our reaction to race in public discourse—that is, the instinct to brand anyone who isn’t colorblind as racist—blinds us to everything important in our culture that is actually race-based, such as the multitude of issues surrounding the school-to-prison pipeline that Alexander addresses in her book.

In today’s world, I’d argue that racism actually has very little to do with calling a friend “my nigga” or wearing blackface. It has everything to do with the sense of fear I feel when I realize a black man is walking behind me on my way home. But until we stop pretending that we’re colorblind and building a culture of fear around conversations about race, we won’t even realize this kind of racism exists, let alone have a truthful dialogue about it.

The Role of Performance in Online Life

In Sherry Turkle’s Alone Together, the author writes:

Brad says, only half jokingly, that he worries about getting “confused” between what he “composes” for his online life and who he “really” is. Not yet confirmed in his identity, it makes him anxious to post things about himself that he doesn’t really know are true. It burdens him that the things he says online affect how people treat him in the real. People already relate to him based on things he has said on Facebook. Brad struggles to be more “himself” there, but this is hard. He says that even when he tries to be “honest” on Facebook, he cannot resist the temptation to use the site “to make the right impression.” On Facebook, he says, “I write for effect. I sit down and ask, ‘If I say this, will it make me sound like I’m too uptight? But if I say this, will it make me sound like I don’t care about anything?’” He makes an effort to be “more spontaneous on Facebook . . . to actively say, ‘This is who I am, this is what I like, this is what I don’t like,’” but he feels that Facebook “perverts” his efforts because self-revelation should be to “another person who cares.” For Brad, it loses meaning when it is broadcast as a profile.

I’m not a teenager like Brad, but I share a lot of his concerns. Turkle uses the word performance frequently when describing public and semi-public life on places like Facebook and Twitter, and it’s an apt description.

Perhaps it comes from the reaction many have when they’re sent a mass email, but I’ve always felt that the meaning of a message changes as the number of people receiving it increases. Most of my electronic communication tends to revolve around email and instant messaging with close friends; the few online communities I’ve truly felt a part of have all been gated and largely inaccessible to the general public. Communications within these realms is bounded, and context is well-defined; it’s easy to figure out what my message will mean to its recipients, whether it will be interpreted as spam, vulgarity, hilarity, or saving face. Yet beyond the mechanics of conversation lies a basic belief that the fewer people receive my message, the more it will mean to each of them.

Consequently, however, places like Facebook, Twitter, and public forums mean little to me, at least when it comes to creating and maintaining authentic connections with others. These may be places for carefully crafted banter, rational discourse, or using humanity as a lazyweb—but they are not places that feel like home.


I’ve been reading Eli Pariser’s book The Filter Bubble and was fascinated by his description of how data collection companies operate. Independently of that, David Ascher suggested that I add a feature to the Hackasaurus goggles which helps learners understand how cookies and tracking works.

I actually didn’t know a lot about tracking myself, so I whipped up a Firefox add-on called Collusion to help me visualize it better. The results were a little unsettling.

I’ve put a demonstration up at, which takes you through five popular websites and visualizes the data collection companies that track you across them. From there, you can download the add-on if you want to see the tracking visualization of your own browsing behavior evolve in real-time.

Special thanks to the Mozilla Add-on SDK team for making a great foundation to build on. This experiment also gave me a chance to play around with d3.js, which is a fantastic successor to Protovis. And thanks to PrivacyChoice for their excellent tracker list, which I’m sort of using without their permission. I hope that is okay.

I’m also not really a privacy expert, so I’m not sure if everything I say in the demonstration is completely true. If you find any inaccuracies, please let me know.

Finally, if you need the source code, it’s all at I’m particularly interested in seeing better visualizations than the force-directed graph I’m using, which regrettably requires a lot of user interaction to explore and understand.

Moving At Internet Speed

In his book Program or be Programmed, Douglas Rushkoff writes:

For most of us, the announcement of the next great “iThing” provokes not eagerness but anxiety: Is this something else we will have to pay for and learn to use? Do we even have a choice?

At Mozilla, we talk a lot about user choice, but one choice we have a hard time giving our users is whether to upgrade to the latest version of our software.

This isn’t unique to Mozilla, of course. It’s fundamentally a social problem: once developers decide to push a product in a certain direction, there’s not enough human resources left to maintain the old version for an indefinite period of time. Eventually, the old version reaches its end-of-life; one can try to keep on using it, until a security hole that goes unfixed results in data compromise, or a dependency like the underlying operating system changes and breaks the program that relies on it.

Our inventions shift beneath us like tectonic plates.

Every company wants their product to be the next great iThing, but what about people who are content with what they’ve got? Or the ones that are so overwhelmed by the other changes in their life that they simply don’t have the time to figure out how to use the latest version of their software, which has been forced upon them at internet speed?

Good Customers

Here’s something I read in a blog post by Esther Dyson, where she describes a visit to Russia in which she was asked for advice on how to spur innovation in the country:

In fact, I started my discussion with Russia’s government leaders by talking about my experiences as chair of NASA’s Innovation and Technology advisory committee. The issue, I said, was not really about funding technology innovation; it is how to create a culture that rewards thoughtful innovation and considers mistakes the price of learning.

Another requirement is good customers – that is, customers who are willing to pay good money for good products and good services, who are willing to try out new things that show promise and to give feedback, and who are unwilling to take bribes.

One of the really interesting things I’ve noticed about Apple-created markets ever since I had my first Macintosh LC in the early 1990’s is that they attract consumers who think that good user experiences are worth paying money for—an easy belief for Apple to select for, since one has to have it to buy an Apple product in the first place.

This belief isn’t the case so much in the PC world, or at least it didn’t use to be; when I came to my first Mac from a PC and browsed the troves of third-party software, I was befuddled by how many of them expected me to actually pay for them. This “culture shock” became even more acute in late 2007, when I switched from Windows to OS X and found the same thing—only this time it was a welcome change, with a few exceptions.

From Dyson’s perspective, was I simply an un-civil consumer in the early 1990’s, spoilt by the notion that getting a mediocre experience for free was better than paying for a well-designed one? I believe the strength of Apple’s platforms today has something to do with it, and it’s an interesting question to ask of any potential marketplace: what do your particular customers value enough to pay good money for?

My First CrisisCamp

On Friday I attended CrisisCamp Silicon Valley. I didn’t really know what to expect, since I was unfamiliar with the nascent field of internet-facilitated crisis response and was unable to find a high-level overview of how people—both techies and non-techies—can really make an impact.

The Bird’s Eye View

As I understand it, this is the big picture of internet-facilitated crisis response:

  1. People on the ground in a disaster are told, through various channels, to report what they’re seeing to the public through a variety of media: SMS, Twitter, Facebook, whatever’s easiest and most understandable for them. In the case of the floods in Pakistan, for instance, people are encouraged to report by sending an SMS text message to 3441, making sure to add FL to the beginning of the message.
  2. These raw reports are collected or found by programs on the Internet that send them all to a site for processing by humans, who classify and categorize them in various ways: for instance, does the report represent an emergency that needs attention, or a dangerous obstacle that aid workers should be aware of? Does the report need translation from a different language? To what area of the disaster area does the message refer? In the case of the Pakistan floods, you can visit right now to do this yourself—all you need to enter is your email address, and you’re presented with a brief message that someone on the ground sent.
  3. Multiple people actually process the exact same report, which allows a computer program to correct for errors and combine information in the various responses—much in the same way that having two eyes is better than having one. This means participants don’t need to get too stressed-out about accidentally providing inaccurate information.
  4. The processed reports are then collected at another site on the internet, where they effectively constitute a public resource that anyone can use. The most obvious consumers of the data would be the relief workers on the ground. The public data set, its associated software, and its user interface is sometimes referred to as Ushahidi or an Ushahidi instance—check out the Wikipedia entry on Ushahidi for more background on why. There’s a Ushahidi instance for the Pakistan floods at

If you’re familiar with real-time strategy games like StarCraft II, this whole process could be envisioned as crowd-sourcing a mini-map of a disaster area. The people involved in the crowd-sourcing aren’t directly helping in the sense of actually rescuing people, but their mediation between people on the ground is providing a valuable set of “eyes and ears” for everyone involved.

The Dirty Details

In practice, this process is a lot more chaotic than it seems, which creates new problems that need solving. For instance, while I’m very used to Google Maps containing highly accurate data about where I live, many of the cities, towns, roads, and other places mentioned in reports from Pakistan either aren’t visible on Google Maps at all, or are known by multiple names, depending on language and locale. Because of this, one of the ways people familiar with the disaster area can help is by using OpenStreetMap, a sort of cross between Wikipedia and an atlas, to add information about places that conventional commercial sources don’t contain.

While I was at CrisisCamp SV, one of the technical problems that needed a solution was the fact that Facebook was reportedly much more popular than Twitter in Pakistan; relief workers on the ground wanted to be able to tell the public that they could join a Facebook group and post their reports on its wall, but they didn’t know how to import the data from the wall into the site that processed raw reports, so I wrote a simple Python script to convert the wall data into an RSS feed using Facebook’s Graph API.

Crowd-Sourcing and Communities of Practice

The interesting thing about my contribution is that it was just one possible solution to a problem: humanitarian agencies on the ground didn’t actually know if posting to a Facebook group’s wall would be a solution that the population would use, but just having a solution available was better than complete uncertainty. I don’t typically write code when I have a low degree of confidence that the code will actually be useful to someone, but I nonetheless decided to write it up.

In general, a number of people I talked to at the CrisisCamp had a less-than-ideal degree of confidence that their individual contribution was providing concrete aid, but there was a lot of faith in the sum of what everyone was doing as a whole, the belief that people on the ground would benefit immensely from this crowd-sourced radar we were creating.

I’ve typically been very skeptical of the term “crowd-sourcing”, primarily because its use in language has a tendency to abstract away the notion of human individuality: people become fungible processors or gadgets that are doing things that we simply haven’t figured out how to do with computers yet. In a lot of ways, the language surrounding it dehumanizes us in the same way that assembly lines and mass production dehumanized the nature of work during the industrial revolution.

From this perspective, one of the greatest strengths of events like CrisisCamp, and organizations like CrisisCommons, is their ability to provide group membership, to create meaningful connections between people who want to help, and to create new kinds of communities of practice. If I hadn’t attended the CrisisCamp event, I certainly wouldn’t have written that Python script, but because of the social context—the notion that I would be creating something that could be recognized by people with similar interests and lead to connections with them—I found a lot more meaning in it than I otherwise would. This is, of course, the same kind of motivation that engages people to volunteer, to create resources for their World of Warcraft guild, or to contribute to an open-source project.

How Mozilla Can Help

A few days ago, Mitchell Baker wrote a blog post in which she wondered how Mozilla could help with humanitarian crises. One thing I noticed about the chaos surrounding the Internet-based efforts was that, like Mozilla, they were formed very organically: this meant that there were a plethora of activities going on which anyone could participate in, but the picture presented to a newcomer was confusing and messaging wasn’t always consistent. Tasks needed to be completed urgently; the changing landscape on the ground meant that problems and solutions were constantly changing, and assumptions were frequently challenged. Keeping the Web in-sync with reality could be difficult, especially since the Web doesn’t forget things.

Combined with the distributed nature of the solution, acquainting newcomers with a reasonably humane workflow for contributing was non-trivial: just processing a report on, for instance, often meant switching between tabs containing, OpenStreetMap, and a Google Docs page containing advice and other resources. There was a lot of copying and pasting involved.

There’s many ways browsers could help with this. For one thing, addons or GreaseMonkey Scripts could make the experience of contributing easier. While I didn’t get around to it, for example, I could easily imagine an addon or Ubiquity command that mashed-up with, OpenStreetMap, and other services to provide a streamlined interface, potentially eliminating the need to learn how to use those other websites and copy/paste. In other words, since the solution to these problems is on the Web, we can use the inherent hackability of the Web to make the solutions much easier to use.

Another thing I noticed was that the vast majority of browsing activity occurring while helping out was largely privacy-insensitive: reports were submitted from the ground with the expectation that they would become public, the CrisisCommons wiki was completely public, as was any activity on Twitter or even the Facebook group. There was also a lot of link-sharing and people looking at one another’s screens as they figured out workflows and discovered solutions, so the notion of a sort of “public browsing mode”, or perhaps a separate browser tweaked to broadcast all its activity to the internet or a specific group of people, is an interesting one.

Aside from that, some of the affordances present in the Mozilla community and other open-source projects seemed like they could help the CrisisCommons efforts a lot. As far as I could tell, for instance, there wasn’t any kind of real-time virtual space or chat room where the community could hang out. There also wasn’t any kind of issue tracker, which seemed like it could be useful, too.

In any case, CrisisCamp SV was a really interesting experience, and I’m looking forward to attending more events like it.

Ethnography, Usability, and Community

Context offers fodder for innovation. Hidden in the physical work space, in the users’ words, and in the tools they use are the beautiful gems of knowledge that can create revolutionary, breakthrough products or simply fix existing, broken products.

I’ve been talking with my colleague Jinghua Zhang, the project lead for Mozilla’s Test Pilot program, about the usefulness of ethnography and qualitative research in user interface design, and it seems like something that could both strengthen Mozilla’s community and help make our products easier to use.

A few months ago I picked up Hanging Out, Messing Around, and Geeking Out, a book in the John D. and Catherine T. MacArthur Foundation Series on Digital Media and Learning, which contains twenty-three ethnographic case studies on how young people are “living and learning with new media.” The studies span an impressive variety of socio-economic groups and social contexts, and nearly all of the interactions that take place in these studies are mediated through a web browser—so I thought this might be a useful opportunity to learn more about our users.

One Example: Techne-Mentoring

While I haven’t yet finished reading the book, one of my favorite case studies so far is Megan Finn’s section on “Techne-Mentoring”. As I’ve explained in my post on Kids and The Open Web, when I was wee, learning about computers was very much about creating and hacking on things that I could share with my friends and parents. Computers were mostly a hobbyist’s toy.

Today, however, the computer is an indispensable information appliance that everyone needs to use. It’s also constantly beset with viruses, bugs, and design flaws that confuse and frustrate people. Finn’s study on Techne-Mentoring focuses on this when she asserts that many young people interested in technology gained their expertise not necessarily by creating or remixing things, but by learning how to get rid of viruses on their families’ computers, or learning how to work around some other technical problem. This knowledge becomes a valuable social asset, allowing the individual to become an informal mentor in their family or peer group.

This got me thinking: the primary gateway to messing around with advanced features in Firefox is the about:config page, which we currently caveat with this dire warning:

If a young person who’s fixing their family’s computer is seeing this screen, why not take this opportunity to invite them to share their expertise with our vibrant support community? Community is, after all, one of Mozilla’s strongest assets, so it may be useful to link to it at relevant touch-points in Firefox’s user interface.

Going Further

We can get even more meta: how awesome would it be to actually help our community members become amateur ethnographers, doing things like observing and interviewing their friends and family to help Mozilla learn more about its users and design better products? Maybe it’s a crazy idea, but ethnography does seem like an incredibly useful asset for interaction design, and I’m eager to learn more about it.

On The Webbyness of an Installable Web App

I’ve heard some talk lately, primarily from Henri Sivonen, regarding whether Google’s notion of an Installable Web App is “webby”.

I am not sure exactly what webby means, but if I had to guess, it would involve the kinds of qualities that Mitchell Baker and Mark Surman believe make the web better: more transparent, participatory, decentralized, and hackable.

Though I’m not fully sold on these newfangled apps, I can think of three ways that they could make the web better.

The Usability of Files

At first glance, one might say that putting some web pages and scripts into a ZIP file marginally reduces transparency, as one now has to unpack it to see the original code.

However, this simple mechanism addresses a significant barrier to web development that isn’t often captured by web standards: casual developers intuitively understand files because—for better or for worse—they’re something that’s an integral part of the way one interacts with their computer from day to day. The notion of creating some files on one’s computer and making them available to the rest of the internet is reasonably simple and profoundly powerful. The operative metaphor of a ZIP file—putting a bunch of files into a little box that can be delivered as a single file and unpacked later—isn’t hard to understand once one knows what a file is. While it’s a bit of a hassle to put things into the box and unpack them, most operating systems already offer tools to make this easier for ordinary users.

Introduce the notion of HTTP Response Headers, however, and barriers start to appear: this is a completely different concept from files, requires an understanding of the Hypertext Transfer Protocol to not be completely mysterious, and requires learning the particularities of tools that one may not even be aware that they’re using.

Dump some files onto a server and you don’t even need to care whether that server uses Apache, Microsoft Internet Information Services, Lighttpd, or something else. Add a requirement to a Web standard that an arbitrary file be served with a special MIME type via an HTTP header, however, and suddenly a casual Web developer has to become aware of an entirely new layer of technology that they were previously blissfully unaware of.

The reason I mention this is because there are at least two different web standard proposals I know of that involve the use of ZIP files to make it easier for casual developers to participate in the web and make it better. One of them is Alexander Limi’s Resource Packages specification, and the other is Google’s proposal for Installable Web Apps. Both of them involve taking things that are currently arcane—configuring a web server to automatically serve files with compression over a keepalive connection and serving an offline web application with a cache manifest of type text/cache-manifest, respectively—and make them easy and understandable for non-professionals.

With some browsers already capable of introspecting into ZIP files, the effectiveness of View Source—the enabler of transparency and hackability—need not be reduced. In fact, it could even be increased: if putting JavaScript into a compressed ZIP file reduces its size enough to make minification less of a necessity when it comes to delivering Web content quickly, then more web content will be delivered in way that others can learn from and remix.

Untethered Applications

Google’s proposal for Web Apps actually makes the internet a more decentralized place, because it contains provisions for creating and sharing entirely serverless, untethered applications. Using the terminology of Jonathan Zittrain, this makes it easier for control to be transferred to the endpoint that users are (hopefully) in control of. That said, there are other proposals that could technically enable similar use cases, such as Brandon Sterne’s excellent Content Security Policy.

Webs of Trust, Not Heirarchies

Another area in which Installable Web Apps could decentralize the internet has to do with the field of trust. It’s currently very difficult to actually prove that a piece of Web content or functionality I created came from me, and wasn’t altered at some point by someone else. The only viable way to do this is via Secure HTTP, which requires asking an authority for permission to issue you a certificate. That this frequently involves paying them money and that the system is susceptible to corruption are besides the point. As Mark Surman mentions in a draft of Drumbeat’s mission statement:

Ultimately, our goal is a strong, safe open internet: an internet built and backed by a massive global community committed to the idea that everyone should all be able to freely create, innovate and express ideas online without asking permission from others. (Emphasis mine)

It should be possible to prove to other people that something came from you without having to ask permission from someone else, and in this respect, even though this mechanism is part of the Web, I would argue that it is profoundly un-webby. Google’s proposal for Installable Web Applications associates an application’s identity with a public key that doesn’t require a blessing from any kind of authority; all versions of the application are self-signed by the key, which makes it far easier to establish trust between a user and an application. The trust model is also more granular and secure, because it creates a trust relationship between the user and the particular application they’re using, rather than the server they’re connecting to—which often isn’t even under a web developer’s full control. It’s because of this that we’re using a similar mechanism in Jetpack; extending it to the entire Web would be very webby, not coincidentally because it establishes a foundation for what could eventually become a web of trust.


While I’m still on the fence regarding whether Google’s proposal for Installable Web Apps are the best solution for a better Web, I do think that they’re a step in the right direction. In particular, they address social issues and usability concerns that, if resolved, will make computing life more transparent, participatory, decentralized, and hackable for everyone.

You Are Not a Gadget

This is what a social network looks like.

Each dot represents a human being. Each line represents a social connection between two people, such as acquaintanceship, financial exchange, friendship, or love. The picture can become arbitrarily more complex as we take one-way relationships into account and add more dimensions to model particular interests and behaviors.

Much of the attention around technology these days has something to do with this picture. Authors like Clay Shirky write about amazing things that can happen when the amount of effort needed to transmit information through the lines is drastically lowered. Companies like Google harvest information from the dots to offer better services to them; products like Amazon’s Mechanical Turk harvest little slices of spare time from the dots to quickly complete otherwise unwieldy tasks; games like Zynga’s Farmville are designed to propagate through the lines like a virus.

Advertising companies and some advocates of open-source software don’t even refer to the dots as human beings: they call them “eyeballs”. The involvement of just one pair of eyeballs means just a few cents to a revenue stream or a single bug-fix in a software program, but when the process is scaled, it results in billions of dollars of profits or bug-free software.

Jaron Lanier, the author of You Are Not a Gadget, is not interested in dots and lines. Indeed, he finds it strange that the relationship between two people is reduced to a mere line, and that the people themselves are just dots.

Instead of reducing things, he claims, we should be using technology to deepen the connection between two people and make it more meaningful.

You Are Not a Gadget is a complex book. I originally bought it because, flipping through its pages at a bookstore, I found random fragments to offend me. Even though I don’t agree with everything the author has to say, I still found it a fascinating read that I’d recommend to anyone with an interest in technology and where it’s taking us.