For the next few days I will be participating in a project aiming to apply the VID perspective to future Internet architecture (FIA) design eforts: the Values-In-Design Council.

The National Science Foundation has recently funded multiple projects to envision and  pursue new ways to build a “more trustworthy and robust Internet.” As described by the NSF:

The four basic research and system design projects funded under FIA explore different dimensions of the network architecture design space and emphasize different visions of future networks. NSF anticipates that the teams will explore new directions and a diverse range of research thrusts within their research agenda but also work together to enhance and possibly integrate architectural thinking, concepts and components, paving the way to a comprehensive trustworthy network architecture of the future.

The four FIA projects are described in more detail here.

Along with these technical projects, the NSF has also funded the creation of the Values-in-Design Council, a multi-disciplinary team of experts in the social analysis of digital information technologies, led by Helen Nissenbaum, who are tasked to work alongside the recipients of the FIA technical grants. As described by Nissenbaum:

Council members will serve as analysts and consultants to the FIA projects, helping to identify junctures in the design process in which values-critical technical decisions arise; locating design parameters and variations that differentially call into play relevant values; for and with respective projects, developing rich conceptual understandings of relevant values; for and with project investigators, operationalizing values to enable transition from values conceptions into design features; with FIA investigators, examining the interplay of values embodied in design with respective values embodied in law and policy; and where possible, verifying values in design through prototyping, user testing and other empirical analyses.

The full list of VID Council members is here.

At this week’s meeting, hosted by Colorado State University’s Computer Science Department, each of the four project teams will provide an update of their work, and then discussion will focus on this set of questions:

Who are the service providers in your architecture, and what is the resulting provider ecosystem? (Some of the FIA architecture seem to presume a provider ecosystem similar to today: a connected set of packet forwarders. Some presume other services related to carriage, such as storage providers. )

• What is the incentive of each of these actors to enter into their line of business? Where would your architecture require payments among actors to sustain viability?

Options for control: which actors can influence the behavior of a transfer?

• Does your architecture provide user control over aspects of service selection: routes, service qualities, or providers of support service (e.g. like DNS in today’s Internet)?
• To what extent does your architecture support or resist the goals of those who wish to control access to classes of information (e.g. governments, rights-holders). How does this position influence the balance of power in your network, and its viability? Which actors have the ability (or perhaps the easy ability) to block communication among willing end-points?
• IP addresses accidentally turned out to be scarce resources, for no good reason. What features of your architecture might turn out to be “scarce resources” or resources over which some potentially powerful actor could exercise control?
• Do you have hierarchies with single points of control at the root? Is there information you share with partners that has to be signed by a trusted third party?
• Are there policies that you have explicitly embedded in your design?

What is the range of services that the system provides to the higher layers?

• Compared to today’s Internet, would you expect the same sort of commercial entities at the higher layers?
• For example, (especially in the context of those architectures that emphasize information retrieval), would you imagine that there would be CDNs operating on top of your architecture?
• Does your architecture provide an API that defines the service interface of your system?

Interfaces among providers

• What types of information is expected to be exchanged between providers?  This goes beyond packet forwarding to include:
  • Routing information
  • Naming information (e.g. DNS zone transfers)
  • An interconnection agreement between providers in today’s Internet may have Service Level Requirements, or specify aspects of routing policies (cold potato, hot potato).  What would you expect to find in inter-provider agreements in your architecture?
  • To what extent do services provided to higher levels (see above) require negotiation or cooperation among the various actors that make up the overall network?
  • What mechanisms does your architecture provide for negotiation among service providers?
  • What range of functions are supported by the protocols and mechanisms that hook them together?
  • Operators are sometimes worried about all getting together to solve operational issues. It is hard to do and looks like anti-trust. What are the “top five” aspects of your architecture that require operational coordination?

Market forces and regulation

• To what extent does your proposal facilitate or limit the use of competition as a discipline on the market?
• If regulation were proposed to require some sort of non-discriminatory access or “network neutrality”, what might that mean in your design? Where might forms of discriminatory service emerge?

Evolvability

• How does your architecture allow innovation and the migration to new mechanisms?
• Which sorts of evolution seem to require global coordination, like the migration to IPv6 today?

Trust, isolation and availability

• What sorts of trust assumptions does your design make about the various actors that make up the ecosystem?
• Does your architecture provide means for instrumentation or data-gathering? What sorts of data? Internal structure of the network, usage, routes, outages, etc?
• To what extent does your architecture include tools to detect that actors are not functioning properly? Which actors have access to these tools?
• How do your options for control allow different actors to respond to actors that are not trustworthy or mis-functioning?
• Availability often implies “extra” or “diverse” resources. Does your architecture depend on resources that are otherwise under-utilized to achieve high availability. Is economics a barrier to a high-availability network? Both within a region and across regions, does your design allow the operator to trade off explicitly between cost and availability/resilience?

Implicit in these questions are various ethical concerns, including: autonomy, access, freedom from bias, control, and trust. I’m excited about the conversations that will unfold over the next couple of days, and will provide public reflections here as appropriate.

Zimmer, M. (2012). The ethical (re)design of the Google Books project. In iConference ’12 Proceedings of the 2012 iConference, 363-369. DOI: 10.1145/2132176.2132223

Today, the Google Books project is at a relative standstill — lawsuits against the project remain outstanding as the courts rejected a proposed settlement agreement. The failure of the original vision for the Google Books project to become fully realized presents us with a unique opportunity to ensure that whatever final form Google Books will take in the future, it is designed to support the values respected within the domain of information ethics. This paper will proposed an ethical re-design of the Google Books project, focusing on three core ethical values of primary interest to librarian and information professionals: privacy, intellectual freedom, and public access to information. Advocating for these values in the next iteration of the mass digitization service can help ensure that the informational norms of the library are embraced and upheld.

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.