Accellion blog has moved!

You should be automatically redirected in 6 seconds. If not, visit
and update your bookmarks.

Friday, August 11, 2006

FTP, Email, HTTPS, and BitTorrent? A historic perspective on sending large files/attachments securely for enterprise users

Summary: For enterprise users, FTP was the first dominant solution for file transfer. Email attachment teased the non-technical masses with a taste of what is possible. HTTPS and Web 2.0 is now the de rigour technology for secure file transfer. The question is, would BitTorrent be the next thing?


Being a lazy summer day, ACA Guy's attention (naturally) shifts to the evolution of sending large files securely by enterprise users, from FTP in the 70's, to the rise of email throughout the 80's and 90's, and the current competing crop of file transfer solutions from HTTPS to BitTorrent.


What makes the information technology (IT) industry interesting is its constantly shifting benchmarks and non-stop sprinting by all concerned just to keep up with what is technically adequate because no one wants to find himself being the last man using the wrong technology. The trouble is that only hindsight is 20-20. New technology and protocols are being introduced by vendors and adopted by users, with or without the approval and support of the IT department. Any semblance of IT clairvoyance is only possible with a combination of business perspective and technical acumen tempered by a long-term view.

FTP: the first file transfer solution

The first dominant technology for file transfer was FTP, or file transfer protocol, as first described in the 1971 RFC114 document. In its basic form, as described by Wikipedia's FTP section:

The FTP server listens for connection requests. The client computer initiates a connection to the server. Once connected, the client can do a number of file manipulation operations such as uploading files to the server, download files from the server, rename or delete files on the server and so on.

Since it was designed by and for technical users, FTP has earned the notoriety of being a technically powerful but end-user unfriendly solution. Many vendors have tried to put pretty user interface wrappers around it to enhance the usability, but its legacy status continues to both haunt its wider adoption as a business tool and make it a deeply entrenched tool in many IT shops.

As a business tool for file transfer, FTP also suffers on the security and privacy side. For example, I have noted concerns over Google indexing FTP servers and a major managed file transfer vendor admitting the need to monitor FTP activities.

Email: file transfer for the rest of us

In the late 80's and early 90's, email started to emerge as a new dominant solution for sending files while FTP began the process of becoming a mostly machine-to-machine niche solution using its scripting capabilities.

With the proliferation of PCs in the 80's and Internet in the 90's, email has become a universal business communication tool. More importantly, in the context of this missive, there is just no easier way than email attachment to send files.

The trouble with email attachments as a file transfer solution started as purely a performance issue. Email is not designed as a file transport solution, so when the CEO wants to share a 5MB presentation with 200 key people around the globe, he has just pumped about 1GB worth of data (5MB x 200 recipients) through the system with one click and, if he is really unlucky, crashed the email server. In response, IT departments started to impose increasingly stringent email attachment size limits which I have addressed in more detail here.

But the headache with email attachment does not stop there. With its near universal popularity, email has also become the main target for cyber crime and pranks. And, with the payload carrying ability of attachments, email attachment is the most common conduit in which computer infections spread. Yes, there is a whole industry focused on addressing this problem with lots of chatter, including yours truly in this posting, surrounding it. But, the net net of it is that IT administrators are, wisely, putting in additional constraints on email attachments to lock down the cage and protect one of the most visible corporate processes.

In short, sending data and large files through email attachment has become increasingly difficult or simply disallowed in many enterprise environments.

HTTPS, XML, and Web 2.0: secure file transfer pretenders

The irony is that as email is being locked down, we are entering a hyper-collaborative world where most business processes involve some sort of information exchange with both internal and external senders and recipients. Exacerbating the issue further, the IT industry has enabled users to generate more data, larger files, and bulkier presentations with greater ease and less time than just a few years back.

With an increasing number of people who require the ability to easily, quickly, and securely exchange large sets of information, the issue of secure file transfer has elevated beyond a technical consideration and become a core business process issue.

The truth is, business users just want the ability to send a 20MB PowerPoint presentation to 100 recipients with a single click, because that is what they need to do to get the job done. Finance/compliance people just want to have a process where information/data/file gets from user A to user B in a secure and auditable manner. And, IT folks just want to be left alone.

The current pretender to meet the user's secure file transfer needs come from the family of web technology, XML, HTTPS, etc., whose acronyms we have grown accustomed to in the late-90's. Amongst its many merits, web technology offers a compelling combination of features for enterprise users as a file transfer tool such as:

  • It does not require any specialized software beyond a browser which is free and, overwhelmingly, preinstalled on every computer.

  • It can enforce security through various encryption methods which are considered highly robust.

  • Its basic architectural capability is such that it can push a file to the recipient without involving FTP or impacting email servers.
Of course, there are the issues of Web 2.0 and AJAX (which Accellion has implemented) as well as the browser imposed file size barrier of 2GB (which Accellion also broke through). But, these are details.

Within the context of HTTPS and other web protocols, there is a wide selection of vendors whose products range from letting you upload and download files from a website on a pay-per-use basis to Accellion, which offers a dedicated secure file transfer appliance. This appliance, by the way, sits within the enterprise IT infrastructure to provide extensive IT administrative capability as well as integration into Exchange/Outlook and Domino/Notes.

Think of these as field tested and crusty veterans in the current incarnation of secure file transfer solutions for enterprise usage.

BitTorrent: is it ready for enterprise secure file transfer prime time?

Then there’s BitTorrent, the newest kid on the large file transfer block. As a P2P (peer-to-peer) file sharing protocol, it is mostly mentioned in the context of teenagers exchanging (pirated) files with each other. At its most basic level, unlike the classic approach of sending a file from user A to user B through a dedicated connection, BitTorrent breaks up the file and passes the pieces through peer computers via a swarm from the sender to the recipient. Because a swarm can have many peers, the performance of sending a large file can be improved as a distributed grid design. Furthermore, with each peer machine having bits and pieces of the file at any one time, it also removes the bottleneck of the origination sender for a file's proliferation.

I can definitely see the process advantages BitTorrent offers in the P2P and consumer context as its creator Bram Cohen argued. But, what ACA Guy wants to know is, would it work for enterprise file transfer and what form would it take?


Let me know what you think while I fetch a glass of iced tea.


No comments: