I had spoken with a high level Mozilla rep (will remain nameless since I didn’t receive confirmation that I could publish the conversation in full) after the release of version 4 about this important design flaw, and the person told me they were up against hard deadlines to get the feature included in version 4, and didn’t have time to tweak the preferences GUI. The representative agreed this was “less than ideal” and promised that the entire privacy panel would be “revamped” in future releases.

Today, Mozilla has released version 5 of its popular browser, and they have kept their promise. In this new version, the option to turn on “Do Not Track” is rightfully located at the very top of the “Privacy” tab in the preferences panel:

(Another notable enhancement is that the Do Not Track feature now works across platforms.)

I’m glad to see that Mozilla is paying attention and (finally) recognizing that these design decisions matter.

This is an important step towards giving Web users more control over how their digital steps are being monitored and recorded. The Future of Privacy Forum has been tracking the history of this feature for some time, and we had a conference call with Mozilla, Microsoft, and Google a few weeks ago to learn about their various (and varying) methods for allowing users to prevent tracking.

Here’s how Firefox’s Do Not Track feature works:

For more background, please see Chris Soghoian’s detailed history of the inception of the opt-out header concept, as well as the DoNotTrack.Us website for full details on the broader project supporting these initiatives.

Note, however, a critical limitation (currently) to the Do Not Track method: it requires third-party advertisers to recognize and properly react to the DNT header sent to them from your browser, and there’s no requirement that they must. As Firefox notes: “Honoring this setting is voluntary — individual websites are not required to respect it.” While implementing the header should be easy for advertisers, no advertising network or other tracking service has yet announced plans to honor the Do Not Track header. The FTC might require something similar, and we can hope that public pressure might lead ad networks to voluntarily adopt Do Not Track, but for now, this is merely the expression of a user’s privacy preference that falls on deaf ears.

Despite this limitation, it still is very important and meaningful that Firefox has implemented Do Not Track for its millions of users.

The problem is, unfortunately, they made it very hard to turn Do Not Track on.

Today I installed Firefox 4 and went to the preferences panel to see for myself how Do Not Track has been implemented. Logically, I went to the Privacy tab first:

Here, all I see is a default setting of “Remember history”, noting that “Firefox will remember your browsing, download, form and search history, and keep cookies from Web sites you visit.” This default is discomforting. Looking at the menu of options, I see I can select “Use custom settings for history”:

Here, at least, I control whether Firefox stores my browsing history, or accepts third party cookies, etc. But, Do Not Track is nowhere to be found on the Privacy settings control panel.

Next, I try the Security tab, since Do Not Track is pitched as a security feature by Mozilla. Again, no settings for Do Not Track are provided:

Finally, I click on the ubiquitous “Advanced” settings tab. Bingo! Look closely, and you’ll see a setting for “Tell web sites I do not want to be tracked” among the list of browsing settings. And, of course, the default setting is to not have Do Not Track activated:

This design choice is very troublesome. Do Not Track is a major development in potentially providing Web users more privacy, security and control over their online activities. Mozilla brags about “leading the Web towards a universal standard Do Not Track feature,” and its own (draft) Privacy & Data Operating Principles talks about providing “real choices,” “sensible settings,” and “user control.” Yet, the setting to turn on Do Not Track is buried in the Advanced preferences tab, and listed alongside such mundane options for smooth scrolling and spell check.

Mozilla, you can do better than this.

Last week, however, this all changed. Google announced two new “features” in Latitude: Location History and Location Alerts.

Location History allows users to opt-in to having Google keep a history of their locational data tracked by Latitude. Only you can see it, and you can remove items from your history, which is great. But for everyone who activates this service, there’s now a log in Mountain View of everywhere your cellphone has been, a log that could be shared with third parties in according with its privacy policy.

More people might activate Location History when they learn about Location Alerts, a service that notifies you if a friend happens to be nearby. The beauty of Location Alerts is that you won’t be altered when people are simply engaging in their routine activities (ie, you won’t be alerted every time your coworker sits down at their cubicle across from you) . Instead, it “learns” what users’ “normal” locations are, and only notifies friends if they are nearby in an unusual place or time. To make this work, you need to have Location History activated, and in the process, Google is able to create a type of “locational profile” for each user. It is unclear whether this profile might be used for other purposes (ie, targeted advertising).

