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.
- 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.
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.