Category: privacy

Google Street View Visiting Today

I took a day off today so I happened to be driving through my own neighbourhood around 10:00am.  As I turned the bend, I noticed a Chevy Cobalt with an odd derrick-like structure mounted on the roof:

Of course it was the Google Street View car!

The cameras on the car take pictures in all directions. Specialized software then ‘stitches’ the still images together to provide the Street View experience.  Here is a picture of the camera cluster:

There has been lots of discussion across the country about Street View and its potential for privacy invasion.  The Privacy Commissioner of Canada weighed in on this with their Fact Sheet titled Captured on Camera.  The basic point is that we do have privacy rights:

In Canada, there is private-sector privacy legislation that applies to these street-level imaging applications if they are collecting images of identifiable people. And, while the Privacy Commissioners of Canada, British Columbia, Alberta and Quebec recognize the popularity of these applications, they have also expressed reservations because the technology captures images not just of places, but of people as well.

I believe the federal commissioner lobbied Google and was able to extract two key concessions: Google would notify residents of the Street View car visit and the company would allow citizens to have images scrubbed if they were deemed privacy invasive.

I’ll dig up the facts related to this on a subsequent update to this post, but for now I have to go tidy up my front yard!

Mike

Update: Google has a video describing how to remove sensitive or inappropriate images from the service.

Update: Thanks to  Master Maq for a link to an Edmonton Journal article that, I suppose, meets the Privacy Commissioner’s requirement to notify us they are in town. Or does it?

How Federation Improves Privacy

Over the past few weeks I’ve been working through some use cases and designs for a solution that involves Federated identities.  It has got me thinking about the concept of authorization and how we often request more information than we need in order to authorize a transaction or session.

The essential use case is simple.  Let’s use the example of a municipal library system web site.  In this web site there are advanced sections that the library only wants to offer to residents of the city.  An example might be a search function that allows real-time queries against library titles and directs users to the location where these books can be found.

The library’s essential problem here is one of authorization.  It needs to know that the user is a citizen of the city, because it only wants the advanced sections of its system to be available to its own citizens.  What is interesting is that the library doesn’t really care about the individual citizen’s identity — it is merely concerned with establishing that the online user is authorized to be granted this access.

In a traditional Identity & Access Management (IAM) system, it would make sense to create a user store, populate it (or have users self-populate it) with unique identities, then grant authorizations for each citizen to access the full web site. In this scenario the IAM would need to validate the user’s identity and collect information on them.  It might also collect some ‘shared secrets’ so the user could reset their password or to later prove their identity if they called into a help desk.  By the end of the registration process, the IAM may have  collected six or eight or 12 pieces of information about the user.

But what if the library system had a relationship with another organization that operated its own IAM system?  For example, what if the library trusted the Canadian federal government’s ePass system?  In this case, the ePass system has significant user information at its disposal, ranging from birth dates to income and tax information.  The ePass system also has the user’s address…

The library system could enter into a Federated Identification sharing agreement with the federal government. This agreement would allow the two organizations to share limited information.  For example, the federated IAM that resulted from this arrangement could state that the ePass system could only pass the user’s first name and city of residence to the library system.

These two pieces of information (attributes or claims) are more than enough for the library system to do its job.  They do not uniquely identify the user.  The name would simply be used as a greeting on a screen, and the city of residence would be used for the actual authorization.  If the city matched, the system would allow access.  If not, it would return the user to the main web site.

The advantages to the library system are:

  1. no need to purchase or design/build an IAM to meet its authorization needs;
  2. no need to create, store and revoke user IDs; and
  3. no need to collect, store, maintain and protect from hackers sensitive user information.

The advantages to the federal government are:

  1. ability to promote its services as a single sign-on solution beyond its own web sites and business applications;
  2. to show support municipalities that might be struggling to deliver e-government services; and
  3. to demonstrate increased return-on-investment in an existing system.

The user also benefits:

  1. increased convenience;
  2. increased choice, particularly if the library system was federated with multiple parties and the user could select which system performed the authentication; and, most importantly
  3. increased privacy protection — one less system would need to hold their personal information.

While this is a fictitious example, it is good illustration of how our governments can work together to increase efficiency, expand services and protect user privacy.

Mike

User-Centric IdM for the Public Sector

Moving forward, user-centric Identity Management is clearly an interesting alternative to centralized systems.  The promise of a solution where the user has choice over how and what identity information is shared with Service Providers is worth working towards.  It is not surprising that user-centricity is finding its way into pilots and initial implementations in the public sector.

It is becoming clear to me that user-centric IAM is a philosophy / model / strategy that is well-suited to government implementations because it has potential to return ownership of identity information to individuals, many of whom access multiple public services.

If they can avoid it, Canadian governments do not want to hold identity information outside their highly secured core registries.  These government departments recognize that our relatively tough privacy laws prohibit retention of information beyond what is needed to deliver a service.  Storing additional identity information, or unnecessarily storing the same information in more than one place, increases the risk of breaches and identity fraud.

Adopting user-centric strategies can reduce the volume of sensitive data to be managed, move privacy decisions closer to the user and make governments more compliant with their own legislation and policies.  Perhaps most importantly, as Dick Hardt’s Identity 2.0 presentation made it clear, user-centric IdM allows the creation of privacy- and user-driven solutions that mimic the real-world we live in.

This is possible because many systems do not necessarily require identification, but rather authorization.  Or if they do need identity information, they need it to support a transaction and have little need to store it after the transaction is completed.

Think about an e-commerce transaction using a credit card.  The system does not actually need to permanently store identity information. Rather, it needs to know that you have the funds to cover the transaction.  The key information is the card number.  Your name is only provided to support the transaction, i.e. to verify that the card being used can be matched to an accountable card holder.  If these authorization elements are present in the transaction (and not disputed later) then the business can be conducted.  The storing of the name information beyond a reasonable dispute period (say 45 days) is unwarranted.

When faced with breaches of identity information, goverments may soon find themselves needing to identify less.  It may seem counter-intuitive, but for certain low-value business transactions, a government organization may not actually want to know very much about those individuals, or at least they don’t want to have to store information about them in local databases.  What they do want is to ensure that these citizens are authorized to access the system and the information it contains.

An example of a provincial service that could likely dispense with traditional retention of identity information would be a system that issues a fishing license.  When issuing the license, it is important for the individual to properly identify themselves so that their name can be printed on the actual license document.  The license then authorizes the named individual to fish, so after the transaction it is important to have that identity information on the card to support an enforcement officer’s needs for proving ‘eligibility’.  While the issuing department may make a case for retaining the identity information in a license database, does it need to have its own Identity Provider service — chock full of duplicated identity information? Can it not simply trust one of several provincial or federal Identity Providers?

In time, this user-driven approach should result in fewer identity providers and many more relying service providers.  In a provincial government, there could conceiveably be three or four identity providers.  These could be linked to key registries such as HR (for internal users) or public education, health or motor vehicles (for citizens).  Add to this a federally provided IdP, perhaps based on tax records or a passport database, and citizens would have real variety in IdP services.

Moving to user-centric IdM with real choice in identity provider services can provide greater privacy protection and reduce the complexity of government electronic service delivery.

Mike

PS2009 — Winn Schwartau

Feb 4th, 9:40am
Live blog post…

Winn Schwartau is the President of Interpact Inc. He explains how easy it is to gather information on an individual; medical, financial and legal information are all available using a range of free and paid Internet services.

Key concerns:
– On the Internet today, there are approx. 500,000 databases containing personal information.
– Virtually no regulation exists to protect privacy especially in the US.
– No-one reads usage agreements that outline what a company can do with our data.
– Privacy rules/laws difficult to set because technology changes so rapidly.
– 75 percent of US residents have had data on them lost or stolen.

He makes a number of interesting points:
– Why can’t we treat our personal details as copyrighted information? Why can’t we own our own names?
– The questions are ethical not legal.
– We need to redefine ‘public domain’ to mean ‘for the public good’.
– We should be able to tell companies that they can only use our information for one transaction (unless we order otherwise).
– We must be able to request and receive all information held on us by companies.
– We must have data error repair rights and, if possible, some recourse for abuse.
– Need leadership and global cooperation to bring about change.

Interesing and thought provoking, more info at www.thesecurityawarenesscompany.com.

Mike

PS2009 — ePETs

Feb 2nd, 1:00pm

I wasn’t too sure where I’d spend the second part of the workshop day, so I wandered into this panel discussion led by Canadian privacy celebrity Ann Cavoukian and MITRE Corporation’s Dr. Stuart Shapiro:

The MITRE Corporation with the Information and Privacy Commissioner’s Office of Ontario

This session is intended to explore the area of ePETs, which are aimed at supporting privacy within large organizations that must appropriately handle and safeguard large amounts of personally identifiable information (PII) throughout the information life cycle. The dominant focus of traditional PET research and development has been tools to enable data subjects to protect their personal privacy, typically by preventing the collection of PII. There is a growing need, though, for tools that can help data stewards responsibly manage the PII in their possession in accordance with Fair Information Practices.

Okay, so lets start with this: ePETS are electronic Privacy Enhancing Technologies.  Most of the technology discussed was a tool from a researcher named Kaled El Emam from the University of Ottawa.  He has developed a set of tools for anonymizing data for research purposes.  This technology has potential to greatly increase the type of information that a hospital or government organization can share with the research community by quantitatively measuring the degree to which the data has been anonymized before it is released.

