Electronic Medical Records -- the new email frontier?

The statistics regarding the impact of EMR (Electronic Medical Records) on efficiency seem far less than encouraging. As commented privately to me, in more than one occasion, significant net drops in provider efficiency are the norm, despite the hype.

The push for EMR adoption on the part of the government and payers is about data, not provider productivity (at least not the kind of productivity that improves a provider's bottom line). A 6% penalty on Medicare billing or a $64,000 incentive is small compared to the real cost of EMR adoption for many providers. The gap between what providers are being sold on and reality could hardly be broader in the industry...

So, the reality is that today's EMR is a really hard thing to do well, as also evidenced by the reported high numbers of failed EMR conversions and large number of second EMRs (replacing a first EMR).

Electronic Medical Records -- the new email frontier?

In contrast, using encrypted email can be much easier for adoption and even provide an EMR basis IF it can complement rather than replace an email system. It should require no changes in the user GUI, no learning, no commitment in other areas, no change to any other aspect of the operation, and should have low cost compared to the base system (email).

This is exactly what ZSentry at http://zsentry.com has been providing, as a complement system to Google Apps, Outlook, iPad, and other existing email solutions, enabling HIPAA and HITECH Safe Harbor (the next need after HIPAA) practically "out-of-the-box".

And ZSentry can also be used as part of a local EMR, allowing secure communication in and out of it. One such hybrid ZSentry/EMR system has recently been certified by the DHHS in the US ARRA program.

So, Yes, albeit the statistics on current EMR efficiency are not encouraging, we can start with simpler systems that are, well, simpler to work with.

How about the future?

If we see the statistics of CNC (Computer Numerical Control) adoption in the early 50's in the US, in the 70's for word processors, and other IT application examples, including the Internet itself, we will see the same trend of less efficiency, frustration, followed by exponential, unbelievable at the time, improvements in efficiency, cost, quality, and every other parameter (except when people look at direct employment reduction as a downside, rather than as an opportunity for progress).

Now, ask yourself how much would it cost to run an IT company the way a physician runs his office today?

For example, how many people-hours/day are used faxing in a practice today? And faxes are not even HIPAA-compliant...How long can this waste go on?

It's just natural that the future comes with a shock-wave. But automation-driven efficiency improvements grow fast and are worth the trouble. The U.S. Census Bureau took eight years to complete the 1880 census, but just one year for the 1890 census. The difference then: automatic tabulation with Hollerith cards.

Now, fast-forward to the US health-care sector in 2011. What's happening with the SOHO and SMB health-care markets? They are shrinking fast since ca. 2000, and becoming far more competitive in price. For example, the share of solo practices among members of the American Academy of Family Physicians fell to 18 percent by 2008 from 44 percent in 1986. And US census figures show that in 2007, just 28 percent of doctors described themselves as self-employed, compared with 58 percent in 1970. Many of the provisions of the new health care law are likely to accelerate these trends in the health care sector.

Because efficiency will become even more critical for the survival of solo and small practices, they may be more likely to use simpler, secure email first and move to EMR as possible. I doubt they will continue to use fax, or even dare to ask their patients to run to the pharmacy with a written prescription, or refill by phone. Larger health-care providers may also see faster returns by using simpler systems first. Keep It Simple -- and I see no need for adding a second S at the end.

Ed Gerck

Silverlight, Flash, PDF and other Online Form Techniques

[Target Audience: Developers and System Administrators]

There seems to be growing interest for an online form service allowing customers to collect input from users and send it back as structured information to organizations, while preserving confidentiality including input, transmission, archive, access, and auditing functions.

The ability to enable customers to style online forms, for different server scenarios including absence of server-SSL input protection, should also be part of the available customer-design process. Further, the online form service should allow customers to use web forms, email forms, SMS forms, storage file forms, and any other communication process.

ZSentry is currently beta-testing such a Secure Online Form service that meets these considerations.

This work has led us to think more deeply about the pros and cons of Silverlight, Flash, PDF and other methods used to provide online form functions, as well as security and usability, which are the motivations for this posting and feedback.

In many cases of interest, the online form service must assure full HIPAA compliance. Safe Harbor compliance (even without HIPAA) is also coming to the foreground given the high profile and costs of recent breaches such as with Epsilon and Sony.

From the security viewpoint, and contrary to ZSentry for Google Apps (where both the need for HIPAA and Safe Harbor compliance can be satisfied by ZSentry), online forms as enabled by Google Docs cannot at this time be used by ZSentry as a basis for such secure service. The recent security breaches caused by phishing attacks against Google Apps and Gmail further highlight the concerns of storing plaintext information in online services such as Google Docs.

Our usability starting point is that online form functions are "critical" and, thus, in principle should be usable without asking the user to download or do anything else.

Usability is also necessary to ensure security, as we mention elsewhere (Usability is a system's #1 Security Property). In short, a secure online form service that is secure but not usable will not be used and, therefore, will actually fail to be secure. If security is too difficult or annoying, users may give up on it altogether.

Therefore, while it is OK for an information or help document to be available in PDF (with all the PDF requirements/problems to be met and solved at the user side), users can either view the PDF using any quick view software/service (including Google) or just move on to something else. Not so with an online form that needs to be entered.

We also see that many users are just that -- users -- and have no admin privilege in their devices. Increasingly, devices are locked (also by manufacturers -- see iPad vs Flash) for installation.

These concerns go against Silverlight. It could be better to use Flash (more widely available) but still many users would be left out as new Flash versions come out quite frequently and many users cannot update or do not like to bothered by yet another update. Silverlight also suffers from frequent updates.

How about JavaScript? It is commonly available. However, even JavaScript should only be used to provide added usability, while the online form itself should be functional without JavaScript. This is important not just because some devices have problems with JavaScript; some networks and services also block JavaScript.

In comparison, even though Silverlight or Flash based online forms may look more usable for corporate intranets and other special subsets of users, for public Internet users they are actually not as usable as HTML/CSS with optional JavaScript.

ADA and accessibility requirements also point to HTML/CSS with optional JavaScript.

In conclusion:

1. Knowing the target-user comes first, as it defines how the message needs to be delivered. Silverlight, Flash, PDF forms, and other non-HTML solutions can be used well in an intranet (internal services in a hospital, for example) where the organization can control the server, the network, the filters, all the clients, and what is installed and updated at any moment in those clients. Lacking that inclusive control, it is bound to fail in the public Internet for the same reasons.
2. From the user's viewpoint, HTML/CSS with optional JavaScript should be the best practice for online forms using the public Internet, as providing the needed functions while not standing in the way of using the online form -- which is the user's goal.
3. The ZSentry API for secure online forms is designed so that it can be used with any desired method, including HTML/CSS with optional JavaScript, Silverlight, Flash, PDF forms, and other interfaces. It is up to the developer to make the best use of it.

Comments are welcome. ZSentry for secure online forms is currently in beta test. Please submit a Support Ticket if you are interested in participating now or when the service is launched.

Cheers,
Ed Gerck

NMA ZSentry API -- Frequent Questions

[Target Audience: Developers and System Administrators]

The NMA ZSentry API is a secure software service that works in your environment. You can use the API both in a server as well as in a client context. There is no plugin or installation. With the ZSentry API you can readily connect, send, and store information securely, for example as a secure email, enabling secure communications in desktop, cloud, and mobile platforms, anywhere.

What is the NMA ZSentry API?
An SMTPS (SMTP over SSL, also called implicit SSL) service. You use the ZSentry API to connect your system to the ZSentry engine using TCP port 465 for encryption and decryption directly or through a message service or application. The resulting secure emails are encrypted per message and can be sent using ZSentry's own SMTP server, without requiring SSL, or can use another resource as a mail relay with or without SSL.

Why port 465?
With port 465 there is no ZSentry data exchange without SSL, including the ZSentry Usercode and Password data. Contrary to the submission port 587 with STARTTLS where the connection changes from non-SSL into SSL, port 465 has SSL-at-connect required. We prefer port 465 because every connection is encrypted from the start, preventing problems such as the SSL bridge attack (a well-known problem also for web browsers).

What server-side applications and servers are compatible?
The ZSentry API complies with IETF standards. ZSentry tested the API using servers with the dovecot/postfix Debian implementation and other Linux flavors. Customers have tested the API with a variety of Linux and Windows technology, including System.Net.Mail, CDOSYS (Collaborative Data Objects, Cdosys.dll), VB6, PHP, Java, and Sybase PowerBuilder.

Do users need to use ZSentry App (the web interface)?
No, not necessarily. The ZSentry API sends secure email that can be read and decrypted using the ZSentry App as well as leading Mail clients without any plug-in. This means that with the ZSentry API there is no web browser security and usability limitation for users, and users do not need to use the ZSentry App for reading, sending and saving secure messages. However, the ZSentry App can be used in a webmail environment.

How about Google Apps and Gmail?
Web mail services including Google Apps and Gmail can be set up to send HIPAA-compliant secure email using the ZSentry API directly, as a cloud Mail client with Single-Sign-On. This can be done by users, without an add-on or installation. Reading and saving secure email can also be done through Google Apps and Gmail,
using ZSentry App in the webmail environment or a Mail client.

How are Mail clients used?
Mail clients can be set up to send, read, and save HIPAA-compliant secure email using the ZSentry API directly, with Single-Sign-On. The user only sees the Mail client GUI for sending, reading and saving messages. This can be setup by users, without a plug-in or installation. A web browser is still used on the client side, but it is used transparently as a middleware and not as a GUI.

What clients are compatible?
The ZSentry API complies with IETF standards. Compatible clients include any major web browser, Outlook, Outlook Express, Windows Mail, Apple Mail, Entourage, Thunderbird, iPhone, Android, and iPad, on Windows XP, Vista, Windows 7, Linux, Mac OS X and iOS.

What applications can be used at the client side?
Clients can use several applications including webmail, email, IM, SMS, and file storage services.

Can I debug the SSL/SMTP flow?
Yes. This is a typical SSL/SMTP trace enabled by the API and which you can also capture in normal use to log delivery evidence for your service:
--------------
SMTP -> FROM SERVER:220 mail.example.com ESMTP Postfix
SMTP -> FROM SERVER: 250-mail.example.com 250-PIPELINING 250-SIZE 20480000 250-VRFY 250-ETRN 250-
AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
SMTP -> FROM SERVER:250 2.1.0 Ok
SMTP -> FROM SERVER:250 2.1.5 Ok
SMTP -> FROM SERVER:354 End data with .
SMTP -> FROM SERVER:250 2.0.0 Ok: queued as E519A5801F4
-------------------------

More Information:
http://zsentry.com/zapi.htm

Sender-Defined Security

When you send an email to a recipient, who bears the highest risk?

Usually, you. Because the information is transferred from sender to recipient, the sender likely has the highest risk. The information may be valuable to both, but the sender is the party that can be found liable for (even if inadvertently) disclosing it to others. Email is risk-asymmetric.

For example, patients may initiate communications with a health care provider using unencrypted email, according to HIPAA. This is done at the patient's risk. However, providers may have concerns when replying to the patient using unencrypted email. Providers are subject to potential liability under the HIPAA Privacy Rule [see 45 C.F.R. § 164.530(c)], including their determination whether a patient is aware of the possible risks of using unencrypted email.

Since the sender is the party at risk, the sender needs to be able to define the security conditions, for example, for confidentiality, delivery, and tracking of the message.

Let's see how certified postal mail works. The sender chooses the service and the type of envelope to protect the message. The sender also chooses the instructions
that must be followed before the envelope can be opened by the recipient. The recipient has no charge to pay for, or burden, in order to receive the envelope, and does not have to do anything before the envelope is sent. The recipient is able to verify the identity of the sender and, if so desired, refuse the envelope. The recipient can open the envelope if and only if the recipient is willing to follow the sender's instructions (e.g., providing name, address, date, signature).

The same should be available for sender-defined security modes of operation for email.

Using IBE encryption (Identity-Based Encryption, Voltage, MessageGuard) does not work because IBE requires sender key-escrow, so that the sender is always at risk that her messages can be read by someone else.

Clearly, a conventional public-key model (PKI, X.509, PGP) cannot provide this functionality either. The security model for protecting email with public-key cryptography is backwards, technically and business wise. The sender, who is the party at risk, has to trust a lock provided by the recipient (his public-key) to protect her secrets (the message).

If certified postal mail would provide message security a la PGP, PGP/MIME or S/MIME email, the sender would have to convince the recipient to pay and send in advance an envelope for the sender to use. The sender, however, would never know whether the envelope indeed prevented others from prying into its contents. Moreover, the recipient is not the business driver who needs to provide, pay for and protect the lock. The sender is the party who has the motivation to spend money to provide and protect the lock.

These are well-known and recognized standards for encryption of email. However, their security and usability problems noted above cannot be solved by improvements in usability, better pricing or user education regarding how IBE, PKI, X.509, or PGP work. It simply does not work as it should work. That's also why conventional secure email has been difficult to use. It has the wrong logic for the problem.

ZSentry is a security technology that was developed after these standards and improves upon them in both usability and security. ZSentry provides per-message encryption, authentication, message control, and auditing, protecting information in motion and at rest. ZSentry reduces the trust and control requirements in several critical areas, making it easier to attain and demonstrate a higher level of security while increasing usability.

Most importantly, ZSentry enables a secure email system that works closer to how postal mail, including courier and certified postal mail, works.

Because ZSentry mail can be delivered securely to both registered and also to unregistered users, the sender is able to define the delivery conditions that must be satisfied by the recipient before the message can be decrypted (delivered) in each case.

For example, based on what is at stake and what threats may apply, versus the usability requirements, the sender can select from the following delivery conditions:

Require Registration: (For higher security: use this option) The recipient must register before reading the message. After the recipient registers, delivery is further controlled by the Delivery option specified by you for registered users (see next items).

Require Login: (For higher security: use this option) The recipient must be registered and login before reading the message. To reduce risk, this process includes mailbox authentication, login monitoring, message expiration, and other control features.

Read Until Expiration: (For higher usability: use this option) Available for both registered and unregistered users. The recipient is allowed to decrypt the Zmail, including attachments (if any), as many times as desired until the message expires. The security of the Read Until Expiration mode is based on mailbox authentication, login monitoring, and expiration control. The sender can choose when to expire, where the sooner the better for security.

Reply to Sender: (available in all options, including without registration or login) This is a very useful choice to receive a secure reply, as the recipient has no burden to reply securely (can reply securely just with one-click).

The security of these Delivery choices is further enhanced by other choices, including for Control and Tracking, for example allowing the sender to choose a message self-destruct time and real-time audit reporting with a Return Receipt.
The Return Receipt is sent back to you with information on When, Where, How, and by Whom your message was read.

You can also compare the Return Receipt with the corresponding Send Receipt (available from the server, upon sending), closing the loop with potentially more comprehensive delivery and notary evidence than using courier or certified postal mail, with less cost and immediate delivery.

In summary, ZSentry puts the sender in the driver's seat of secure email, with more and more effective options than any other system including IBE, PKI, X.509, PGP, courier and certified postal mail.

Large EMR privacy breach notification, two years later -- an exception or a symptom?

NOTE: A colleague and I are working on a paper discussing a number of  privacy and security red flags that can help call attention to these and other issues, especially in the context of secure email. A draft is gladly available to those who are interested, by private email request, for comments before  publication. 
 
Electronic medical records (EMRs) are at the heart of health care reform, and there is both a personal as well as a legal expectation of privacy for EMRs.

Promptly notifying users of privacy breaches can help bring accountability to the system, and help users.

In February 2010, RelayHealth (also known as NDCHealth Corporation) acting as a claims processing company, notified prescription holders that EMRs of two years ago, dating between February 2008 and December  2008, with full name, date of birth,  prescription number, insurance cardholder ID, and drug name, that were  dispensed at Rite Aid as well as other retail chain pharmacies and  independent pharmacies in the State of California, were sent to an  unauthorized pharmacy.

After I mentioned this case online, RelayHealth has contacted us in March 2010 and stated  that the data was sent in error only in November 2009, so the delay in informing consumers was not two years but three months.

However, we note that this information was not provided to RelayHealth's consumers when the privacy breach was disclosed in February 2010.  RelayHealth may want to look into that communication and verify why they did not disclose a delay of three months.

Further, what matters to our analysis here is the consumer privacy risk, which includes the two-year delay.  If, for example, three-year old files are wrongly disclosed today and the EMR processor informs the patient tomorrow,  this is not a lesser problem for the patient (as the next mentioned Fortis case exemplifies).

The 2010 breach notification did not disclose why the information was sent (Who requested it? Under what authorization? Who approved it?), who incorrectly received  the EMR, and who was responsible for the breach, neither what compensation or recourse users may have.

In a recent court case, Fortis (a US health insurance company) was found to have a practice of targeting policyholders with HIV. A computer program and algorithm targeted every policyholder recently diagnosed with HIV for an automatic fraud investigation, as the company searched for any pretext to revoke their policy.

Companies such as Fortis can find out about anyone's diagnosed HIV, or other illness, through pharmacies and claim processors, for example.

This situation underscores the underlying conflicts of interest between at least three distinct roles that RelayHealth plays. They are:

1. claims processor;
2. provider of patient EMR to their pharmacies and doctors;
3. provider/seller of EMR to providers other than the patient's.

This last activity has the greatest potential conflict, as patients are included in a no-opt-out policy at www.RelayHealth.com that says (words in square brackets are comments, not from RelayHealth):

"Your Provider, a Provider-Designated User [pretty much anyone] or  authorized member of a Provider Group  [anyone] can use contact and/or health information about you stored by RelayHealth for many purposes including [ie, this  says that it does not exclude anyone or anything]:
..."

and

"RelayHealth may use the contact, billing and/or health information [EMR] provided by you in our service to provide your physician or other healthcare provider [ie, anyone they want]  with updated and/or supplemental information for their files or systems." 
 
A pattern that seems to emerge here is that because EMRs also have a market value (for example, to insurance companies, pharmacies, etc.), health care service companies can build automated information exchanges where they can make collected EMR available to other entities, and build a business on this activity.

That the same health care service companies (with different hats) also serve on behalf of the patients to protect the EMR from disclosure, is where the fox is taking care of the hens, and where the conflicts in 1-2-3 may play a role.

What this means is that the expansion of health care into larger use of EMRs ought to call for a much broader review of procedures and conflicts of interest than what is currently available. And, obviously, it should also include stricter rules for information security and handling of EMRs than what's currently used.

Your comments are welcome.

Best regards,
Ed Gerck

Discussion summary on improving SSH

SSH (OpenSSH) is a workhorse for secure web administration and, as such, important for managing Internet servers including email. SSH is, usually, the only way to access remotely located servers. Of course, this makes SSH a valuable attack target.

There are established practices for securing SSH. However, they currently rely substantially on additional systems, that also present their problems and add to the maintenance burden.

After some discussion in the cryptography@metzdowd.com list and in private, I present below a summary of the dialogue and clarifications with a view to improve SSH. I've divided it in sections A-F, to make it easier to discuss.

A. THE SIX SSH ISSUES
The free test tool Nessus allows a remote SSH server to be quite easily discovered and explored by automated scans & attacks. The information obtained in SSH server scans can be typically divided (from the view point of a sys admin) in six issues (to be discussed later, this is just a list):

1. no way to block scanning and attacks
2. does not learn from attacks
3. advertises itself and the server OS
4. allows empty authentication requests (eg, requests by invalid users)
5. sends host key fingerprint to invalid users (eg, with no username)
6. sends a reply to invalid users (eg, with no username)

These issues, alone or in combination, can lead to multiple vulnerabilities, some with higher security significance than others (according to operational factors as well).

B. CRYPTO
Let's first state that not all the six issues are created by crypto use in SSH. And this leads us to the main question here:

Could new crypto in SSH help mitigate or solve any of these six issues?

Currently, how are these issues addressed? By non-portable and potentially buggy methods (see below), with more software that has to be patched, updated, configured and tested, all at different times, with added security gaps that can be compromised.

New crypto methods in SSH could do a better job by reducing the problems in the first line of defense at SSH itself and by avoiding security gaps. Non-crypto things such as PAM, tcpwrapper, port-knocking, grey-listing and others can always be added later anyway, if desired.

C. PASSWORDS
Some issues could be minimized by turning off password authentication, to use only private/public keys (PKs). SSH allows users to generate PKs without cost (no need for a CA). Users can keep their private keys in their drives and also in a USB dongle, for example. One can also add second-channel authentication (e.g., RSA SecurID) to SSH with a PAM or a patch.

However, turning off password authentication is not desired in many cases, even when PKs and second-channel authentication are used.

Password authentication may be more secure against attacks on the client, to gather information before compromising the server. According to Peter Gutmann, a study of SSH attacks a few years ago showed that nearly two thirds of all SSH private keys were stored on disk with no password protection at all, so that simply being able to read a hard drive will get you access to any number of systems without having to trojan the SSH client or plant a keyboard logger as you'd need for an SSH password. So turning off password authentication could make things less secure, not more.

Another reason for using passwords in SSH, and perhaps more compelling, is that you don't want to risk getting locked out just because your disk died, you forgot your laptop, SecurID or USB dongle, and the private key cannot be found (for security reasons!) in the back-up. Passwords can also easily be given over the phone from sys admin to sys admin, and are easily protected by threshold cryptography. And using a private/public key pair in SSH would anyway require a password for protecting the private key.

Using good, high-entropy passwords turns out to be preferred by many sys admins because it is simpler, more portable, and works fine for security (provided the password is chosen with enough entropy). Sys admins already need to use many passwords for many servers and protocols, and have safe methods for off-line storage, redundant record keeping, and authorized record access (including a handwritten notebook, encrypted USB dongles, and a printed list), that are of course not kept near the computer.

D. PAM
Some of the issues can be solved with SSH PAM, such as pam-abl. However, PAM libraries are usually buggy (buggier than SSH), and might be unstable unless suitable PAM items were added by which the daemon can communicate the client IP address and port number, and maybe other things too.

E. SOLUTIONS
I believe that each one of the issues 1-6 can be met by a cryptographic protocol deployed in SSH. Some solutions are well-known. BTW, there were some similar issues in the SSL protocol.

F. ISSUE BY ISSUE REVIEW

#1. no way to block scanning and attacks

Firewall port-knocking can help here. It is hard to guess and defeat; nothing shows up in scanning. However, it is not portable and is hard to debug and use.

While there are also IDS that can turn off the SSH port if a scanning is detected, this can lead to DoS.

Pam-abl can also help, but PAM is usually buggier and adds security gaps.

Possible solution: SSH could easily incorporate some of the pam-abl code, enough to block an IP for some time T after N failed attempts, self-clearing after T.

#2. does not learn from attacks

Possible solution: SSH can incorporate some of the pam-abl code for this purpose.

#3. advertises itself and the server OS

"Need to know" is a valuable security policy.

Advertising the OS may compromise a higher security function (the OS) in the case of a zero-day or unpatched exploit. SSH MUST NOT advertise the OS. It may compromise policies and apps in a lower (more critical) layer than SSH, not just the OS.

Also, advertising SSH's innards in "already dead" authentication has no useful purpose that could not be more securely met.

Possible solution: let the client tell its version to the server, for the server to decide if it is acceptable -- it is a server function anyway (eg, not to accept SSH v1).

Additionally, it would also be useful for the client to send to the server a list of acceptable configurations, for the server to select, so that the server would no longer be groping in the dark as to what algorithm and parameters to use.

#4. allows empty authentication requests (eg, requests by invalid users)
#5. sends host key fingerprint to invalid users (eg, with no username)
#6. sends a reply to invalid users (eg, with no username)

- Some claim that the SSH protocol requires key exchange to occur before the user identity is sent, as it protects the user identity from disclosure to an impersonator.

However, if the user does not have a valid username, why and what should the server have to prove to that user? Invalid data deserves either "no response" (safer) or an error response. The SSH server should not do work or provide information to an user that is known already to be invalid. The SSH protocol needs improvement here.

- Some also claim that if the SSH protocol would permit such differing responses for valid/invalid users, then attackers can use SSH as an oracle to determine username validity.

However, SSH can prevent username enumeration by trial and error. With a simple keyed-hash, if this protection is desired, one would just enter the same key for the server and clients, so they can be all using the same transform. This is a simple mechanism that hackers cannot break by guessing. Note that SSH already uses a hash mechanism to hide domain names in the hosts file.

- Some claim that the issues #4 and #5 are actually "features" that are used by some of the anonymous services, such as anonymous CVS.

However, these "features" could be closed by default, and opened in the sshd config file if desired. This may also need some cryptographic protocol changes.

Because the reported issues could be improved by adding crypto, I am asking for more input first, before taking these issues to the OpenSSH development list. This should help the development effort. The OpenSSH development mailing list is at:
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Thanks for all the input! Comments are welcome.

Cheers,
Ed Gerck