Critical policy failures of the Canadian online Census

(Also carried by p2pnet)

I have seen this issue covered in a variety of locations, and is being discussed in a number of different forum. On Thursday there was a Newsforge article by Bruce Bayfield with the headline "Canadian online census discriminates against FOSS". A few citizens have written letters to their member of parliament about this embarrassment to Canada.

I thought I would weigh in on this issue as a technical, policy and security consultant.

First, I do not see this as a FLOSS/Linux vs non-FLOSS/Microsoft issue. I do not believe that the government should be expected to make implementations of software available for every platform that its citizens may use. In fact, I'm not convinced that the government should be involved in providing implementations of software to be installed on peoples computers at all, with this being the major source of my complaint.

What the government should be doing is clearly documenting the free/libre and vendor neutral standards being used to communicate between citizen and government computers, allowing a wide variety of implementations to be authored. Citizens can then choose a supplier that they trust, or get together in a coalition of citizens to create their own trustworthy implementation.

While the government may provide a list of vendors who supply compliant software, if they distribute software themselves it should be mandated to be publicly disclosed third party audited software.

Private citizens should have a legally and government protected right to make their own choices of what software they install on their computers. Computer software is just a set of rules or instructions which a computer obeys. It should be the owner of that computer and not a third party, whether a Virus author, the government or the entertainment industry, that should be able to determine what instructions the computer obeys. (See "Code is Law" Speedgeek)

The claim from the government is that the specific software in question is being used for "security" purposes. I believe that this is false, no matter what definition of security you are using, or what threat you are using this security to protect against.

The vendor-dependant platform choice.

The software happens to be dependant on specific versions of the Sun Microsystems implementation of the Java language. This implementation is only available for a subset of computers..

While vendor neutrality is a legitimate public policy concern, I do not believe this concern is critical to the question of security. Many technical people have become distracted by those who claim this implementation is insecure as they believe that this is an evaluation of the Java language or of the Sun Microsystems implementation. Whether or not the specific implementation of Java that is required to make this application work has flaws does is not critical. The critical issue is that an application written in a full featured language is being run on a persons personal computer, with all the access to other information and settings on that computer that any other application would. Whether the application is written dependant on Sun's Java, a vendor-neutral Java, or in "C" does not matter.

This code has not received third party audit

While there is a claim that the government audited this code, this should never be considered sufficient evaluation for software that is going to be installed on computers not owned by the government. The government should be expected to do their own security audit of any software that runs on government computers, but the same level of auditing should be allowed of citizens who should be able to do their own audit. Encouraging citizens to download, install and run unaudited software from the Internet on their computers is an extremely bad policy. In a world with so much harmful code being inadvertently installed on peoples computers, the government should be actively helping to educate people to never install random software from unaudited sources -- not becoming one of those unaudited sources themselves.

The government has mandated that this software be unable to receive third party audit

A group of security students at University of Ottawa (That happen to have a podcast called The Parliament Hillbillies in Ottawa) filed an Access to Information request for this software. Not only did they not receive specifications of the software or any necessary source code, they did not even receive documentation of what security policy is theoretically being implemented by this software. Not only is the implementation not able to be audited, the underlying policy being automated can not be audited.

Any claim that the government may have that the information can not be disclosed for "proprietary reasons" are invalid. This information must be disclosed, and if a vendor is unwilling to disclose this information then this issue should have been resolved as a mandatory requirement of the procurement process. Vendors who are not willing to publicly disclose for third party audit any software that will be installed and run on citizens personal computers should have been disqualified from the bidding process.

As a security person my recommendation is to stay away from any site which claims you need to download and run unaudited software on your computer. This must include government sites, so citizens are recommended to not fill in the online census and use the more secure paper version of the forms.

There are other people who have recommended a boycott the Canadian Census for other reasons.

Statistics Canada has contracted out software, hardware, and printing of the 2006 Canadian Census to Lockheed Martin--the world's biggest arms manufacturer, a maker of weapons of mass destruction, a company that continues to benefit from the war in Iraq, a company known for corruption and breaking the rules, and a company that could possibly invade our privacy under the US PATRIOT Act if it obtained such information.

While I agree with this campaign, I would still be recommending against using the online census forms even if a more trustworthy firm had been contracted. The fact that this specific firm has been contracted just adds fuel to those who quite legitimately are boycotting the online census.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Is it just me, or is that a violation of section 9(1) of the Statistics Act?


This is really the tip of the "SecureChannel" iceberg.
What we have is a conflict between open desktop requirements (which requires that the desktops be owned by the users), and CSE Common Criteria, which prefers that CSE own all computers.

mcr's blog entry:

Regarding FOSS rescrictions.

I've spent a fair amount of time analyzing the browser compatibility on the census app. As a Linux user, I was obviously irritated to see that my platform wasn't supported, but the issue for me has nothing to do with forcing the government to produce software that can run on any platform its citizens might run.

