Go to the {0} homepage
Join Meeting | Logon | Register | About
WebHuddle: Uniquely Secure

WebHuddle is truly different from other web conferencing solutions, especially in terms of size, simplicity, and cross-platform support. WebHuddle’s security advantage, however, is perhaps the most important difference. With WebHuddle, security includes: protecting the privacy and integrity of your meeting and data; protecting hosts, participants, and the WebHuddle service itself from potential compromises; and using an explicit "opt-in" model for executing privileged actions on a given meeting host or participant’s computer.

WebHuddle assures the privacy and integrity of your meetings through the exclusive use of HTTPS to encrypt all meeting content. Also referred to as SSL (Secure Sockets Layer), HTTPS has proven itself through millions of online banking and e-commerce transactions. It virtually guarantees that meeting data cannot be understood or altered by someone eavesdropping on the Internet. HTTPS, in conjunction with certificate authorities such as Verisign and Thawte, also assures the identity of the WebHuddle service itself, preventing the so-called "phishing" scams seen recently where rogue websites pose as legitimate ones.

Other web conferencing services offer HTTPS as an option, charging extra for it. Still others use it to encrypt only a portion of your meeting data -- because HTTPS requires extra processing power -- leaving the rest unencrypted. WebHuddle uses HTTPS to encrypt all data, including application sharing and voice, inbound and outbound, period.

Note also that not all HTTPS is created equal. Several strengths of SSL encryption exist, the most common being 40 and 56 bit strength. While much better than no encryption at all, these strengths are widely regarded as relatively easily "cracked", given sufficient resources. For this reason, most banks require the use of web browsers that support " strong" 128 bit SSL for on line banking. Many e-commerce web sites, however, allow transactions from browsers that support only the lower strengths, because such browsers are still common and the risks are arguably lower than those of online banking.

Because not all encryption is equal, WebHuddle has the option of requiring 128 bit HTTPS support. In other words, when starting a meeting, the host may decide to allow only participants whose browser supports 128 bit encryption. This option is for meetings that demand absolute security, and only WebHuddle offers it.

The WebHuddle security difference goes well beyond just HTTPS. If you have heard of "buffer overflow" attacks, you probably know that they comprise at least ninety percent of all computer viruses and worms. The buffer overflow was called "the biggest security problem to plague modern software" in the March 2004 Dr. Dobb’s Journal (p. 64). CPU manufacturers are even planning designs that would automatically guard against overflows ("Chips to ease Microsoft’s big security nightmare," NewScientist.com, Feb 4, 2004). Yet a software solution to this problem has existed for years ... it’s called Java and WebHuddle leverages its security benefits on both the server and the client applet.

Designed with the hazards of the Internet in mind, Java has extensive and proven security features, such as protection against buffer overflows. Every buffer access is preceded by a check that the area accessed is within the legal bounds of the given buffer. Unlike C and C++, the two other most common programming languages, Java does not allow reading or writing to arbitrary locations in memory. This virtually eliminates the chance of overflow attacks.

By default, Java applets run in a "sandbox" which blocks them from any action that could compromise the user’s computer or privacy. For example, an applet cannot read or write to any files, open a user’s microphone, or make network connections to servers other than the server from which it originated, among dozens of other restrictions. Only digitally signed applets may do privileged operations, such as opening your microphone, and only after explicitly requesting and receiving permission from the user.

For a participant to be able to share their desktop, then, they would need to "opt in" and grant permission to the WebHuddle client applet. But granting such permission is not required to join a WebHuddle meeting, as it is with other web conferencing solutions. Even the meeting host may decline the permission request and still run a meeting. The meeting host can also optionally choose the "sandbox" mode for all participants, so people aren’t prompted for permissions when they join in. Only WebHuddle offers this degree of flexibility.

Most other web conferencing clients run not as Java applets but as browser "plugins." Written in C and C++, plugins lack Java’s security benefits, including protection from buffer overflows. Upon installation, plugins request your permission, just like the WebHuddle client applet. Unlike WebHuddle, however, it’s an all-or-nothing proposition: if you don’t "trust" the installation, it stops and you cannot join the meeting.

A secure client is worthless with an insecure server. Like the WebHuddle client, the WebHuddle server is written entirely in Java, so it too benefits from Java’s security advantages. In addition, multiple layers of facility, hardware and software protection assure the safety of the WebHuddle servers. Video surveillance, firewalls and locked cabinets create a virtual fortress around WebHuddle.

Finally, WebHuddle even sweats details like cookies and JavaScript (also called "Active Scripting"; not the same as Java). Some users disable cookies because they can compromise privacy. Many JavaScript vulnerabilities have been discovered, especially what are called "cross-site scripting" hacks. Unlike most other services, neither cookies nor JavaScript need be enabled to participate in WebHuddle.

In the critical area of security, WebHuddle is truly unique. WebHuddle made security complete and standard, not an option, not an afterthought.

SourceForge.net Logo