Monthly Archives: July 2013

Update FileSender roadmap: terasender, multi-file and file encryption

A summer update on the current roadmap for FileSender.  The next update is expected in the week of 22-25 July.

Next release: version 1.6 “TeraSender”

The next release is slated to be version 1.6 nicknamed “TeraSender”, leveraging the results of the FileSender TeraByte Challenge.  Release 1.6 will include:

  • significant upload speed improvement with new TeraSender upload module with upload speeds realistically enabling terabyte file sizes
  • improved MyFiles clearing the way for multi file transfers and changes in email flow
  • partial download support

As of this weekend code integration for the first beta is completed and a thorough work flow test cycle is now being planned.  After that test we expect to announce a release planning date for the first 1.6-beta.  You can track progress on the cardwall for tickets related to the 1.6 release.

We do expect a second beta with improved upload authentication handling and configurable CSS, tickets #905 Modify session validity check on upload to allow for very long uploads and #892 CSS Configurable.  These were postponed for the time being.  From previous releases we know it takes about 6 to 8 weeks to cycle from one beta to the next one.  Knowing we plan a 2nd beta the current dead line for a release candidate for the 1.6 release is 1 October.

Release 2.0: multi file with improved email flow options

UNINETT hired two summer students, Jack Kittridge and Vegard Polden, to work full time on FileSender for 2 months.  The project decided to use this opportunity to make a serious stab at support for multi-file transfers.  During the last month we’ve planned release 2.0, which we envision will be fully multi-file transfer capable: uploads, MyFiles, downloads and email receipts.  With email already being reworked it seems a good opportunity to include better user control of email receipts: we plan 5 email options that’ll allow a user control of email receipts, including the often asked for “stop spamming me” option.

After 3 weeks of work Jack and Vegard have made good progress prototyping all necessary functionality and most of what we envision looks to be possible.  We had a question mark with downloading multi-file transfers; there is no consensus across browser vendors for a fileWriter API like there is for the HTML5 fileReader API.  This lack of open standard support meant an alternative solution had to be found, we envisioned streaming zip download which now mostly works.    With the addition of 250 lines of code and no extra dependencies streaming all files into a single downloaded zip file is not a problem and it looks to work without a performance hit.  At the moment the resulting zip file refuses to be unzipped with the Mac archiver but this looks like a solvable problem.

The prototyping phase for multi-file is expected to last another 3 to 4 weeks after which we’ll start putting together the actual 2.0 release.  What we aim at is a rough and ready release 2.0 that we can then polish through a beta cycle during the remainder of 2013.

Close tracking of the progress of release 2.0:

2014: native browser-based file encryption and time stamping

We have functional prototypes for file encryption and for cryptographic time stamping.  Once the multi file release is sufficiently advanced we will use that as a basis to support native browser-based file encryption as well as an option to leverage FileSender as the user front-end for cryptograhpic time stamping.

The file encryption functionality will open up use cases for transfer of sensitive data: health research, HR data, sensitive research, personal data etc.  An ability to encrypt files of any size directly in a browser against zero per-user license cost is something we haven’t had before so who knows, it might help us bring encryption to the masses.

The cryptographic time stamping functionality we envision will enable a role for FileSender in protecting research data and protecting research ideas (draft publications).  A cryptographic time stamp proves a certain (collection of) file(s) existed at a certain point in time and hasn’t been changed since.  This type of proof is crucial if you want to re-use scientific data sets to validate scientific results, or to build new research on.  A cryptographic time stamp combined with the user’s identity is also very useful to prove a certain idea documented in a draft publication existed on a certain point in time.  In the world of competitive academic research such functionality ought to be good to have.

We expect to start work on integrating native browser based file encryption as well as time stamping in 2014 and will use the time until then to sharpen our vision and scope these new features.