The panel discussion produced a number of interesting quotes:

  • ‘Don’t let the perfect get in the way of the good’ — Joseph Alhadeff, Oracle Corp.
  • ‘… an Identity Resolution Service is needed’ — Charmaine Lowe, Director at the BC Ministry of Labour and Citizens’ Services, responding to a question related to resolving mis-information in government registries.
  • ‘Federated Privacy Impact Assessment tools are coming’ — Ann Cavoukian, Information and Privacy Commissioner for Ontario.
  • ‘… [government needs to] consider marginalized citizens who cannot produce the required identity proofing documentation when registering for programs and identity management systems’ — attendee from the Insurance Corporation of British Columbia explaining how he sees many cases each year where, for various reasons, people simply do not have the birth certificates, passports, citizenship cards, etc. required for registration

Overall, I thought this was a well-balanced discussion that reflected on how the practical needs of researchers can be met without eroding the privacy protections we expect organizations to provide us.

Mike

10th Annual Privacy and Security Conference

I’m back in Victoria, British Columbia this week for what is becoming an annual event for me — the Privacy and Security Conference sponsored by the BC Government.  I like this conference because it has a public-sector flavour to it; the speakers and attendees see the same challenges in their work as I do.

The plan is to produce a post or two each day but we’ll see how it goes…

Mike

Canadian Bar Association, Privacy Section

The Canadian Bar Association / L'Assocation du Barreau canadien

I had the pleasure today to present to an attentive and curious group of privacy lawyers at the Canadian Bar Association.  The presentation was a rapid fire slide deck titled Identity Management: Drivers, Challenges and Opportunities; click here to view.

Many thanks to Jane Steblecki from Field Law for the opportunity.

Mike

Identity Assurance — Information Classification

 

2nd in a series [ <- previous ]

The first component of the Pan-Canadian Assurance Model to review is the Security Classification of Information.

There are a number of ways that organizations can classify their information.  The Pan-Canadian model uses the Canadian Public Sector Security Classification Guideline developed by the National CIO Subcommittee on Information Protection (NCSIP).  The guideline is quite straight-forward as its justification is summarized by the following quote:

…when electronic information is shared with external jurisdictions that are not aware of the value or sensitivity of an information asset, it becomes essential that the classification rating be established so that the information protection requirements can be quickly understood, communicated, and acted upon.

Here are the guideline’s information classifications and my interpretations of each:

  • 1. Unclassified — Typically publicly available information.  A breach, loss or unauthorized modification would not result in injury to individuals or organizations.
  • 2. Low — Basic information about an individual, internal administrative systems or the status of a government process.  Breaches of Low level information could cause significant injury (in the legal sense) to individuals or organizations including financial loss, service level impacts and/or embarrassment.
  • 3. Medium — Medical/health information, an individual’s tax information, trade secrets, identity information that could be used to support fraud, etc.  Breach or loss “could reasonably be expected to cause serious personal or enterprise injury” including significant financial loss, legal action, etc.
  • 4. High — Cabinet documents, oil & gas exploration data, criminal case information, information on a police informant, etc.  If information rated High were breached, stolen or modified without authorization, “extremely serious” injury to individuals or organizations could be expected to occur.

The above provides general guidelines on how information should be classified.  It is fairly consistent with classification models I’ve used in the past, and the examples in the guideline are quick easy to understand.

In Practice:

When using this type of guidance, it is important to develop your own examples so that the information your organization manages is used for illustrative purposes.  For example, if you manage permits or licenses, be clear as to how that information is classified both during and the permit application process and after it is completed.

Educate your business clients on the guideline.  IT staff must NOT make the classification decision, nor should they influence the decision-makers one way or the other. Business owners and ‘information stewards’ need to classify the information.  Use workshop settings to uncover information being managed, and use the examples to define information classifications.

It is important to perform information classification activities outside the activity to select security controls.  While it is very true that the classification will impact the controls you select, the knowledge that costly or difficult-to-implement controls might be needed must not influence the way information is classified.

Document the classifications — this could be done by each business area, or recorded centrally as an appendix to information classification standards or information management documentation.

The information classifications are mapped to the right most column in the model.  This column, titled “Potential Impact of Identification/Authentication Error” will drive the remainder of the identity assurance analysis.

Next: Trust Levels.

Security and Privacy Quotes

Here are the weekend quotes, a day early…

On security:

Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. — Helen Keller, author and activist.  Keller, who was deaf and blind, was an advocate for many progressive causes including women’s suffrage and inclusion for people with disabilities.

On privacy and youth:

“Young people are very adept and comfortable with electronic communication. As advocates, we have to help young Canadians find the information they need to be their own privacy watchdogs” — Irene Hamilton, Manitoba Ombudsman, speaking at the semi-annual meeting of Canadian Privacy Commissioners, June 4, 2008.  Visit youthprivacy.ca for more information.

On common sense?

“Many companies need to do more to prevent inexcusable security breaches.  Too often, we see personal information compromised because a company has failed to implement elementary security measures such as using encryption on laptops.”  Jennifer Stoddart, Canada’s Privacy Commissioner in her 2007 report to Parliament.

Mike