• Print

Privacy and open government: conversations with EPIC and others about OpenID

A few days ago I proposed a way to

offer more privacy to people visiting government web sites
.
This blog builds on that proposal, which was largely technical, by
examining the policy and organizational issues that swirl around it.

My ideas are informed by a discussion I had with Lillie
Coney, Associate Director of the
Electronic Privacy Information Center.
The blog is also inspired by two comments on the earlier blog and
brief email I exchanged with one commenter, which intertwine with
Coney’s in intriguing ways.

As I said in the first blog, my proposal focused on a very narrow
question driven by the Obama Administration’s interest in revising a
memorandum from 2000 concerning the use of cookies in web
browsers. The proposal suggested a way to better approach anonymity,
but didn’t look at the related social and political issues:

  • The kinds of privacy and the degree of privacy people want

  • When it’s appropriate to make visitors identify themselves, or at
    least to provide some persistent identity

  • Whom people trust to maintain identity information

This blog offers a number of points about those issues. The sections
are:


Can the government be your friend?

The kinds of government/public collaboration pursued by CIO Vivek
Kundra and others in the Obama administration sees people doing much
more than submitting ideas. The administration wants information
sharing and an exchange of ideas that allow both sides to reveal
vulnerabilities.

But as one commenter pointed out on my previous blog, the government
has a lot of power that should make us hesitate before sharing too
much. Coney, whose work at EPIC includes a focus on domestic
surveillance, pointed to an incident where

the Las Vegas Review-Journal was served a subpoena

requiring it identify readers who had posted online comments about an
article involving a case with the Internal Revenue Service. (The
newspaper is fighting the subpoena.) Some agencies have enough power
to be scary. And some agency heads may take heavy-handed measures
without even being malicious or vindictive–just out of a concern for
security.

So you may be living it up like Obama, Gates, and Crowley on one
agency’s web site, forming great relationships and having an extremely
productive discussion, only to discover that your comments come back
to bite you when you tussle with an entirely different agency. And of
course, the data you give these sites lasts forever.

Such promiscuous information sharing is supposedly outlawed by the
1974 Federal Privacy Act. This oft-cited law, along with the 1966
Freedom of Information Act, remain centerpieces in the armory of those
protecting personal privacy in the U.S. However, the Federal Privacy
Act creates many exceptions for agencies that want to opt out from its
rules, and fails to cover private contractors. Coney says, “EPIC’s
goal is to develop fair information practices that are enforceable and
transparent to protect users of government information.”

Having studied the privacy policies requested by different agencies,
Coney finds them in two camps. Agencies whose mission is to reach and
out and help people, such as the Department of Health and Human
Services, favored as much privacy as possible–the same goal Kundra
has expressed many times. On the other hand, law enforcement and other
agencies concerned with protecting the public would like to log all
accesses and try to attach personal information to all visits–even
access to public information.

That last policy puzzles me. If the government offers information
freely, Carl Malamud or I or anybody can grab it and put it on another
web site. There is no way to track who accesses free and open
information. Tracking access in the hope of preventing criminal use is
not only obnoxious but futile.

In short, forming a partnership with government takes a bit more
consideration than friending someone on Facebook. The new age of
government participation we’re hearing about, then, rests on some
assurances to the public. Personal information should not be collected
unless absolutely necessary, and should not be used for purposes
unrelated to the reason for capturing it, especially by other
government entities.

We’re all excited about the expanding collaboration between government
and citizens, but the historic change intensifies the need to take a
fresh look at laws and policies on a regular basis, just as the OMB
has done in requesting comments on their cookie policy.


Anonymity, pseudonymity, and participation

People phone anonymous tips in to the police all the time. To allow
the same kind of anonymity
online would be just an invitation to spam. In fact, anyone with
something to hide would make sure to flood the system with
irresponsible accusations just to drown out the people who have
legitimate crimes to report. (The
FBI tip site
asks you to identify yourself.)