Google, of course, realizes the privacy implications of all this, and again takes some steps to help mitigate these concerns. there are FAQs for each product detailing how they work and the privacy concerns; the services are op-in; users are reminded periodically when they have Location History activated (Google should do this for all products, btw).

But all this makes me wonder: did Google plan to provide these services from the start, just with a delay? Did Google learn the lessons of Facebook, who repeatedly bites off more than it can chew as it relates to users’ privacy, and decided to launch Latitude without these features, thereby winning the praises of privacy advocates (guilty), and then strategically add them 9 months later, claiming it is simply in response to user demand?

If my fears are true, it’s not quite what I had in mind when calling on Google to engage in value-conscious design in order to protect user privacy.

All this said, I was quite excited at the launch of Google Dashboard:

Google describes Dashboard as a simple way to view “the data associated with your account”, and that it will provide users “greater transparency and control over their own data.” Elsewhere, Dashboard has been described as a “big concession to users’ privacy rights“, as the answer to the question: “What does Google know about me?”, and as a place providing users “more control over the personal information stored in Google’s databases“.

Unfortunately, Google Dashboard is none of these things.

What Google Dashboard provides is a single place to browse the list of most of the Google services you’ve signed up for, quick links to their individual settings pages (including privacy settings & policies), summary statistics of your usage of these services, and indications of what details I’ve shared with others.

While this is a very convenient new interface, and a helpful reminder of some of the services and settings that I might have long forgotten were activated on my account, Dashboard isn’t providing any new transparency or new control over the data Google knows about me. I still only see that information Google wants to make available to me through its interfaces. I still only get to control the limited data Google allows me to control.

Sure, from the Dashboard I can go and look at my Web search history, for example (and this screenshot confirms that my TrackMeNot Firefox Extension is successfully sending ghost queries to Google!), and from there I can remove stored searches from the service. But remember, this is only removing the searches from the Web History service, not from Google’s primary search query logs (as Google acknowledges here). There is no new level of control over the personal information stored in Google’s databases. Simply convenience.

(And, FWIW, Dashboard could be made even more convenient if Google simply had a link to “Dashboard” in the upper right corner after you log in, rather than having to click Settings -> Google Account Settings -> View data stored with this account)

The convenience Dashboard provides is helpful. Users should be regularly reminded of what services they sign up for, what information is being collected, and what their current privacy settings are. And hopefully Facebook will follow Google’s lead and provide similar convenience. But, unfortunately, Google Dashboard is no concession to users’ privacy rights. A helpful step, but we still have a long road ahead of us.

UPDATE: Others agree with my assessment of Dashboard. ReadWriteWeb notes that “Google’s Privacy Dashboard Doesn’t Tell Us Anything We Didn’t Know Before”, while Mashable recognizes that “Dashboard is nothing more than a selected list of privacy-related settings”. And Fred Stutzman correctly observes in the comments below that “By creating this interface, Google gets to functionally define the “sense” of information collection/retention. That is, their sense of the boundaries of collection will be informed by the interface. But…this interface minimizes the true extent of data retention.” Indeed.

Online behavioral advertising (OBA) refers to the practice of tracking users across web sites in order to infer user interests and preferences. These interests and preferences are then used for selecting ads to present to the user. There is great concern that behavioral advertising in its present form infringes on user privacy. The resulting public debate — which includes consumer advocacy organizations, professional associations, and government agencies — is premised on the notion that OBA and privacy are inherently in conflict.

Privads is a practical architecture that enables targeting without compromising user privacy. Behavioral profiling and targeting in Privads takes place in the user’s browser.

Our technical paper discusses the effectiveness of the system as well as potential social engineering and web-based attacks on the architecture. One complication is billing; ad-networks must bill the correct advertiser without knowing which ad was displayed to the user. We describe a cryptographic billing system that directly solves the problem. We implemented the core targeting system as a Firefox extension and report on its effectiveness.

