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.