The proposal in my previous blog delivers pretty good pseudonymity,
allowing someone to submit repeated comments with the assurance that
they all come from the same person, but without surrendering personal
information.

One commenter on my blog asked whether we can really trust the
government to protect pseudonymity. Well, of course they can always
trace you if they want to. Even non-government actors can do that, as
we’ve just seen from the recording industry’s testimony at Joel
Tenenbaum’s trial. Privacy is a cat-and-mouse game in which both sides
have escalating levels of attacks and parries.

Tracking you through contact information

Attack: My proposal let people leave a contact, such as an
email address or Twitter account, where the government could report
information about their account. Although the government should
promise not to misuse the contact, it could be used to identify a
visitor.

Parry: Leaving a contact is optional, and you can manage your
account without leaving one. You can also use a free email address
from popular providers.

Tracking by IP address and time

Attack: The government can require your ISP to provide your
identity based on the time you were logged in and the dynamic IP
address they assigned you.

Parry: Find an open wireless access point or use an onion
routing network.


Who should run an OpenID server?

From this point on, I’ll assume that OpenID will be used by federal
agencies in some configuration, because that’s the only technology
with a widespread implementation that can provide the protections
discussed in this blog.

One of the central policy questions we have to deal with, then, is
whom we should trust with our OpenID account. My proposal called on
the federal government to run an OpenID server for all its agencies,
mostly because I want the government to kick the habit of using
commercial services for such essential information-age functions. (See
my earlier blogs,

Five projects for Open Source for America

and

themes from the Personal Democracy Forum conference
.)

Coney and I discussed several options for ensuring reliable servers.
There’s no reason not to allow multiple options. Running an OpenID
server is pretty easy. If EPIC had a hankering to serve up privacy
directly, this is its chance. The problem is whether visitors can
trust any particular server 1) to stay up, 2) not to go out of
business, 3) not to leak information, 4) not to abuse the information
for private gain, and 5) not to cave in to government pressure and
release information outside of the scope of the law.

Here are a few options.

The federal government runs its own dedicated server

Pros: The government can probably do the best job of
guaranteeing that the server stays up and is not broken into. The
government is not depending on outside entities for this essential
function.

Cons: A central OpenID server offers a compelling target, and
a stream of recent news reports shows that government agencies suffer
from the same security lapses as private companies. Furthermore, many
people don’t trust the government to protect their privacy and feel
more secure with a private server.

The federal government regulates the organizations that provide servers

Pros: Personal data is stored in a variety of private
servers, complicating attacks, while the government ensures they are
run professionally.

Cons: Defining service-level agreements and quality control
is difficult, and legislating or regulating it is even more difficult.

The organizations that provide servers define a code of conduct and
monitor compliance

Pros: Self-regulation is much lighter-weight than laws and
regulations, and the experts who know the technical and business
issues the best will be in charge of ensuring quality.

Cons: Self-regulating privacy agreements–we’ve seen
that before! The failures of TRUSTe and P3P leave us twice-scarred and
reluctant to try again. (See my article

Promises, Promises, Promises
.)
Still, TRUSTe and P3P provided no protection because the organizations
creating privacy policies were disingenuous and lacked an interest in
truly protecting privacy. A sincere self-regulatory effort by new
organizations committed to privacy might succeed.

The federal government sets up a dedicated agency that is monitored by
a private firm or non-profit

Pros: This was suggested by Coney. It combines the
reliability of the government with the disinterested independence of
an outside observer.

Cons: Malicious actors in the government agency may succeed
in hiding bad behavior from the monitors, whose inspections would quickly settle
into an uninspired routine. Moreover, the requirements that the monitor
has to enforce are just as complex as in the previous solutions.

Free market: let each visitor choose a server and take his chances

Pros: This leads to the most diversity, which is a strength
in the area of security. And if a server goes down, how much is lost?
The visitor can open a new account elsewhere and rebuild the lost
personal information.

Cons: No one can evaluate the competence and reliability of
another organization’s server, and weaknesses don’t become apparent
until disaster strikes.

As usual, the policy, organizational, and social issues in deploying a
technology are thornier than the technology itself. I still think the
architecture I offered in my proposal to OMB provides a good basis for
building any of the systems considered in this blog.


Thought experiment: could federal agencies offer anonymous authentication for whistle-blowers?

I’ll end this blog by exploring an identity system that would allow
an agency to authenticate a pseudonymous whistle-blower by verifying
“Yes, this is a current employee” or “Yes, this is a former employee”
without giving further information about that individual.

I believe that any such authentication system would have to be based
on a two-tier approach such as I laid out in my OpenID proposal. The
system I lay out in this section is too complex, organizationally and
technically, for the government to implement at this point, but it
shows the tools available to privacy advocates.

  1. Each government agency participating in the authentication program
    sets up a server to digitally sign IDs. Another server hosts accounts
    for every employee.

  2. Each employee is encouraged to create an account on the OpenID server
    and to keep it secret.

  3. When logged in at his or her agency account, the employee submits his
    or her account name with the agency’s digital signature. This produces
    an unforgeable string that combines verification of the employee with
    verification of the agency.

  4. At any time, the employee can post information to any web site that
    accepts an OpenID login, using the employee’s secret OpenID account.
    The employee includes the string obtained in the previous step. By
    checking the signature, anyone can verify that the employee had an
    account at one time on the agency server. Because the text revealed
    underneath the signature is the account name, it proves that the
    person who obtained the signature is the same person posting
    information currently.

In order to masquerade as an agency employee, someone would have to
obtain both the employee’s signed string and access to the
employee’s secret account on the OpenID server. This might be possible
if the employee is lax in protecting the information (for instance, by
putting it unencrypted on a cell phone and losing it). Other problems
with this system include:

  • There is no way to revoke the signature, unless the agency revokes all
    signatures at once. Thus, there is no way to tell whether the employee
    is still employed. This may be acceptable.

  • This system would allow any employee to leak any agency information
    without personal repercussions. That’s probably not a policy we want
    to foster.

Technology confers power, and so does anonymity. Technical, legal, and
policy experts are all needed to study the implications of the systems
we have for participation, and the systems that are proposed to
replace them.

tags: , , , , , , , , ,
  • http://www.reachthepublic.com Scott Burns

    Thank you for the thoughtful post on this important issue.

    I’m the co-founder of a company (GovDelivery) that helps government agencies gather email address and other contact information from the public in order to provide outbound alerting services. We find that people are very trusting of the government and signup in large numbers as long as they understand what they are going to receive (given lots of choice) and aren’t asked for unnecessary information.

    The old thinking on ID systems in government was to create a master/massive “single sign-on” effort. I’m glad that OpenID exists and is now such an obvious and more practical solution to this age-old problem.

    If the government thoughtfully plans and sets things in motion against this open standard, OpenID could be a real home run in the public sector. I know our company is ready to embrace it and that many of our clients and the citizens they serve would see it as a nice benefit.

    Because we work with 13 of 15 federal agencies and many state and local governments, we could help put OpenID into broad use very quickly if the federal government put its support behind one or more of the approaches you outline.

    I’m not an OpenID expert, but whatever approach is chosen, my only major concern is that users can easily bypass any onerous requirements for creating a detailed profile to make use of OpenID. If the amount of information required gets to great, I worry that what we call “impulse buys” (someone sees a health tip on the CDC website and quickly signs up for updates) could become so cumbersome that signup rates would plummet.

    Your approach of thinking through the use cases and the pros and cons is a good one for ensuring that we don’t take one step forward and two steps back.

    -Scott Burns
    http://www.twitter.com/smburns
    http://www.govdelivery.com

  • http://blog.seorider.com/ SEO

    This is fantastic. Here’s to open government and the open web! I believe OpenID will continue to be the most convenient and trustworthy open identity standard on the Web. Open standards create a better Internet for everyone, and the U.S. government’s adoption of OpenID is a huge endorsement of OpenID and a big step forward for open standards. From SEO Rider