The biggest issue in my opinion is that by looking at the app itself, I found absolutely no reason for it not to function on linux. There is just a little piece of Javascript that checks to make sure that the person is running Windows or OSX and anything else simply 'return false;'.

What this means is that instead of actually testing to see if it would work, the engineers simply assumed that nobody would care and that it was not worth it to do the extra work, which is the digital equivalent of giving me the finger.

The reason why the web has become so popular is that it allows you to deliver your content or your apps without having to worry about the platform or language or usability preferences of the user. It's basically just like one big road and you can use it to go from point A to point B regardless of whether you are driving a truck, a bike, a minivan or a sport car. The census app is basically building a road but we don't really know if it can handle all vehicles so we simply don't let you on our new road unless you're driving a GM car, because that's what we bothered testing it with.

Furthermore, the app is built in J2EE/JSP with some of the UI using Java applets. Java is supposedly the technology of choice for people who want to "write once, run everywhere". In this case though, they used this technology for "write once, run where we've bothered testing".

Really, if they went through the trouble of testing under Firefox for Windows using JRE on Windows, I see no technical reason why that same app wouldn't run using Firefox and JRE on linux, since both of those technologies are meant to be completely cross-platform.

Of course, I still have the option to fill out the paper form and send it out, but this is just like having an election with a brand new road that goes straight to the polls, but that only works for GM cars... Buy GM, or Walk.

Don't be distracted...

The JavaScript program simply detects what environment is being used before downloading and executing the larger program. It is not this JavaScript that causes any incompatibilities that may exist, and this script is used to ensure that once the larger program is downloaded it will execute in a predictable manner and not fail.

The program that is downloaded and executed is written in Sun's Java. Do not let this programming language choice distract you, as the program could easily have been written in a number of other full featured programming languages to end up with the same policy issues.

It is the underlying policy that is at issue. What the Government wants to do is make your computer into a "trusted remote terminal" for their application. In order to make your computer into a terminal trusted by them it needs to be under their control, and not yours. It is this policy, of the government or a private sector firm which they have hired taking control of your personal computer, that should be what causes the greatest concern.

To understand this backward "trust" model I suggest people view the [LAFKON] movie about "Trusted Computing", substituting the government (and/or chosen vendors) for where the video lists specific industry players.

Please read Mike Richardson's article. Governments need to modernize their security policies where each party can trust the computing environments that they own, and these environments securely communicate using free/libre and vendor neutral communications standards.

When a citizen owns a computer they should have the protected right to trust the software on their own computer based on their own personal convictions, and under their own security policy. When the government owns a computer they should be able to guarantee that these machines run under the governments security policy.

I am curious if you received a reply from your member of parliament? I am assuming everyone concerned with this issue have written their MP!!!

Free/Libre and Open Source Software (FLOSS) consultant.

You have all listed

You have all listed important points, and I'd like to further the discussion by saying the tenet of modern cryptography is to only use algorithms you know and trust. Since there is *NO publicly available documentation on SEAL or the online census, there is absolutely no reason to -- and in fact a compelling reason not to -- trust the census application. Russell makes the point that the code is not availalble.

I would add that the cryptographic algorithms are also not available. A digital certificate is normally employed in the real world to bind an entity to a public key. In the case of SEAL, that certificate only binds an entity to that key for the session. After the user has completed the census, the certificate is recycled and given out to someone else! There could be numerous security implications for this design choice, so the open academic community needs to be researching this to verify it's not totally insane!

Statscan has spent a truckload of money on this project, yet they've given the public no reason to trust it. And the "because we say so" argument does NOT count. They just haven't earned it, so let's not let them get away with it!

Ladies and gentlemen, please; use a paper and pencil. DO NOT DO THE CENSUS ONLINE.

More info from Alex

Alex posted an introduction of himself to a publicly archived forum. This message contains quite a bit of information.

I am replicating the post below as it is quite valuable.

At the behest of Russell McOrmond, I've finally joined this mailing list. I understand the topic of the online census has become of interest of late. I think I might have something to contribute to this discussion, so allow me to introduce myself to the group.

I'm an engineering masters student at UO studying information security. Now this is a fairly broad area and includes the fields of cryptography, anonymity and access control. One of the unique requirements of those working in this area is the amount of time one must spend in the roles of both cops and robbers; both as the cryptographer and the cryptanalyst.

This exercise comes down to the concept of trust. There is no formula for trust, and like in any other social setting, trust is only earned through time. Likewise trust is built by many acts and destroyed by only one. These principles are no less important in information security than they were when one's mother taught one as a child.

