Information, Privacy, and Security

This page has been archived on the Web

Information identified as archived is provided for reference, research or recordkeeping purposes. It is not subject to the Government of Canada Web Standards and has not been altered or updated since it was archived. Please contact us to request a format other than those available.

IT Net Luncheon Speaker Series

April 23, 2002
Ottawa, Ontario

George Radwanski
Privacy Commissioner of Canada

(Check Against Delivery)


Good afternoon. It's a pleasure to be here today, with so many people in the privacy business.

If you're wondering why I said that, it's because all of you in this room are right in the thick of one of the most important privacy issues we face as a society.

You're the decision-makers when it comes to government information systems. Those systems, whatever else they do, inevitably entail the collection, use, and disclosure of personal information-and that puts you smack in the middle of privacy.

Personal information is central to privacy-in fact, I define privacy as the right to control access to one's person and to information about oneself.

The old saw that "information is power" is nowhere truer than in the context of personal information. It's not only that those who know our deepest secrets can control us. It's that our ability to control the collection, use, and disclosure of information about us is the key to our freedom.

It's what lets us live as free individuals-free to read what we please, think as we please, associate with whom we please. Our right to privacy means that we don't have to go through life with someone watching over our shoulders-watching our every move, every purchase, and every human interaction; analyzing patterns in our behaviour; interpreting, and maybe misinterpreting, our actions; judging, and maybe misjudging, our intentions.

The right of privacy underlies our society's most valued freedoms. Freedom of thought, association, conscience, and speech, to name just a few, are all based on our having a private sphere of thought and action that is our business and no one else's.

You're involved in the privacy business at a critical moment in our technological and social history. Both government and private-sector organizations hold more information about us than ever before, and their appetite increases every day. There's a steady growth in the speed and sophistication with which our personal information can be analyzed, combined, combed, matched, and mined. That's why I believe that privacy is the defining issue of this decade. And that's why I'm here talking to you, because you bear a huge responsibility: to build information systems that protect privacy.

Let me be clear: I believe that can be done. I'm no Luddite. I'm a supporter of electronic delivery of services, and in particular of the federal government's GOL initiative. I'm enthusiastic about the prospect of improvements in the way programs are delivered, and a wider range of choice as to how people gain access to government services. Who wouldn't welcome an initiative that will make government more efficient and accessible? And if it contributes to making Canada a world leader in technology, and to the development of a thriving private sector, so much the better.

But we need to stay cautious. For all of these systems' promised advantages and benefits, we've got to make sure that the price we pay is not our fundamental human right of privacy. The IT systems that you build have to protect privacy.

Some of you may already be doing that. But I should tell you that for a long time the IT people involved with Treasury Board's Government On-Line project thought that they were protecting privacy, and said so. But in fact they were only protecting security and confidentiality. A search for the term "privacy" on the Government On-Line website would get you nothing but information about security safeguards, public key infrastructure, and protection from unauthorized use and disclosure. Those things are important. They're necessary. But they're not sufficient. They don't amount to privacy protection.

So for the sake of clarity, let me say once again what privacy is, and how it's distinguished from security and confidentiality.

Privacy, in the context of information systems, is our fundamental right as individuals to control the collection, use, and disclosure of information about ourselves. The right to privacy means that individuals get to decide what and how much information to give up, and to whom it is given, and for what uses.

Confidentiality is different. It's the obligation of a custodian to protect the personal information that it's been entrusted with. A promise of confidentiality imposes a duty of care to maintain the secrecy of the information, and not misuse or wrongfully disclose it.

Security is something else again. It's the process of assessing the threats and risks posed to information, and taking steps to protect the information against unauthorised or unintended access, use, intrusion, loss, or destruction.

Privacy drives the duty of confidentiality and the responsibility for security. You have to respect and address the right of privacy first, before you deal with confidentiality and security.

If you don't respect privacy-if you collect, use, or disclose information about someone without their consent-it doesn't matter that you ensure confidentiality and security. If you encrypt the information and protect it with the best firewalls, you may well have assured its security. But that doesn't change the essential fact that you've violated the individual's privacy.