While some are skeptical about whether Privads will be fully effective and/or embraced by the online advertising industry, this is the kind of innovative, values-based design that we need to mitigate the growing threats to privacy online.

Google has conceded, and will now erase identifiable raw data depicting people, property, or cars upon request.

This is a first, and it is significant, but it is an exception only for Germany.

Rather than taking a broader value-centered approach to designing its systems, Google continues to base their decisions based (primarily) on local laws. The U.S. lacks laws guaranteeing individuals “privacy in public,” so Google launches street view with minimal (and poorly-executed) ability to protect one’s privacy. Canada, however, does have such laws, so Google decided to blur faces there (but only applies that engineering solution to Canada). Now, Germany wants the source data purged, so Google will only provide this privacy-protecting measure to that local authority.

A broader values-centered approach would (learning from the Canadian and EU legal environment) recognize that protecting one’s privacy in public might indeed be a fundamental right, and perhaps is something that must be designed into such a potentially privacy-invasive tool as Street View.

I’ve informally chatted with Google folks about these issues, and I applaud that they do have law/policy folks on every product team. But too often, when asked about something like “why didn’t you blur the faces in the U.S. version”, the answer is “the law doesn’t require it”. Such a strict legal approach to designing (or not) ethics into products is extremely shortsighted.

Do we need to start calling for Chief Ethical Officers in our corporations?

The open letter is signed by 38 researchers and academics in the fields of computer science, information security and privacy law — myself included. The letter was spearheaded by Christopher Soghoian, a computer researcher, programmer and privacy activist, and it has already received some press coverage at Wired and NY Times.

From the letter’s executive summary:

This six page letter to Google’s CEO, Eric Schmidt, is signed by 38 researchers and academics in the fields of computer science, information security and privacy law. Together, they ask Google to honor the important privacy promises it has made to its customers and protect users’ communications from theft and snooping by enabling industry standard transport encryption technology (HTTPS) for Google Mail, Docs, and Calendar.

Google already uses industry-standard Hypertext Transfer Protocol Secure (HTTPS) encryption  technology to protect customers’ login information. However, encryption is not enabled by default to protect other information transmitted by users of Google Mail, Docs or Calendar. As a result, Google customers who compose email, documents, spreadsheets, presentations and calendar plans from a public connection (such as open wireless networks in coffee shops, libraries, and schools) face a very real risk of data theft and snooping, even by unsophisticated attackers. Tools to steal information are widely available on the Internet.

Google supports HTTPS encryption for the entire Gmail, Docs or Calendar session.  However, this is disabled by default, and the configuration option controlling this security mechanism is not easy to discover. Few users know the risks they face when logging into Google’s Web applications from an unsecured network, and Google’s existing efforts are little help.

Support for HTTPS is built into every Web browser and is widely used in the finance and health industries to protect consumers’ sensitive information. Google even uses HTTPS encryption, enabled by default, to protect customers using Google Voice, Health, AdSense and Adwords. Google should now extend this degree of protection to users of Gmail, Docs and Calendar.

Rather than forcing its customers to “opt-in” to adequate security, Google should make security and privacy the default.

HTTPS is commonly used by banks and e-commerce websites to protect sensitive user information in transit; it ensures that anyone “snooping” on the network cannot see your password or credit card information “in the clear”. While Google does use HTTPS when you log into your GMail or Docs account, thereby protecting your password, the remainder of your activities on those applications occur unencrypted, leaving everything you do and type susceptible to snooping. Google does allow users to turn on HTTPS for all of their activities, but the default setting is for less-secure processing, and Google does a poor job of promoting and explaining the benfits of using a secured connetion (sound familiar?).

The letter asks the following of Google:

[R]ather than forcing users to “opt-in” to adequate security, we strongly urge you to make security and privacy the default setting, and allow informed users to “opt-out” of the encryption if they feel it is an unnecessary burden.

If Google insists on not enabling these encryption-based protective measures by default, the company should at least make the consequences of this decision more prominent, so that users make a fully informed choice. Few users know the risks they face when logging into Google’s Web applications from an unsecured network, and Google’s existing efforts are little help. We suggest that, at minimum, Google do four things:

1. Place a link or checkbox on the login page for Gmail, Docs, and Calendar, that causes that session to be conducted entirely over HTTPS. This is similar to the “remember me on this computer” option already listed on various Google login pages. As an example, the text next to the option could read “protect all my data using encryption.”
2. Increase visibility of the “always use https” configuration option in Gmail. It should not be the last option on the Settings page, and users should not need to scroll down to see it.
3. Rename this option to increase clarity, and expand the accompanying description so that its importance and functionality is understandable to the average user.
4. Make the “always use https” option universal, so that it applies to all of Google’s products.  Gmail users who set this option should have their Docs and Calendar sessions equally protected.

Google has responded, acknowledging these concerns, but stating they “want to more completely understand the impact on people’s experience” before making HTTPS the default. Google seems most concerned about HTTPS’s impact on speed, asking rhetorically “Does it load fast enough? Is it responsive enough?”. These are loaded questions, since users typically don’t know what “enough” is, especially when they aren’t fully told the security risks of not using HTTPS.

We further address this issue of latency in the letter:

Once a user has loaded Google Mail or Docs in their browser, performance does not depend upon a low latency Internet connection. The user’s interactions with Google’s applications typically do not depend on an immediate response from Google’s servers. This separation of the application from the Internet connection enables Google to offer ‘offline’ versions of its most popular Web applications.

Even when low latency is important, financial firms such as Bank of America and American Express have demonstrated how to provide users with a pleasant, low-latency browsing experience, while still implementing strong encryption by default. Likewise, Adobe’s cloud-based Photoshop Express lets users interactively edit images via a Web application that is 100% encrypted by default.

Other Google applications demonstrate that security need not come at the cost of performance. Google’s Health service enables users to browse through and manage their private health information online. Google’s Voice service lets customers initiate VOIP phone calls, send text messages, and manage voicemail inboxes.  However, unlike with its Gmail, Docs, and Calendar products, Google only provides access to Health and Voice via HTTPS encrypted communications sessions, recognizing the highly sensitive health and call record information users entrust to Google.  Likewise, Google’s AdWords and AdSense products, which are the backbone of Google’s advertising business, can only be managed by customers using a secure HTTPS connection.

Google’s engineers have created a low-latency, enjoyable experience for users of Health, Voice, AdWords and AdSense – we are confident that these same skilled engineers can make any necessary tweaks to make Gmail, Docs, and Calendar work equally well in order to enable encryption by default.

I hope Google does the right thing and put the privacy and security of its customers first by making the changes described in this important letter.

Most recently, Germany has noted that Google’s (reluctant) blurring of faces and license plates is not enough, demanding that the original images themselves be permanently removed from their databases. Google argues that the original images are necessary to help the system “learn” how to automatically blur better in the future. This sounds like a valid need from an engineering perspective, but the key dilemma here is how to manage the balance between engineering and ethics. Just because the engineers want to have access to the original images doesn’t mean they should remain.

These are difficult decisions to make, but we’re here to help…

Meanwhile, I’ll take this opportunity to reiterate what I’ve previously suggested Google do to alleviate some of the privacy concerns with Street View:

1. Make use of their own facial recognition technology to automatically scan the Street View image database to identify and blur all faces, thereby protecting privacy and differentiating themselves from Microsoft’s offering. This should be done in all Street View products, not just the Canadian version.
2. Make reporting inappropriate images easier by placing a specific  “report this image” link on each image screen, not just a generic “help” link.
3. Think harder about privacy in public, and recognize that just because a random person can take another random person’s picture in public doesn’t mean there’s no difference in having a similar image available on Google.

In Code, Lessig argues that all of the rules, tendencies, affordances, and constraints of/in cyberspace are the result of human decisions, actions, and, ultimately, code. What we can and cannot do there is governed by the underlying code of all of the programs and protocols that make up the Internet, which can, alternatively or simultaneously, permit and restrict certain human actions:

In real space recognize how laws regulate – through constitutions, statues, and other legal codes. In cyberspace we must understand how code regulates – how the software and hardware that make cyberspace what it is regulate cyberspace as it is. (1999, p. 6)

For Lessig, “how a system is designed will affect the freedoms and control the system enables” (Lessig, 2001, p. 35); the very architecture of the Internet dictates its politics and ideology. He argues that it is the architecture of cyberspace that constitutes its culture, its community, and its freedom; and as the architecture is threatened or changed, so is the culture, community, and freedom it enables.

To see this in action, consider two recent examples: a change to the default reply settings on the Association of Internet Researchers discussion list, and a similar change implemented by the microblogging service Twitter.

:: Air-L ::

The Association of Internet Researchers hosts a quite active discussion list (air-l) on all things related to Internet studies. This past Sunday evening, the list manager sent out the following message:

Up until now on air-l, replies to messages posted to the list went, by default, to air-l. The default reply setting for air-l has been changed. As of now, replies to list posts will go privately to the message poster and not to air-l. If you would like people on the list to see your reply, you will need to manually insert the air-l address into the To: field of your reply.

Within minutes, this change was strongly criticized:

I think this is very detrimental to the community. This change fundamentally destroys the conversation construed as a group, and forces it to be between individuals, unless they consciously choose otherwise. …Air-l should be about collegiality and sharing, not about replying to individuals…. (source)

A lengthy discussion ensued, which included more detailed explanations of the motivation behind the change (centering on a concern over the inability to remove personal/confidential/harmful information that might be mistakenly sent to the entire list given the original default reply setting — a motivation that has been questioned by myself and others). Some also found the nature of the change quite surprising considering we’re an organization who studies Internet-based communication and culture; while others criticized the lack of community feedback, participation, or notice about the change.

The debate continues, but what it reveals is how the architecture of a system can impacts not only the mode of communication, but also the members’ sense of community, dialogue and sociability. As one commenter put it: “Even small technological changes can have immense social and political repercussions.”

As Lessig states, code is law, and as the reaction to the change in settings on the Air-L list reveals, many fear that this new code will regulate their experience in new — and detrimental — ways.

:: Twitter @Replies ::

At just about the same time as the Air-L debate, Twitter announced a similar change to how it would treat replies on its microblogging platform:

We’ve updated the Notices section of Settings to better reflect how folks are using Twitter regarding replies. Based on usage patterns and feedback, we’ve learned most people want to see when someone they follow replies to another person they follow—it’s a good way to stay in the loop. However, receiving one-sided fragments via replies sent to folks you don’t follow in your timeline is undesirable. Today’s update removes this undesirable and confusing option.

Translation: If I follow certain people, I can see their tweets, including those they send in reply to people I don’t follow. Twitter states their data shows this is “undesirable,” so, with this global change in place, I no longer see replies from friends to people I myself don’t follow.

Again, the reaction was swift, with the hash tag #fixreplies quickly emerging as a means of following the chatter.

And again, we are reminded of Lessig’s warning that the way a system is designed regulates our experiences within it. Consider this commenter’s reaction:

The new policy isn’t something you have to opt-in to. It’s not something you can opt-out of. It’s true for people who use 3rd party Twitter clients to read their Tweets. It’s more fundamentally closed than Facebook is; on that site I may not be able to view the profiles of strangers talking to my friends, but I can see that the conversations are happening and I can read the comments. This new Twitter policy breaks one of the fundamental rules of social activity streams: that I can discover new people by seeing who is conversing with the people I already know.

As with the Air-L issue, this is an ongoing debate with arguments from both sides (and Twitter appears to be making changes their original tweaks).

The point of both these cases is that architecture matters; especially architecture that is hidden, controlled by others, and set globally. The way a system is designed is constitutive of its culture, its community, and its freedoms; and as Lessig argues, when the architecture of a system is threatened or changed, so is the culture, community, and freedom it enables.

Building from its acquisition of DoubleClick, Google’s new ad system — which it refers to as “interest-based advertising” — will use cookies to track users across the multitude of sites that show Google’s display ads, allowing Google to create a profile of each user based on the kind of sites visited. Google will then target ads to a user based on that profile.

While Yahoo!, Micrsoft, and AOL have all been engaged in behavioral targeting for some time, Google’s entrance into this controversial domain is quite significant. And, similar to its approach to locational privacy with Latitude, Google has taken some very positive steps to design privacy into this new advertising framework. For example:

• If a user clicks on the “Ads By Google” link which accompanies its banner ads, they will be taken to this page where the behavioral targeting technique is explained, with a link for even more detail.
• On this page, users can see exactly which behavioral categories they have been assigned based on their browsing activity. Users can also add/delete categories to/from their profile.
• A user’s profile is only based on her browsing activity as tracked by a specific cookie. It is not populated by, or linked to, her Google Account or Gmail.
• Google won’t create “sensitive interest categories” like race, religion, sexual orientation, health, or sensitive financial categories, without a user’s opt-in consent.
• Users can also opt-out of the targeting altogether by clicking the “opt-out” button on this page, disabling Google’s tracking cookie with an “id=OPT_OUT” setting.
• Recognizing that users might routinely clear out their browser’s cookies, and as a result removing this “id=OPT_OUT” setting, Google warns users of this possibility, and has taken the steps to build an open-source browser plug-in to allow users to permanently opt-out of the cookie tracking system.
• To help explain all of this, Google has added a YouTube video on its Privacy Channel.

These are all significant — and mostly unprecedented — steps to give users access and control over the data collected about their online activities; just what I have been urging Google to do for quite a while now.

That said, Google can go further to better protect user privacy, and increase transparency, access, and control with regard to the collection of personal information. For example:

• Make participation in behavioral targeting opt-in, not opt out. Currently, every person who comes into contact with a website participating in Google’s targeting program receives the cookie and is integrated into Google’s larger tracking infrastructure. A user must happen to click on the “Ads by Google” link at the bottom of an advertisement to discover she can opt-out.
• Change “Ads by Google” to “Ad Privacy Preferences”. If the goal is transparency, access, and choice,  Google should make the link to the ad preferences page more descriptive than “Ads by Google”. In fact, since the entire advertisement is “clickable”, a user has little reason to think clicking on “Ads by Google” would take them anywhere different than the ad itself. If anything, a user would presume that link points to a general page about Google’s advertising solutions. There’s nothing that would trigger a user to think they could opt-out or view their profile by clicking this link.
• Provide more refined controls. While it is impressive to let users see and edit exactly what interest profiles they have been assigned to, Google should take it a step further and provide even finer levels of access to view precisely what websites have been included in my profile data. Not everyone will need to be burdened with such detail — perhaps only those who I call “privacy power users” — but providing the option would be an important enhancement to the privacy controls already designed.
• Expand these tools to all Google properties. I’m impressed by the level of transparency and control Google is providing users in relation to behavioral tracking and targeting. Now, extend these same privacy-enhancing features to other Google products. Let me see what data has been collected about my search history (in Google’s logs, not just what is viewable in the “Web History” interface. Similarly, let me see what clickstream data Google collects from my activities on their properties, if they’ve been logging what books I view in Google Book Search, and so on. And just like the interests in my behavioral profile, provde me the ability to edit, add or remove data from these logs.
• Create a global Google cookie opt-out plugin. Google should enhance the advertising cookie opt-out plug-in to include any and all Google cookies. Rather than relying on third-parties to design and maintain cookie blocking, Google should recognize that releasing such a tool would be a big step in building user trust (and, since I’m guessing that only a small percentage of people would bother to user such a plug-in, Google probably wouldn’t lose much data anyway).
• Commit to never use search history for behavioral targeting. Finally, I call on Google to commit to never use an individual’s search history for behavioral targeting. Search queries necessarily contain personal, sensitive, and private information. It should never be aggregated in an attempt to profile a user and sell advertising.

[Disclosure: I recently attended a Public Interest Consultation and Roundtable discussion at Google, which included a preview of this advertising product and related privacy controls. Google paid for my travel & accommodations.]

UPDATE: Read Seth Finkelstein‘s column criticizing Google’s strategy, which includes this apt reflection:

If Google can convince people its surveillance is merely a warm and fuzzy way of helping you shop, while ISPs’ surveillance is akin to warrantless wiretapping, that gives Google an enormous advantage in collecting information to sell to advertisers.

UPDATE: Chris Soghoian has expanded Google’s opt-out plugin to include nearly all behavioral advertising networks. Download it here.