Consider the implementation of SSL that you might use to do your banking online. Aside from that fact that the code is open source, with which you can personally satisfy yourself (aka trust) the code's correctness, the cryptographic algorithms employed are likewise open. Presumably the reason we would trust something like RSA, AES, DSA, etc is because we know that alot of mathematicians, more conversant than ourselves, have spent a lot of time banging their heads against these problems, and likewise published their efforts in open academic journals. This is the foundation for trust: a chosen set of people who's abilities you respect, who cannot readily find a flaw -- the
more the better -- forms the best means for you to make a personal decision about what algorithms you trust.

As you can see however, the consequence is that building trust requires openness. The tenet of modern cryptography is that the security of a properly designed system relies entirely on the secrecy of the key, and not whatsoever on the secrecy of the algorithm. Indeed knowing the algorithm is absolutely essential to build trust for the reasons noted. However there is a deeply ingrained belief in those unversed in these matters that "revealing the inner workings could compromise the security." My recent encounters with the government have all contained that sentiment.

The online census is this month as you undoubtedly know. Though held every 5 years, this is the first time citizens may respond online. The census data likewise must remain secret for 92 years pursuant the Statistics Act for several reasons. One is to prevent historical abuses, such as the US Government using the census to round up Japanese-American citizens during WWII. (And yes, there is still a "race" question on the census long-form, much to my surprise). Here the point of attack is within the government, but in an electronic environment, another point of attack is introduced between the respondent and the government. Privacy is obviously one concern, but consider also integrity. An attacker must not be allowed to significantly alter census data as it is being submitted. But finally there is the PR aspect of security. Statscan wants to convince people to share their personal data with them, and has to make them feel comfortable by addressing their privacy concerns. They have spent to the tune of $4 million dollars on the electronic census and thus have a considerable financial interest in people using it.

There's just one problem: the whole thing's a big secret.

The enabling technology is something called "Session Encryption with Automated Login" (SEAL) which furnishes the respondent with a set of cryptographic credentials. Likewise, the Entrust Truepass client-side applet manages these credentials and the corresponding encryption and signing of census data.

Back in February, I went on a personal campaign to get information about the inner-workings of SEAL. This was back before I knew Russell, GOSLING, or even what an ATIP was. You can imagine my wake-up call since then. Except for one Powerpoint presentation from the director of the government's Secure Channel from the GTEC conference in October last, there is *NO* public documentation about this technology.

The PWGSC, having been the ones to commission SEAL, have been the target of my ATIP efforts. Last month they gave me a response: they're delaying my request for 100 days while they consult with Bell over what they feel comfortable releasing. In this case "comfortable" means what they decide is NOT a trade secret. Conveniently, the census will be long over before (I suspect) they will reject my request.

So here I submit to you, there must be recognition by the government of the public's inherent interest in this matter. The public will, at their own risk, employ this technology essentially to grant the government a favour. To treat the request for disclosure in the way the GoC has is unacceptable. To so unapologetically place third party financial gain before public privacy is disappointing. It would seem there exists a conflict between the Access to Information act's trade secret clause, and the Privacy act. While PWGSC is fond of citing the ATIP 3rd party trade secret clause, they cannot verify their ability to protect the public's privacy while the technology remains secret. So what began as an exercise to protect the public, has really instead ended in farcical clamour for the government to protect itself and its contractors.

Security that exists unto itself is no security at all. Trust built upon secrecy likewise. If these concepts refuse to permeate the handlers of the online Census, absolution will only be found in a stubby pencil.

Aleks Essex

Lockheed Martin and other vendor/contractor choices.

Many of the question about the specific procurement choice of Lockheed Martin are answered in a FAQ provided by Statistics Canada as well as a report from the Information Technology Security Verification Task Force.

None of this addresses the concerns that Aleks Essex, Mike Richardson or I brought forward, but does discuss the concerns people had about that specific vendor.

My concerns are vendor independent, whether discussing Lockheed Martin, Entrust, Microsoft, Apple, Sun or other vendors implicated in what many are calling the Canadian census scandal.

In the case of software to be downloaded and executed on equipment owned by a private citizen it must be the personal convictions of that person, and not a third party such as the government or a contractor, that should determine what software is to be installed. While some citizens may trust the software choices of the government, it is inappropriate to discriminate against citizens who have different personal convictions. While I'm not convinced it is a violation of section section 9(1) of the Statistics Act as Julianna suggested, it comes pretty close and may be worth some lawyer pursuing this question.

Free/Libre and Open Source Software (FLOSS) consultant.

Comments from people involved with the census...

There are some odd quotes in this article. There seems to be an attempt to claim that the encryption used in the census is somehow better than plain ssl. The technical stuff seems a bit bogus to me (eg. 128 private key vs 1024 bit public key).

Here is a random paper found off a google search that strongly implies that the proprietary encryption solution used was not originally suited for the task (no anonymous logins) and needed extra effort to allow it to work at all. It suggests that technical virtue might not of been the most important factor in the choice of the system used in the census.