Until quite recently, this was not as well-understood in government IT circles as it should have been. It was evident that the people who were designing and implementing the IT systems in the GOL initiative had been trained to think about security and confidentiality, but not about privacy. I know that things have changed, but I have to tell you: when I go to the Government On-Line website and search for "privacy," I still get nothing but information about security safeguards, public key infrastructure, and protection from unauthorized use and disclosure. It's high time Treasury Board updated the GOL website to reflect its enhanced understanding of privacy issues.

For architects of information systems, and for their clients, there's an important element of self-interest in respecting privacy. Privacy is not just an abstract right. It's true that sometimes people take their privacy for granted, the way they might take their health for granted. But as with their health, it doesn't take much to make them aware of their privacy, and protective of it. We've learned from the development of electronic commerce that people are reluctant to engage in electronic transactions if they think their privacy is at risk.

EKOS Research Associates recently found that only 32 per cent of daily users of the Internet-people who describe themselves as very comfortable with life online-are willing to register personal information on Internet sites they visit. Among casual users that figure drops to 11 per cent.

Those low comfort levels with privacy on the Internet translate into real consequences for electronic commerce. EKOS found that only 22 per cent of Canadians would be willing to give their credit card number online. Among confirmed Internet users, that figure rises to only 31 per cent. Even among daily users of the Internet, it's only slightly more than half.

This is going to be the picture for electronic delivery of government services, if you don't get it right on privacy. These systems won't work without public buy-in. And that won't happen, at least not in any significant numbers, unless people are assured that their privacy is protected.

Many of you will have noted the Auditor-General's statement, in her recent report to Parliament, that Canadians are reluctant to go on-line to do business with the government, without assurance that the systems are secure and that their personal information will be protected.

She's right, of course. They also want assurance that their information will be fairly collected, and that it won't be misused or shared inappropriately. In other words, it's not only that they want their information protected: they want their privacy respected.

Let me describe three of the most important privacy concerns with Government On-Line.

First, the merging of databases, as walls come down between agencies and programs, within government and across levels of government.

We all like cooperation and coordination between agencies that have a common goal. We all oppose duplication and waste. So the idea of breaking down the walls can be pretty appealing.

But some walls between collections of personal information are crucial.

Information about individuals and their interactions with government is collected for specific uses. The separate databases it's held in-the "silos"-reflect the specific purposes justifying the collection and retention of the information. The information is compartmentalized. Yes, there's some duplication. That's a trade-off for a couple of benefits.

Without those silo walls someone with a need to know only one piece of information can have access to lots more than he or she needs or has any right to. If I surrender information in order to get a CPP disability pension, the only person who should have access to that information is someone with a demonstrable need for it, for the purposes I agreed to when I surrendered it. And that person has no business knowing anything else about me. I can only count on that being the case when there are walls between the different banks of information.

That's one reason for silo walls. Another is that, without them, information can be combined to reveal new information. That can lead to profiling of citizens-a distinguishing feature of surveillance societies. Dossiers on individuals, tracking their activities and their interaction with government, have no place in an open, democratic society. We have a well-established and long-cherished right to go about our lawful, peaceable business anonymously and unmonitored. We can't allow it to slip away from us in the pursuit of efficiency.

The second concern about GOL is the involvement of the private sector in delivering services or benefits electronically.

There's nothing intrinsically wrong with this. It may well lead to more efficient delivery of services, and probably will contribute to the economic health of the private sector as well. With the right privacy protections built in, it may not be a problem. But without them, it will be.

Again, remember that walls between banks of personal information help to protect privacy. Linking networks could eventually lead to one inter-operable system combining the personal information holdings of both the public and the private sector.

And privacy protection in the private sector, even with the Personal Information Protection and Electronic Documents Act in force, is patchy. Unchecked and unguided, the pursuit of the objectives of efficient government and private sector development could very well lead to the emergence of uncontrolled databases on Canadians. That's something that I will strongly oppose. Personal information that's been provided for the purposes of a government program must not become the source of telemarketing or mailing lists, as has happened in the US with information from driver's licences.

The third concern is the need for an authentication, identification, and access device-an "e-identity."

Authentication is a big issue in a networked economy. Electronic commerce tends to require that businesses know whom they're dealing with. Ingenious minds are always looking for alternatives so that we can do business anonymously, but the alternatives haven't really caught on, and I think it's likely that we're stuck with authentication. Most people seem to accept it in electronic commerce. But its use by the state is a different issue, and we need to be aware of the problems, right at the outset.

We need to ask two questions about authentication of clients of government services. First, to what extent is there actually a need to identify the client?

If people have a ready means of authenticating their identity in an electronic interface with government, it may be tempting to require authentication when it's not really needed.

Obviously, if you're seeking a government benefit, you have to identify yourself. The government has to be able to verify that you're who you say you are, that you're entitled to the benefit, and that you haven't already received it.

But there's no need to ask people to authenticate their identity in a transaction that can just as reasonably be done anonymously. A simple request for information, for example, requires no authentication of the client's identity.

What's needed here is a conscious choice to require authentication only when necessary. The default setting should be anonymity.

Things like cookies, digital certificates, and public key encryption all contribute to client identification and detract from anonymity. They should only be used where anonymity will not work.

The other question we need to ask is this: How deep do we need to drill to authenticate identity, and what evidence will satisfy us?

If you are interfacing on-line with the Department of Human Resources Development for Canada Pension Plan benefits, the department needs to verify certain things about you. If you are inquiring on-line about your passport, the Department of Foreign Affairs needs to verify certain things about you.

The kinds of information those departments need to know about you are not the same, although obviously there's some overlap, like your name and your date of birth. Whatever means of authentication is chosen, the architecture of the system has to reflect that.

I'm sceptical about one-size-fits-all authentication devices, like a smart card that incorporates all the information about our interactions with government, and then makes it all available, indiscriminately, every time we interact with a government department. Authentication for one purpose must not elicit information from you that's only required for another purpose.

A single card that holds all the information about our interactions with government raises the problem of combined databases to a new level. And, unless we take steps to restrict it, the forces of convenience and efficiency will drive it towards becoming a national identity card.

In Canada we don't have to identify ourselves to anyone-agents of the state or anyone else-except for specific and limited purposes. This is not a country where you can be stopped by a police officer and casually required to produce your papers. In Canada you have the right to go about your business anonymously and peaceably, without having to justify yourself, without being subject to surveillance.

It would not be acceptable to lose that.

So those are my concerns about Government On-Line. They should be the concerns of the architects of GOL as well, because GOL will fail, at the cost of enormous investments, if those concerns are not addressed.

As I've mentioned, I support the electronic delivery of services and I want to help make GOL a success. But I can't do this unless I'm kept up-to-date. I've had some meetings with the Chief Information Officer, but these have been few and far between. Her repeated undertakings to keep me closely in the loop simply have not been kept. This, of course, is disturbing.

The points I've made about privacy in Government On-Line apply to government information systems generally. The architecture has to be informed by privacy principles-so that, for instance, information collected for one purpose isn't available for use for unrelated ones, and is kept only as long as it's needed for the purpose the individual consented to.

That's why, since my appointment as Privacy Commissioner, I've continually urged information system designers to build privacy in from the start. And the key to that is a Privacy Impact Assessment.

This is an analysis of the likely impacts on privacy of a system that's either being proposed or being redesigned. It involves looking at all the personal information practices that go into the system, such as what kinds of information are collected, how consent is obtained, how and for how long the information is kept, how it's used, and who it's disclosed to. It involves looking at things like the purposes and statutory authorities for collection, use, and disclosure, what kinds of linkages there will be between this and other information, and how individuals will be able to exercise their right of access to their information. And it looks at privacy legislation and principles, and assesses how the project or system complies with them overall.

Let's look a little more closely at the kinds of questions you'd ask.

You would want to ask whether your system or project is going to lead to data matching. Will it be possible to combine unrelated personal information to create new information about individuals?

Will the system, especially its demands for identification and authentication, lead to profiling, transaction monitoring, and other forms of surveillance?

Will the program or system entail the physical observation of individuals?

Will it facilitate electronic misuse of publicly available personal information?

Those are questions about possible violations of privacy. You also need to ask questions about the resources to deal with them-such as whether there's an accountability structure in place to deal with privacy issues.

In effect, this is a feasibility study from a privacy perspective. It's an excellent way to forecast impacts on privacy, and determine what's required to overcome the negative impacts.

A Privacy Impact Assessment is sometimes referred to as a risk-management tool. That's because a lot of the privacy impacts that are identified aren't certain to happen. There's a risk rather than a certainty that data matching, for example, will lead to new information, or that authentication will lead to profiling.

But it's also a risk-management tool because getting it wrong on privacy is a risky proposition. As I said earlier, design is more cost-effective than retrofit. And you don't want your latest project to result in privacy complaints from individuals.

Doing a Privacy Impact Assessment also enables you to sensitize the various elements and personalities in your organization to privacy issues. That helps you create an organizational culture of respect for privacy, where everyone supports and understands privacy as part of the corporate goal.

And a Privacy Impact Assessment is a very useful tool for monitoring the system as it progresses. You've identified privacy risks, you can see whether your means of addressing them are working, and you're alert and attuned for new, unforeseen ones coming up.

Down the line, when you're reviewing the compliance of your systems with privacy legislation and principles, the Privacy Impact Assessment is an excellent basis for ensuring that those involved in the review-system operators, management, and representatives of the oversight body-understand each other and the system.

Ever since I first spoke on the subject in July of 2001, I've been urging the federal government to use Privacy Impact Assessments, and the idea seems to be catching on. We've been working with the Treasury Board Secretariat to develop a policy on their use. In fact, I'm hopeful that you will hear something interesting on this subject tomorrow.

If privacy is considered at the outset, it should reduce the number of complaints brought before me. Of course, there is a place, and a need, for the complaint process. Canadians must have the right to challenge organizations to respect their privacy. But it's not in anyone's interests to have me oppose something when it's gone too far and millions of dollars have already been spent. And as always, prevention is better than cure. It's better to protect privacy up front than to try to undo the damage after a breach of privacy. Sure, someone can complain to me when their privacy has been violated, and I can help find a remedy, and take steps to make sure it doesn't happen again. But let's face it: they can't get back their lost privacy.

So this kind of collaborative approach makes a great deal of sense for an office like mine. My job is to apply both principles and flexibility to privacy questions. Helping organizations with their Privacy Impact Assessments is a very good way to do that.

I might point out that it's not just government institutions that should do Privacy Impact Assessments. They're just as useful to the private sector.

More and more organizations are coming under the scope of privacy legislation, and of course even those that aren't required to under law are usually very concerned about protecting privacy.

They should do Privacy Impact Assessments, because being concerned about protecting privacy is usually not enough. Good intentions, on their own, don't protect privacy.

Privacy, in fact, is often most threatened by well-intentioned people. They don't see themselves as trampling privacy. They just see themselves as trading it off for some greater good. Sometimes that greater good is customer service. Sometimes it's public security. And often it's something called efficiency.

I say "something called efficiency" because it's too often forgotten what efficiency really is.

It's not doing more with less, or being lean and mean, or getting the biggest bang for the buck, or any of those other clichés.

Efficiency refers to the relation between means and ends, to the choice of the best means to achieve a particular goal.

How we define those goals is the crucial question. And for anyone building a program or an information system that requires the collection, use, or disclosure of personal information, protecting privacy has to be part of those goals. Privacy is not an impediment to efficiency. It's not something that you can sacrifice to be more efficient. It is something that you have to protect. That's a fundamental element of your goal. It's up to you to find efficient means to achieve that goal.

I'm confident that this can be done. The key, though, is to recognize how important privacy is to our society, and how concerned Canadians are about it, and build your system accordingly.

So, find a way to work together, involving system architects, program managers, and representatives of my Office. A collaborative approach and a commitment to privacy is your best guarantee of the success of your information systems.

Date modified: